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 16:27:51 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Mike Snitzer <snitzer@...hat.com>
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 10:01:24AM -0400, Mike Snitzer wrote:
> 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?

Yes, we could have.  I was just being lazy and looking for an easy
solution.

> The folding of elv_insert() into __elv_add_request() seems
> irrelevant.

Strictly, it is but they kinda go well together.

> 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).

No, the data ordering is enforced by the filesystem in the new
implementation meaning that by the time FLUSH is issued by the
filesystem, it should have made sure that all requests which must be
written before the FLUSH already had completed.

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

I think 2.6.38 needs a -stable fix.  It has the previous version of
the new flush implementation and is using front insertion.

Thanks.

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