linux-ext4 - Re: [EXTERNAL]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] [day] [month] [year] [list]

Message-ID: <1506975177.24473.15.camel@infinera.com>
Date:   Mon, 2 Oct 2017 20:12:58 +0000
From:   Joakim Tjernlund <Joakim.Tjernlund@...inera.com>
To:     "tytso@....edu" <tytso@....edu>
CC:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [EXTERNAL]Re: [EXTERNAL]Re: ext4 build errors

On Mon, 2017-10-02 at 14:40 -0400, Theodore Ts'o wrote:
> 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.

OK, I can see that. It is just that __set_bit_le is impl. using 
__set_bit(long nr, volatile unsigned long *addr) and that implies, to me,
that the memory should be long aligned. 

 Jocke