linux-ext4 - Re: [EXTERNAL]Re: ext4 build errors

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 2 Oct 2017 14:40:35 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Joakim Tjernlund <Joakim.Tjernlund@...inera.com>
Cc:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [EXTERNAL]Re: ext4 build errors

On Mon, Oct 02, 2017 at 05:27:12PM +0000, Joakim Tjernlund wrote:
> > This is why void * is the right thing --- it's not a u32 or a long.
> > It's a bit array.  And in the case of the mb buddy bitmap, it's not
> > necessarily going to start on a a byte boundary which is a multiple of
> > 4 or 8.
> 
> For ext4 it might be right but I was using "you" in a wider scope,
> the rest of kernel src.

So let's take this up to a high level of the problem.  For the bitops
functions, there are two sorts of users.  Those that want to operate
on an integer type (either a u32 or a long), and those that operate on
bitarrays.  Most of the integer users are using the bitops for
in-memory state flags.  Most of the bitarray use cases are for things
like ext4's allocation bitmaps, where the on-disk format needs to be
portable across architectures --- and that's where bitops_le tends to
be used.

Taking a quick look at the output of "git grep set_bit_le", most of
the users are just like ext4, where it's being used for a bitarray.
So my argument I think *does* apply much more widely.

      	       	       	      	    	 - Ted