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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Mar 2016 09:50:30 -0700
From:	Shaohua Li <shli@...com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	<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 Tue, Mar 29, 2016 at 11:51:51PM -0700, Christoph Hellwig wrote:
> On Tue, Mar 29, 2016 at 03:01:10PM -0700, Shaohua Li wrote:
> > The problem is bcache allocates a big bio (with bio_alloc). The bio is
> > split with blk_queue_split, but it isn't split to small size because
> > queue limit. the bio is cloned later in md, which uses bio_alloc_bioset.
> > bio_alloc_bioset itself can't allocate big size bio.
> 
> 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 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. As long as bio_split can do the right
job, caller of bio allo is good. Fixing bcache is in the opposite side.
I'm Cc Kent to check if he wants to fix bcache.

Thanks,
Shaohua