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.0811100754210.3468@nehalem.linux-foundation.org>
Date:	Mon, 10 Nov 2008 08:00:10 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jens Axboe <jens.axboe@...cle.com>
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, 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.

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.

			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/