linux-kernel - Re: [patch] block: fix flush machinery for stacking drivers with differring flush flags

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] [day] [month] [year] [list]

Message-ID: <x49bovupns1.fsf@segfault.boston.devel.redhat.com>
Date:	Fri, 12 Aug 2011 13:01:18 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Shaohua Li <shli@...nel.org>
Cc:	Tejun Heo <tj@...nel.org>, Jens Axboe <jaxboe@...ionio.com>,
	linux-kernel@...r.kernel.org, dm-devel@...hat.com,
	msnitzer@...hat.com, vgoyal@...hat.com
Subject: Re: [patch] block: fix flush machinery for stacking drivers with differring flush flags

Shaohua Li <shli@...nel.org> writes:

> 2011/8/10 Jeff Moyer <jmoyer@...hat.com>:
>> @@ -320,6 +319,7 @@ void blk_insert_flush(struct request *rq)
>>        if ((policy & REQ_FSEQ_DATA) &&
>>            !(policy & (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH))) {
>>                list_add_tail(&rq->queuelist, &q->queue_head);
>> +               blk_run_queue_async(q);
> A minor issue. I can understand this is required for
> blk_insert_cloned_request() because INSERT_BACK will run
> queue but INSERT_FLUSH doesn't. But sounds we don't need
> run queue for normal requests. Either __make_request will run
> queue (task has plug list) or flush_plug will run queue. delaying
> run queue has its benefit. can we do the runqueue in
> blk_insert_cloned_request() if this is a INSERT_FLUSH.

Well, the only time we need to run the queue is when the request has
data, has REQ_FUA set, and the underlying queue's flush flags contain
only REQ_FUA.  In code:

if (rq->cmd_flags & REQ_FUA && q->flush_flags == REQ_FUA)
	blk_run_queue_async(q);

If that was added to blk_insert_cloned_request, we could get rid of the
blk_run_queue_async in blk_insert_flush.  However, I think Tejun will
object due to the layering violation for the same reason he doesn't like
my handling of empty flushes in blk_insert_cloned_request.

Tejun?

Cheers,
Jeff
--
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/