linux-kernel - Re: [PATCH] x86: always_inline wrapper for x86's test

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]

Message-Id: <1208175845.22460.1247749229@webmail.messagingengine.com>
Date:	Mon, 14 Apr 2008 14:24:05 +0200
From:	"Alexander van Heukelum" <heukelum@...tmail.fm>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Alexander van Heukelum" <heukelum@...lshack.com>,
	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: always_inline wrapper for x86's test_bit

On Sun, 13 Apr 2008 20:16:42 +0200, "Andi Kleen" <andi@...stfloor.org>
said:
> > I have googled, but the only problem I found was concerning dead code 
> 
> It might come as a surprise, but google is still not omniscient.

Hi,

It's just not always easy to think of the right question to ask the
oracle ;).

> > elimination, and in particular references to unavailable object from
> > code that was expected to be discarded. The worst that can happen in 
> > this case is that gcc might produce a strange construction where a
> > runtime check will choose between the two alternative implementations of
> > test_bit. Another is that it will select the 'wrong' implementation. 
> > Both will result is some code-bloat, but at least the code should work
> > properly.
> 
> Yes, but extreme code bloat can be fatal.
> 
> > I have not checked with 3.2. The oldest compiler I have available here
> > is 3.3. That version compiles the functions as expected: I have found
> > instances of either type in the objdump and I have not found strange
> > constructions with both types there.
> 
> It would be good to check on 3.2 too to avoid potential nasty surprises.

Checked with a stock 3.2.3 form gcc.gnu.org (compiled using debian's
gcc-2.95). It gets it right: places that should get the C version get
the C version and places that should get the inline-assembly version
get the inline-assembly version. No funny things at all.

B.T.W., debian and ubuntu don't provide gcc-3.2 packages. Is there a
good reason why gcc-3.2.3 (5 years old in a week) should still be
supported?

> > If you were thinking of another/bigger problem with gcc-3.2, could you 
> > please give me a pointer?
> 
> Not sure what you mean here.

I just thought you might have been thinking of a specific problem. A
bug-report or something like that would have been convenient to have.
Looking for a problem is easier than looking for no problems ;).

Greetings,
    Alexander

> -Andi
-- 
  Alexander van Heukelum
  heukelum@...tmail.fm

-- 
http://www.fastmail.fm - Does exactly what it says on the tin

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