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]

Date:	Mon, 10 Nov 2008 18:10:57 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Tejun Heo <tj@...nel.org>, 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, Nov 10 2008, Linus Torvalds wrote:
> 
> 
> On Mon, 10 Nov 2008, Jens Axboe wrote:
> > > 
> > > Or we could just change the blk-tag.c logic to stop of
> > > find_first_zero_bit() returns >= some_value instead of starting at an
> > > offset? You don't need any extra locking for that.
> > 
> > Something like the below.
> 
> No, there were two reasons for doing it the way I did it, and this shows 
> both. One trivial, one subtle.
> 
> > +	if (!rq_is_sync(rq))
> > +		max_depth = 3 * max_depth / 4;
> 
> The trivial one here is that you round down. Imagine what happens if 
> "max_depth" was 1.
> 
> The subtler one was that the 'use starting offset' means that async and 
> sync can _share_ the tagspace, and while you limit async ones to a maximum 
> outstanding number, you really cut down on them only when sync ones really 
> have filled everything up.
> 
> In contrast, limiting like the above means that it's much easier to be in 
> the situation where you still have tags to use, but you've used them all 
> for reads, and you refuse to start a single write.

Good point. I'll do a counting solution for this instead.

> Anyway, I'll do the revert, since -rc4 is too late to discuss these 
> issues. I think we can easily re-do things when everybody is ok with the 
> code.

OK, we'll get it into shape for 2.6.29 instead.

-- 
Jens Axboe

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