linux-kernel - Re: block: flush queued bios when the process blocks

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: <20151005195007.GA25762@redhat.com>
Date:	Mon, 5 Oct 2015 15:50:07 -0400
From:	Mike Snitzer <snitzer@...hat.com>
To:	Kent Overstreet <kmo@...erainc.com>
Cc:	Jens Axboe <axboe@...nel.dk>, dm-devel@...hat.com,
	Mikulas Patocka <mpatocka@...hat.com>,
	linux-kernel@...r.kernel.org, "Alasdair G. Kergon" <agk@...hat.com>
Subject: Re: block: flush queued bios when the process blocks

On Tue, May 27 2014 at  3:56pm -0400,
Kent Overstreet <kmo@...erainc.com> wrote:

> On Tue, May 27, 2014 at 01:33:06PM -0400, Mike Snitzer wrote:
> > On Tue, May 27 2014 at 12:26pm -0400,
> > Mikulas Patocka <mpatocka@...hat.com> wrote:
> > 
> > > On Tue, 27 May 2014, Jens Axboe wrote:
> > > 
> > > > On 2014-05-27 09:23, Mikulas Patocka wrote:
> > > > 
> > > > > The patch adds bio list flushing to the scheduler just besides plug
> > > > > flushsing.
> > > > 
> > > > ... which is exactly why I'm commenting. It'd be great to avoid yet one more
> > > > scheduler hook for this sort of thing.
> > > > 
> > > > -- 
> > > > Jens Axboe
> > > 
> > > One could create something like schedule notifier chain, but I'm not sure 
> > > if it is worth the complexity because of just two users. If more users 
> > > come in the future, it could be generalized.
> > 
> > It could be that Jens is suggesting updating blk_needs_flush_plug() and
> > blk_schedule_flush_plug() to be bio_list aware too (rather than train
> > sched_submit_work() from this new bio_list)?
> > 
> > Somewhat awkward, but _could_ be made to work.
> 
> No...
> 
> I started on this ages and ages ago, but the patches were nowhere near ready to
> go out.
> 
> What I'd do is rework the existing blk_plug to work in terms of bios, not
> requests. This is a fair amount of work, and then make_request_fn() needs to be
> able to take multiple bios at a time, but IIRC there were other simplifications
> that fell out of this and this also means bio based drivers can take advantage
> of plugging/batching.
> 
> Once this is done, you just... replace the bio list in generic_make_request()
> with a plug. Boom, done.
> 
> (oh, and to avoid blowing the stack the scheduler/plug callback or whatever
> needs to check the current stack usage and punt off to a per request_queue
> workqueue, but that's easy enough).

Re-reading your response since this bug is still lingering; and Mikulas'
patch _still_ fixes the deadlock.. you're suggesting all of the above
just to avoid an extra conditional scheduler callout..

Could be what you're proposing is "the one true way forward" but I'm not
touching it at this point.
--
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/