linux-kernel - Re: [PATCH v6 0/8] block: prepare for multipage bvecs

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]

Date:	Thu, 2 Jun 2016 10:13:18 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Mike Snitzer <snitzer@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>, Jens Axboe <axboe@...com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-block@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
	"open list:DRBD DRIVER" <drbd-dev@...ts.linbit.com>,
	Jan Kara <jack@...e.cz>, Joe Thornber <ejt@...hat.com>,
	Keith Busch <keith.busch@...el.com>,
	Kent Overstreet <kent.overstreet@...il.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Michal Hocko <mhocko@...e.com>, NeilBrown <neilb@...e.com>,
	Sagi Grimberg <sagig@...lanox.com>, Shaohua Li <shli@...com>,
	Steven Whitehouse <swhiteho@...hat.com>,
	Tejun Heo <tj@...nel.org>,
	"open list:XFS FILESYSTEM" <xfs@....sgi.com>
Subject: Re: [PATCH v6 0/8] block: prepare for multipage bvecs

On Wed, Jun 1, 2016 at 9:51 PM, Mike Snitzer <snitzer@...hat.com> wrote:
> On Wed, Jun 01 2016 at  9:44am -0400,
> Christoph Hellwig <hch@...radead.org> wrote:
>
>> On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
>> > > be dm-crypt.c.  Maybe you've identified some indirect use of
>> > > BIO_MAX_SIZE?
>> >
>> > I mean the recently introduced BIO_MAX_SIZE in -next tree:
>> >
>> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/md/dm-crypt.c?id=4ed89c97b0706477b822ea2182827640c0cec486
>>
>> The crazy bcache bios striking back once again.  I really think it's
>> harmful having a _MAX value and then having a minor driver
>> reinterpreting it and sending larger ones.  Until we can lift the
>> maximum limit in general nad have common code exercise it we really need
>> to stop bcache from sending these instead of littering the tree with
>> workarounds.
>
> So should I not push this type of fix to Linus now?  I was going to send
> the above commit and this one to him this week:
> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.7&id=57b3001b240629ecc5266d28c845e23ca5f11719

I don't suggest this kind of fix.

That fix should be in bcache or blk-core instead of other places.
Last time, I sent out the following fix([PATCH v1] block: make sure big bio is
splitted into at most 256 bvecs):

     https://lkml.org/lkml/2016/4/5/1046

But forget to clear the flag of REQ_NOMERGE for this case.

If Jens doesn't mind doing such thing in block-core, I can post v2
for this issue.

>
> Instead, should bcache be made to not do what it is doing?

It depends on if bcache is the only user of this kind of usage.
In theory, any driver can use external bvec table.

Thanks,
Ming