linux-ext4 - Re: Boot failure with ext2 and initrds

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 25 Nov 2006 14:59:16 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Andrew Morton <akpm@...l.org>, Mingming Cao <cmm@...ibm.com>,
	Hugh Dickins <hugh@...itas.com>, Mel Gorman <mel@...net.ie>,
	"Martin J. Bligh" <mbligh@...igh.org>,
	linux-kernel@...r.kernel.org,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: Boot failure with ext2 and initrds

On Thu, Nov 16, 2006 at 12:34:48PM +0000, Russell King wrote:
> On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
> > On Wed, 15 Nov 2006 22:55:43 -0800
> > Mingming Cao <cmm@...ibm.com> wrote:
> > 
> > > Hmm, maxblocks, in bitmap_search_next_usable_block(),  is the end block 
> > > number of the range  to search, not the lengh of the range. maxblocks 
> > > get passed to ext2_find_next_zero_bit(), where it expecting to take the 
> > > _size_ of the range to search instead...
> > > 
> > > Something like this: (this is not a patch)
> > >   @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > >    	ext2_grpblk_t next;
> > > 
> > >    -  	next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > >    +  	next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > 	if (next >= maxblocks)
> > >    		return -1;
> > >    	return next;
> > >    }
> > 
> > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > to scan at `offset'.
> 
> Are you sure?  That's not the way it's implemented in many architectures.
> find_next_*_bit() has always taken "address, maximum offset, starting offset"
> and always has returned "next offset".
> 
> Just look at arch/i386/lib/bitops.c:
> 
> int find_next_zero_bit(const unsigned long *addr, int size, int offset)
> {
>         unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
>         int set = 0, bit = offset & 31, res;
> ...
>         /*
>          * No zero yet, search remaining full bytes for a zero
>          */
>         res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *) addr));
>         return (offset + set + res);
> }
> 
> So for the case that "offset" is aligned to a "long" boundary, that gives us:
> 
> 	res = find_first_zero_bit(addr + (offset>>5),
> 			size - 32 * (addr + (offset>>5) - addr));
> 
> or:
> 
> 	res = find_first_zero_bit(addr + (offset>>5), size - (offset & ~31));
> 
> So, size _excludes_ offset.
> 
> Now, considering the return value, "res" above will be relative to
> "addr + (offset>>5)".  However, we add "offset" on to that, so it's
> relative to addr + (offset bits).

Andrew,

Please respond to the above.  If what you say is correct then all
architectures need their bitops fixing to fit ext2's requirements.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html