linux-kernel - Re: 4.4-final: 28 bioset threads on small notebook

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: <20160223145442.GB8047@redhat.com>
Date:	Tue, 23 Feb 2016 09:54:42 -0500
From:	Mike Snitzer <snitzer@...hat.com>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	Kent Overstreet <kent.overstreet@...il.com>,
	"oleg.drokin@...el.com" <oleg.drokin@...el.com>,
	Ming Lin-SSI <ming.l@....samsung.com>,
	"andreas.dilger@...el.com" <andreas.dilger@...el.com>,
	"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
	"minchan@...nel.org" <minchan@...nel.org>,
	"jkosina@...e.cz" <jkosina@...e.cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	"jim@...n.com" <jim@...n.com>,
	"pjk1939@...ux.vnet.ibm.com" <pjk1939@...ux.vnet.ibm.com>,
	"axboe@...com" <axboe@...com>,
	"geoff@...radead.org" <geoff@...radead.org>,
	"dm-devel@...hat.com" <dm-devel@...hat.com>,
	"dpark@...teo.net" <dpark@...teo.net>, Pavel Machek <pavel@....cz>,
	"ngupta@...are.org" <ngupta@...are.org>, "hch@....de" <hch@....de>,
	"agk@...hat.com" <agk@...hat.com>
Subject: Re: 4.4-final: 28 bioset threads on small notebook

On Mon, Feb 22 2016 at  9:55pm -0500,
Ming Lei <ming.lei@...onical.com> wrote:

> On Tue, Feb 23, 2016 at 6:58 AM, Kent Overstreet
> <kent.overstreet@...il.com> wrote:
> > On Sun, Feb 21, 2016 at 05:40:59PM +0800, Ming Lei wrote:
> >> On Sun, Feb 21, 2016 at 2:43 PM, Ming Lin-SSI <ming.l@....samsung.com> wrote:
> >> >>-----Original Message-----
> >> >
> >> > So it's almost already "per request_queue"
> >>
> >> Yes, that is because of the following line:
> >>
> >> q->bio_split = bioset_create(BIO_POOL_SIZE, 0);
> >>
> >> in blk_alloc_queue_node().
> >>
> >> Looks like this bio_set doesn't need to be per-request_queue, and
> >> now it is only used for fast-cloning bio for splitting, and one global
> >> split bio_set should be enough.
> >
> > It does have to be per request queue for stacking block devices (which includes
> > loopback).
> 
> In commit df2cb6daa4(block: Avoid deadlocks with bio allocation by
> stacking drivers), deadlock in this situation has been avoided already.
> Or are there other issues with global bio_set? I appreciate if you may
> explain it a bit if there are.

Even with commit df2cb6daa4 there is still risk of deadlocks (even
without low memory condition), see:
https://patchwork.kernel.org/patch/7398411/

(you may recall you blocked this patch with concerns about performance,
context switches, plug merging being compromised, etc.. to which I never
circled back to verify your concerns)

But it illustrates the type of problems that can occur when your rescue
infrastructure is shared across devices (in the context of df2cb6daa4,
current->bio_list contains bios from multiple devices). 

If a single splitting bio_set were shared across devices there would be
no guarantee of forward progress with complex stacked devices (one or
more devices could exhaust the reserve and starve out other devices in
the stack).  So keeping the bio_set per request_queue isn't prone to
failure like a shared bio_set might be.

Mike