linux-kernel - Re: [PATCH] bitops: simplify generic bit finding functions

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:	Mon, 28 Apr 2008 21:26:11 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Harvey Harrison <harvey.harrison@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH] bitops: simplify generic bit finding functions

On Mon, 28 Apr 2008, Linus Torvalds wrote:
> > > > How about making the optimization controlled by a config switch so
> > > > arch maintainers can decide whether they want to enable the constant
> > > > optimization or unconditionally call the lib function ?
> > > 
> > > No.
> > > 
> > > This is just making that damn header line look worse and worse.
> > > 
> > > Is there a _reason_ to optimize this stupid function this way?
> > 
> > On architectures which have a find bit instruction we can replace the
> > call to the library function by a single instruction when the size of
> > the bitmap is less/equal bits per long and when the bitnr is a
> > constant.
> 
> That's not what I asked.
> 
> I asked whether there is a *reason* to optimize this and cause all these 
> stupid problems.
> 
> Is there a real hot path anywhere that actually uses this and depends on 
> it?

Sorry, misunderstood your question. 

I checked the use cases and have not found a single one for
find_next_(zero_)bit() which makes use of this micro optimization. In
fact the .text section of vmlinux of the "optimized" and the straight
function call are identical. So the effect of those micro
optimizations is exactly zero.

find_first_(zero_)bit() has a couple of places where the optimization
hits, but the code size reduction is mere 21 bytes and the use cases
are not in real hot pathes AFAICT.

I doubt that that is worth the trouble and we should just remove those
inlines alltogether. This was discussed before, but Andi objected to
remove those micro optimizations and nobody had time to actually
verify the real benefits.

I'll whip up a patch.

Thanks,

	tglx
--
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/