Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1411235
| From | Christoph Hellwig <hch@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v6 0/8] block: prepare for multipage bvecs |
| Date | 2016-06-01 15:50 +0200 |
| Message-ID | <rFeH0-BQ-23@gated-at.bofh.it> (permalink) |
| References | <rEvAe-4Ni-11@gated-at.bofh.it> <rEUff-4Bu-9@gated-at.bofh.it> <rFdBg-8pl-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH v6 0/8] block: prepare for multipage bvecs Mike Snitzer <snitzer@redhat.com> - 2016-05-31 18:00 +0200
Re: [PATCH v6 0/8] block: prepare for multipage bvecs Ming Lei <ming.lei@canonical.com> - 2016-06-01 14:40 +0200
Re: [PATCH v6 0/8] block: prepare for multipage bvecs Christoph Hellwig <hch@infradead.org> - 2016-06-01 15:50 +0200
Re: [PATCH v6 0/8] block: prepare for multipage bvecs Mike Snitzer <snitzer@redhat.com> - 2016-06-01 16:00 +0200
Re: [PATCH v6 0/8] block: prepare for multipage bvecs Christoph Hellwig <hch@infradead.org> - 2016-06-01 16:10 +0200
Re: [PATCH v6 0/8] block: prepare for multipage bvecs Ming Lei <ming.lei@canonical.com> - 2016-06-02 04:20 +0200
csiph-web