Re: [PATCH v6 0/8] block: prepare for multipage bvecs
From: Mike Snitzer <hidden>
Date: 2016-06-01 13:51:55
Also in:
linux-xfs, lkml
From: Mike Snitzer <hidden>
Date: 2016-06-01 13:51:55
Also in:
linux-xfs, lkml
On Wed, Jun 01 2016 at 9:44am -0400, Christoph Hellwig [off-list ref] wrote:
On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:quoted
quoted
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=4ed89c97b0706477b822ea2182827640c0cec486The 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 Instead, should bcache be made to not do what it is doing?