linux-kernel - Re: Problem with find_first

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:	Sun, 17 Aug 2008 19:22:23 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	Alexander van Heukelum <heukelum@...tmail.fm>
Cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: Problem with find_first_bit function and kin




--- On Sun, 8/17/08, Alexander van Heukelum <heukelum@...tmail.fm> wrote:

> From: Alexander van Heukelum <heukelum@...tmail.fm>
> Subject: Re: Problem with find_first_bit function and kin
> To: oakad@...oo.com, "Linux kernel mailing list" <linux-kernel@...r.kernel.org>
> Date: Sunday, August 17, 2008, 4:58 AM
> On Sat, 16 Aug 2008 12:26:54 -0700 (PDT), "Alex
> Dubov" <oakad@...oo.com>
> said:
> > It's well may be that I'm just missing
> something obvious.
> > 
> > It seems to me that find_first_bit/find_next_bit
> functions return their
> > offsets "base 1" - first set bit is
> "1" and last is "bitmap size". This
> > means that if only the last bit in the bitmap is set,
> the returned value
> > will be indistinguishable from no bits set situation.
> Moreover, bit
> > manipulation functions appear to use "base
> 0" bit addresses, adding to
> > the
> > inconvenience.
> > 
> > Is this a desired behavior? And, if yes, how is one
> supposed to deal with
> > last bit of the bitmap?
> 
> Hi Alex,
> 
> If this is the behaviour you observe, it's a bug. How
> did you
> find out?
> 
> The intended behaviour is that the bits are enumerated in
> "base 0"
> style. If only the last bit in the bitmap is set it should
> return
> bitmapsize-1 and if no bit is set it should return
> bitmapsize.
> Some architecture-specific code gets the last detail wrong,
> they
> return a value that is slightly larger than the bitmap size
> in
> some cases.
> 
> Greetings,
>     Alexander
> -- 

I was compiling some stuff out-of-the tree and got "ffs" linked in instead
of "__ffs", which caused all this weird behavior (on 64b platform). Sorry
for the noise.

But then, why "ffs" behaves differently from "__ffs" and whats the reason
they both exist?



      
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/