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  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:	Wed, 27 Oct 2010 19:28:33 -0400
From:	Jeff Garzik <>
To:	"Nicholas A. Bellinger" <>
CC:	James Bottomley <>,
	Andi Kleen <>,
	Mike Anderson <>,
	linux-kernel <>,
	linux-scsi <>,
	Vasu Dev <>,
	Tim Chen <>,
	Matthew Wilcox <>,
	Mike Christie <>,
	Jens Axboe <>,
	James Smart <>,
	Andrew Vasquez <>,
	FUJITA Tomonori <>,
	Hannes Reinecke <>,
	Joe Eykholt <>,
	Christoph Hellwig <>,
	Jon Hawley <>,
	Brian King <>,
	Christof Schmitt <>,
	Tejun Heo <>,
	Andrew Morton <>,
	"H. Peter Anvin" <>
Subject: Re: [ANNOUNCE] Status of unlocked_qcmds=1 operation for .37

On 10/27/2010 02:06 PM, Nicholas A. Bellinger wrote:
> On Wed, 2010-10-27 at 09:27 -0500, James Bottomley wrote:
>> On Wed, 2010-10-27 at 09:53 +0200, Andi Kleen wrote:
>>>> This sounds like a pretty reasonable compromise that I think is slightly
>>>> less risky for the LLDs with the ghosts and cob-webs hanging off of
>>>> them.
>>> They won't get tested either next release cycle. Essentially
>>> near nobody uses them.
>>>> What do you think..?
>>> Standard linux practice is to simply push the locks down. That's a pretty
>>> mechanical operation and shouldn't be too risky
>>> With some luck you could even do it with coccinelle.
>> Precisely ... if we can do the push down now as a mechanical
>> transformation we can put it in the current merge window as a low risk
>> API change.
> I disagree that touching every single legacy LLD's SHT->queuecommand()
> and failure paths in that code is a low rist change.

Think of changes like steps in a math proof.  You want to make a series 
of equivalent transformations such that, each transformation takes the 
code (proof) one step closer to your goal.

unlocked_qcmds does nothing but increase complexity, as opposed to an 
equivalent-transformation mechanical code change much more easily 
provable as correct (or broken). unlocked_qcmds is the type of 
transition step you always want to avoid if possible.  Conditional 
locking logic tends to be complexity at its worst... and in this case, 
it's all avoidable.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists