linux-kernel - Re: [PATCH] block: don't make BLK_DEF_MAX

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: <20160330174035.GA14356@infradead.org>
Date:	Wed, 30 Mar 2016 10:40:35 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Shaohua Li <shli@...com>
Cc:	Christoph Hellwig <hch@...radead.org>, linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org, axboe@...com, Kernel-team@...com,
	"4.2+" <stable@...r.kernel.org>, Ming Lei <ming.lei@...onical.com>,
	kent.overstreet@...il.com
Subject: Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big

On Wed, Mar 30, 2016 at 09:50:30AM -0700, Shaohua Li wrote:
> > bcache should be fixed to not allocate larger than allowed bios then.
> > And handling too large arguments to bio_alloc_bioset is still useful to
> > avoid the checks in the callers and make it robust.
> 
> Doesn't this conflict the goal of arbitrary bio size?

I don't think we ever had the goal of entirely arbitrary bio sizes,
we wanted to get rid of the driver imposed limits.  And I/O submitter
deciding that it's not bound by BIO_MAX_PAGES is something entirely
different.

> I think nothing is
> wrong in bcache side. The caller can allocate any size of bio, the block
> layer will split the bio into proper size according to block layer
> limitatio and driver limitation.

If we get actual arbitrary large bios we

 a) assume drivers can handle bios larger than BIO_MAX_PAGES, which
    we've just noticed md can't
 b) have to handle all sorts of mempools to handle this giant size

nothing that can't be be done, but it's pretty obvious that we're not
there yet.  And I'm not really sure it's necessarily worth it, but
I'm happy to be proven wrong.

> As long as bio_split can do the right
> job, caller of bio allo is good.

But it's pretty clear that it currently doesn't do the right job,
and reducing general queue limits for a single submitter that doesn't
follow the protocol isn't the way to go.  The obvious fix is to
make bcache behave like everyone else for now, and then look into
how useful and painful it would be to move to larger bios in general.