linux-kernel - Re: block: eliminate ELEVATOR_INSERT

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:	Wed, 30 Mar 2011 10:01:24 -0400
From:	Mike Snitzer <snitzer@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Vivek Goyal <vgoyal@...hat.com>,
	Jeff Moyer <jmoyer@...hat.com>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	linux-kernel@...r.kernel.org, Chris Mason <chris.mason@...cle.com>,
	hch@...radead.org
Subject: Re: block: eliminate ELEVATOR_INSERT_REQUEUE

On Wed, Mar 30 2011 at  4:02am -0400,
Tejun Heo <tj@...nel.org> wrote:

> Hello, Jens.
> 
> On Wed, Mar 30, 2011 at 09:59:09AM +0200, Jens Axboe wrote:
> > Pure front insert should be used for requeue and internal commands (like
> > spin up this drive, or get error information). Flush should append to
> > the dispatch list.
> 
> Yeah, right.  The reason I used REQUEUE/FRONT was because BACK
> insertion involves draining the elevator and then appending the
> request at the end of the dispatch queue, which is unnecessary and
> inefficient.  So, front insertion was a quick work around that.  If
> we're removing elv_insert(), we can just append directly to the
> dispatch queue from flush code.

I'm trying to follow along but unrolling what was said above is
challenging considering we're not getting rid of elv_insert()'s
functionality; it was just folded into __elv_add_request() -- offering
no functional change AFAIK.  So placing special meaning on getting rid
of elv_insert() is confusing me.

Why can we all of a sudden append the flush to the dispatch queue _but_
not have any concern about queue draining?  Seems that avoiding use of
BACK, by using list_add_tail, is enabling that.  Couldn't we have always
done that?  The folding of elv_insert() into __elv_add_request() seems
irrelevant.

Can we take a step back and be more explicit about the implications of
having inserted the flush with REQUEUE/FRONT?  Seems to me that having
_not_ inserted the flush at the end of the dispatch queue is cause for
potential corruption (preceding data hasn't been issued to the device
yet).

And just to be clear: none of this is a concern for stable right?  It is
just the flush-merge code introduced for 2.6.39 that needs fixing?

Please advise, thanks!
Mike
--
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/