linux-kernel - Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE

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:	Tue, 21 Apr 2009 17:31:23 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	hpa@...or.com
Cc:	rdreier@...co.com, h.mitake@...il.com, mingo@...e.hu,
	tglx@...utronix.de, rpjday@...shcourse.ca,
	linux-kernel@...r.kernel.org
Subject: Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars

From: "H. Peter Anvin" <hpa@...or.com>
Date: Tue, 21 Apr 2009 14:16:31 -0700

> Roland Dreier wrote:
>> To be honest I think the status quo ante was not really that bad.
> 
> That I have to vehemently disagree with.

I have to agree with Roland.

Unless you make it a compile failure, no driver author is going to
spend any amount of time trying to figure out how to deal with this
situation properly.

So in this sense, the current situation works really well.

If you make it just compile and make an arbitrary choice of whether
the top-32bits is read first or not, you're going to end up with
mysterious driver failures that only occur on some machines and the
cause of which won't be determined until after a lot of painful
digging.

This painful debugging experience is eliminated if the driver author
is told with a compile failure that there is an issue to resolve.

And that is what happens right now.
--
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/