| Message ID | 20220915150417.722975-28-glider@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add KernelMemorySanitizer infrastructure | expand |
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 :) )
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))
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(+)