From: Ming Lei <[email protected]>
commit 3d75ca0adef4280650c6690a0c4702a74a6f3c95 upstream.
This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec
support.
The introduced helpers treate one bvec as real multi-page segment,
which may include more than one pages.
The existed helpers of bvec_iter_* are interfaces for supporting current
bvec iterator which is thought as single-page by drivers, fs, dm and
etc. These introduced helpers will build single-page bvec in flight, so
this way won't break current bio/bvec users, which needn't any change.
Follows some multi-page bvec background:
- bvecs stored in bio->bi_io_vec is always multi-page style
- bvec(struct bio_vec) represents one physically contiguous I/O
buffer, now the buffer may include more than one page after
multi-page bvec is supported, and all these pages represented
by one bvec is physically contiguous. Before multi-page bvec
support, at most one page is included in one bvec, we call it
single-page bvec.
- .bv_page of the bvec points to the 1st page in the multi-page bvec
- .bv_offset of the bvec is the offset of the buffer in the bvec
The effect on the current drivers/filesystem/dm/bcache/...:
- almost everyone supposes that one bvec only includes one single
page, so we keep the sp interface not changed, for example,
bio_for_each_segment() still returns single-page bvec
- bio_for_each_segment_all() will return single-page bvec too
- during iterating, iterator variable(struct bvec_iter) is always
updated in multi-page bvec style, and bvec_iter_advance() is kept
not changed
- returned(copied) single-page bvec is built in flight by bvec
helpers from the stored multi-page bvec
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Omar Sandoval <[email protected]>
Signed-off-by: Ming Lei <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Cc: Zubin Mithra <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/bvec.h | 30 +++++++++++++++++++++++++++---
1 file changed, 27 insertions(+), 3 deletions(-)
--- a/include/linux/bvec.h
+++ b/include/linux/bvec.h
@@ -23,6 +23,7 @@
#include <linux/kernel.h>
#include <linux/bug.h>
#include <linux/errno.h>
+#include <linux/mm.h>
/*
* was unsigned short, but we might as well be ready for > 64kB I/O pages
@@ -52,16 +53,39 @@ struct bvec_iter {
*/
#define __bvec_iter_bvec(bvec, iter) (&(bvec)[(iter).bi_idx])
-#define bvec_iter_page(bvec, iter) \
+/* multi-page (mp_bvec) helpers */
+#define mp_bvec_iter_page(bvec, iter) \
(__bvec_iter_bvec((bvec), (iter))->bv_page)
-#define bvec_iter_len(bvec, iter) \
+#define mp_bvec_iter_len(bvec, iter) \
min((iter).bi_size, \
__bvec_iter_bvec((bvec), (iter))->bv_len - (iter).bi_bvec_done)
-#define bvec_iter_offset(bvec, iter) \
+#define mp_bvec_iter_offset(bvec, iter) \
(__bvec_iter_bvec((bvec), (iter))->bv_offset + (iter).bi_bvec_done)
+#define mp_bvec_iter_page_idx(bvec, iter) \
+ (mp_bvec_iter_offset((bvec), (iter)) / PAGE_SIZE)
+
+#define mp_bvec_iter_bvec(bvec, iter) \
+((struct bio_vec) { \
+ .bv_page = mp_bvec_iter_page((bvec), (iter)), \
+ .bv_len = mp_bvec_iter_len((bvec), (iter)), \
+ .bv_offset = mp_bvec_iter_offset((bvec), (iter)), \
+})
+
+/* For building single-page bvec in flight */
+ #define bvec_iter_offset(bvec, iter) \
+ (mp_bvec_iter_offset((bvec), (iter)) % PAGE_SIZE)
+
+#define bvec_iter_len(bvec, iter) \
+ min_t(unsigned, mp_bvec_iter_len((bvec), (iter)), \
+ PAGE_SIZE - bvec_iter_offset((bvec), (iter)))
+
+#define bvec_iter_page(bvec, iter) \
+ nth_page(mp_bvec_iter_page((bvec), (iter)), \
+ mp_bvec_iter_page_idx((bvec), (iter)))
+
#define bvec_iter_bvec(bvec, iter) \
((struct bio_vec) { \
.bv_page = bvec_iter_page((bvec), (iter)), \
Hi!
> From: Ming Lei <[email protected]>
>
> commit 3d75ca0adef4280650c6690a0c4702a74a6f3c95 upstream.
>
> This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec
> support.
>
> The introduced helpers treate one bvec as real multi-page segment,
> which may include more than one pages.
>
> The existed helpers of bvec_iter_* are interfaces for supporting current
> bvec iterator which is thought as single-page by drivers, fs, dm and
> etc. These introduced helpers will build single-page bvec in flight, so
> this way won't break current bio/bvec users, which needn't any
> change.
I don't understand why we have this in 4.19-stable. I don't see
followup patches needing it, and it does not claim to fix a bug.
> +#define mp_bvec_iter_bvec(bvec, iter) \
> +((struct bio_vec) { \
> + .bv_page = mp_bvec_iter_page((bvec), (iter)), \
> + .bv_len = mp_bvec_iter_len((bvec), (iter)), \
> + .bv_offset = mp_bvec_iter_offset((bvec), (iter)), \
> +})
> +
> +/* For building single-page bvec in flight */
> + #define bvec_iter_offset(bvec, iter) \
> + (mp_bvec_iter_offset((bvec), (iter)) % PAGE_SIZE)
> +
Plus this one is strange. IIRC preprocessor directives have to put #
in column zero?
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
On Thu, Nov 11, 2021 at 05:47:54PM +0100, Pavel Machek wrote:
> Hi!
>
> > From: Ming Lei <[email protected]>
> >
> > commit 3d75ca0adef4280650c6690a0c4702a74a6f3c95 upstream.
> >
> > This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec
> > support.
> >
> > The introduced helpers treate one bvec as real multi-page segment,
> > which may include more than one pages.
> >
> > The existed helpers of bvec_iter_* are interfaces for supporting current
> > bvec iterator which is thought as single-page by drivers, fs, dm and
> > etc. These introduced helpers will build single-page bvec in flight, so
> > this way won't break current bio/bvec users, which needn't any
> > change.
>
> I don't understand why we have this in 4.19-stable. I don't see
> followup patches needing it, and it does not claim to fix a bug.
There is some more context on this at:
https://lore.kernel.org/linux-block/[email protected]/T/#u
and
https://lore.kernel.org/stable/[email protected]/T/#u
Thanks,
- Zubin
>
> > +#define mp_bvec_iter_bvec(bvec, iter) \
> > +((struct bio_vec) { \
> > + .bv_page = mp_bvec_iter_page((bvec), (iter)), \
> > + .bv_len = mp_bvec_iter_len((bvec), (iter)), \
> > + .bv_offset = mp_bvec_iter_offset((bvec), (iter)), \
> > +})
> > +
> > +/* For building single-page bvec in flight */
> > + #define bvec_iter_offset(bvec, iter) \
> > + (mp_bvec_iter_offset((bvec), (iter)) % PAGE_SIZE)
> > +
>
> Plus this one is strange. IIRC preprocessor directives have to put #
> in column zero?
>
> Best regards,
> Pavel
> --
> http://www.livejournal.com/~pavelmachek
Hi!
> > > This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec
> > > support.
> > >
> > > The introduced helpers treate one bvec as real multi-page segment,
> > > which may include more than one pages.
> > >
> > > The existed helpers of bvec_iter_* are interfaces for supporting current
> > > bvec iterator which is thought as single-page by drivers, fs, dm and
> > > etc. These introduced helpers will build single-page bvec in flight, so
> > > this way won't break current bio/bvec users, which needn't any
> > > change.
> >
> > I don't understand why we have this in 4.19-stable. I don't see
> > followup patches needing it, and it does not claim to fix a bug.
>
>
> There is some more context on this at:
> https://lore.kernel.org/linux-block/[email protected]/T/#u
> and
> https://lore.kernel.org/stable/[email protected]/T/#u
Thank you!
Pavel
--
http://www.livejournal.com/~pavelmachek
On Thu, Nov 11, 2021 at 07:53:08PM +0100, Pavel Machek wrote:
> > There is some more context on this at:
> > https://lore.kernel.org/linux-block/[email protected]/T/#u
> > and
> > https://lore.kernel.org/stable/[email protected]/T/#u
>
> Thank you!
Honestly, this looks broken to me. multipage-bvec was a big invasive
series with a lot of latter fixups. While taking this patch on it's
own should be save by itself, but also useless. So if it is needed
to make a KASAN warning go away we need to dig deeper and back something
else out that should not have been backported to rely on multipage
bvec becasue without the other patches they don't exist and can't
acually work.
On Fri, Nov 12, 2021 at 06:48:11AM +0100, Christoph Hellwig wrote:
> On Thu, Nov 11, 2021 at 07:53:08PM +0100, Pavel Machek wrote:
> > > There is some more context on this at:
> > > https://lore.kernel.org/linux-block/[email protected]/T/#u
> > > and
> > > https://lore.kernel.org/stable/[email protected]/T/#u
> >
> > Thank you!
>
> Honestly, this looks broken to me. multipage-bvec was a big invasive
> series with a lot of latter fixups. While taking this patch on it's
> own should be save by itself, but also useless. So if it is needed
> to make a KASAN warning go away we need to dig deeper and back something
> else out that should not have been backported to rely on multipage
> bvec becasue without the other patches they don't exist and can't
> acually work.
Ok, let me drop this for now.
Zubin, can you provide a better report as to what driver is causing the
problem and what exactly resolves it? Has this issue always been in
4.19 since 4.19.0?
thanks,
greg k-h
On 11/11/21 10:48 PM, Christoph Hellwig wrote:
> On Thu, Nov 11, 2021 at 07:53:08PM +0100, Pavel Machek wrote:
>>> There is some more context on this at:
>>> https://lore.kernel.org/linux-block/[email protected]/T/#u
>>> and
>>> https://lore.kernel.org/stable/[email protected]/T/#u
>>
>> Thank you!
>
> Honestly, this looks broken to me. multipage-bvec was a big invasive
> series with a lot of latter fixups. While taking this patch on it's
> own should be save by itself, but also useless. So if it is needed
> to make a KASAN warning go away we need to dig deeper and back something
> else out that should not have been backported to rely on multipage
> bvec becasue without the other patches they don't exist and can't
> acually work.
Yeah it makes no sense to me, to be honest. We're most certainly not
backporting multipage bvecs to stable, and if this particular patch
fixes something, it's by happy accident and we should find out why.
--
Jens Axboe