On Wed, Jun 1, 2016 at 9:51 PM, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > On Wed, Jun 01 2016 at 9:44am -0400, > Christoph Hellwig <hch@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
