KMSAN metadata for adjacent physical pages may not be adjacent,
therefore accessing such pages together may lead to metadata
corruption.
We disable merging pages in biovec to prevent such corruptions.

Signed-off-by: Alexander Potapenko <glider@google.com>
---

Link: https://linux-review.googlesource.com/id/Iece16041be5ee47904fbc98121b105e5be5fea5c
---
 block/blk.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/block/blk.h b/block/blk.h
index d7142c4d2fefb..af02b93c1dba5 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -88,6 +88,13 @@ static inline bool biovec_phys_mergeable(struct request_queue *q,
 	phys_addr_t addr1 = page_to_phys(vec1->bv_page) + vec1->bv_offset;
 	phys_addr_t addr2 = page_to_phys(vec2->bv_page) + vec2->bv_offset;
 
+	/*
+	 * Merging adjacent physical pages may not work correctly under KMSAN
+	 * if their metadata pages aren't adjacent. Just disable merging.
+	 */
+	if (IS_ENABLED(CONFIG_KMSAN))
+		return false;
+
 	if (addr1 + vec1->bv_len != addr2)
 		return false;
 	if (xen_domain() && !xen_biovec_phys_mergeable(vec1, vec2->bv_page))
-- 
2.37.2.789.g6183377224-goog

On Thu, 15 Sep 2022 17:04:01 +0200 Alexander Potapenko <glider@google.com> wrote:

> KMSAN metadata for adjacent physical pages may not be adjacent,
> therefore accessing such pages together may lead to metadata
> corruption.
> We disable merging pages in biovec to prevent such corruptions.
> 
> ...
>
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -88,6 +88,13 @@ static inline bool biovec_phys_mergeable(struct request_queue *q,
>  	phys_addr_t addr1 = page_to_phys(vec1->bv_page) + vec1->bv_offset;
>  	phys_addr_t addr2 = page_to_phys(vec2->bv_page) + vec2->bv_offset;
>  
> +	/*
> +	 * Merging adjacent physical pages may not work correctly under KMSAN
> +	 * if their metadata pages aren't adjacent. Just disable merging.
> +	 */
> +	if (IS_ENABLED(CONFIG_KMSAN))
> +		return false;
> +
>  	if (addr1 + vec1->bv_len != addr2)
>  		return false;
>  	if (xen_domain() && !xen_biovec_phys_mergeable(vec1, vec2->bv_page))

What are the runtime effects of this?  In other words, how much
slowdown is this likely to cause in a reasonable worst-case?

On Thu, Sep 15, 2022 at 10:58 PM Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> On Thu, 15 Sep 2022 17:04:01 +0200 Alexander Potapenko <glider@google.com> wrote:
>
> > KMSAN metadata for adjacent physical pages may not be adjacent,
> > therefore accessing such pages together may lead to metadata
> > corruption.
> > We disable merging pages in biovec to prevent such corruptions.
> >
> > ...
> >
> > --- a/block/blk.h
> > +++ b/block/blk.h
> > @@ -88,6 +88,13 @@ static inline bool biovec_phys_mergeable(struct request_queue *q,
> >       phys_addr_t addr1 = page_to_phys(vec1->bv_page) + vec1->bv_offset;
> >       phys_addr_t addr2 = page_to_phys(vec2->bv_page) + vec2->bv_offset;
> >
> > +     /*
> > +      * Merging adjacent physical pages may not work correctly under KMSAN
> > +      * if their metadata pages aren't adjacent. Just disable merging.
> > +      */
> > +     if (IS_ENABLED(CONFIG_KMSAN))
> > +             return false;
> > +
> >       if (addr1 + vec1->bv_len != addr2)
> >               return false;
> >       if (xen_domain() && !xen_biovec_phys_mergeable(vec1, vec2->bv_page))
>
> What are the runtime effects of this?  In other words, how much
> slowdown is this likely to cause in a reasonable worst-case?

To be honest, I have no idea. KMSAN already introduces a lot of
runtime overhead to every memory access, it's unlikely that disabling
some filesystem optimization will add anything on top of that.
Anyway, KMSAN is a debugging tool that is not supposed to be used in
production (there's a big boot-time warning about that now :) )

-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg