linux-kernel - Re: request to revert libata-convert-to-block-tagging patches

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: <alpine.LFD.2.00.0811100800420.3468@nehalem.linux-foundation.org>
Date:	Mon, 10 Nov 2008 08:03:45 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Tejun Heo <tj@...nel.org>
cc:	Jens Axboe <jens.axboe@...cle.com>, Jeff Garzik <jeff@...zik.org>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: request to revert libata-convert-to-block-tagging patches



On Mon, 10 Nov 2008, Tejun Heo wrote:
>
> I'm just a little bit nervous because libata always has had this tag 0 
> for non-NCQ commands assumption and this conversion changes that, so I 
> was hoping to update blk-tag such that such assumption can be guaranteed 
> first and then convert libata to be on the safe side.  Some controllers 
> use completely different command mechanism for different protocols and 
> it's much safer and more deterministic if same tag can be guaranteed.

Yeah, I think that's a good argument. Even when controllers expect tags, 
it's certainyl quite possible that all they've ever been tested with have 
always started tag allocation from zero, so while the "start at an offset" 
thing is fairly clever for other reasons, it probably was the wrong thing 
to do.

Maybe we can just have something count "outstanding async/sync requests".

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