linux-kernel - Re: [PATCH 1/3] bitops: Add _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <49834.1240849877@turing-police.cc.vt.edu>
Date:	Mon, 27 Apr 2009 12:31:17 -0400
From:	Valdis.Kletnieks@...edu
To:	Steven Whitehouse <swhiteho@...hat.com>
Cc:	linux-kernel@...r.kernel.org, cluster-devel@...hat.com
Subject: Re: [PATCH 1/3] bitops: Add __ffs64 bitop

On Mon, 27 Apr 2009 16:41:06 BST, Steven Whitehouse said:
> The intent was that it would operate on native endian u64 words so that
> it shouldn't be affected by the endianess.

Hmm.. it's passing a 64-bit by value, not by a pointer ref - a subtle
distinction - if that code had done   *(u32)word instead it would break
on some archs.  That will teach me to read code when not caffeinated enough.

(I also admit that often I post comments on the basis of "If I can misread
this, so can some other poor decaffienated Joe Programmer on a Monday morning" ;)

>                                            In the GFS2 code where it is
> used, the byte ordering is converted to native order before this
> function is applied,

Is that a reasonable expectation when other parts of the kernel start
using it?  We've seen bugs before when 32-bit code tries to deal with
a 64-bit or bigger bitfield as a pair or series of 32-bit fields...

- * @word: The 64 bit word
+ * @word: The 64 bit word - must be in native byte order

probably is enough for those who bother finding the function def/doc. And
the ones who don't bother, we can't help anyhow. ;)

Content of type "application/pgp-signature" skipped