linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Collingbourne <pcc@google.com>
To: Andrey Konovalov <andreyknvl@gmail.com>
Cc: catalin.marinas@arm.com, linux-mm@kvack.org,
	kasan-dev@googlegroups.com,  ryabinin.a.a@gmail.com,
	linux-arm-kernel@lists.infradead.org,  vincenzo.frascino@arm.com,
	will@kernel.org, eugenis@google.com
Subject: Re: [PATCH] kasan: remove PG_skip_kasan_poison flag
Date: Mon, 27 Feb 2023 22:33:05 -0800	[thread overview]
Message-ID: <CAMn1gO6cBC6G0EC+JUM+hXmt-dsCt_BAQHn6oyT9TU6NOhYc0w@mail.gmail.com> (raw)
In-Reply-To: <CA+fCnZc-iLXbEUzYhEZtY5wHc=G3p=m-fuNdVsmovg-MT8c-6g@mail.gmail.com>

On Sun, Feb 26, 2023 at 4:20 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> On Fri, Feb 24, 2023 at 7:51 AM Peter Collingbourne <pcc@google.com> wrote:
> >
> > Code inspection reveals that PG_skip_kasan_poison is redundant with
> > kasantag, because the former is intended to be set iff the latter is
> > the match-all tag. It can also be observed that it's basically pointless
> > to poison pages which have kasantag=0, because any pages with this tag
> > would have been pointed to by pointers with match-all tags, so poisoning
> > the pages would have little to no effect in terms of bug detection.
> > Therefore, change the condition in should_skip_kasan_poison() to check
> > kasantag instead, and remove PG_skip_kasan_poison.
>
> This seems reasonable.
>
> > Signed-off-by: Peter Collingbourne <pcc@google.com>
> > Link: https://linux-review.googlesource.com/id/I57f825f2eaeaf7e8389d6cf4597c8a5821359838
> > ---
> > I sent this independently of
> > https://lore.kernel.org/all/20230224061550.177541-1-pcc@google.com/
> > because I initially thought that the patches were independent.
> > But moments after sending it, I realized that this patch depends on
> > that one, because without that patch, this patch will end up disabling
> > page poisoning altogether! But it's too late to turn them into a series
> > now; I'll do that for v2.
> >
> >  include/linux/page-flags.h     |  9 ---------
> >  include/trace/events/mmflags.h |  9 +--------
> >  mm/page_alloc.c                | 28 ++++++++--------------------
> >  3 files changed, 9 insertions(+), 37 deletions(-)
> >
> > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> > index a7e3a3405520..74f81a52e7e1 100644
> > --- a/include/linux/page-flags.h
> > +++ b/include/linux/page-flags.h
> > @@ -135,9 +135,6 @@ enum pageflags {
> >  #ifdef CONFIG_ARCH_USES_PG_ARCH_X
> >         PG_arch_2,
> >         PG_arch_3,
> > -#endif
> > -#ifdef CONFIG_KASAN_HW_TAGS
> > -       PG_skip_kasan_poison,
> >  #endif
> >         __NR_PAGEFLAGS,
> >
> > @@ -594,12 +591,6 @@ TESTCLEARFLAG(Young, young, PF_ANY)
> >  PAGEFLAG(Idle, idle, PF_ANY)
> >  #endif
> >
> > -#ifdef CONFIG_KASAN_HW_TAGS
> > -PAGEFLAG(SkipKASanPoison, skip_kasan_poison, PF_HEAD)
> > -#else
> > -PAGEFLAG_FALSE(SkipKASanPoison, skip_kasan_poison)
> > -#endif
> > -
> >  /*
> >   * PageReported() is used to track reported free pages within the Buddy
> >   * allocator. We can use the non-atomic version of the test and set
> > diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
> > index 9db52bc4ce19..c448694fc7e9 100644
> > --- a/include/trace/events/mmflags.h
> > +++ b/include/trace/events/mmflags.h
> > @@ -96,12 +96,6 @@
> >  #define IF_HAVE_PG_ARCH_X(flag,string)
> >  #endif
> >
> > -#ifdef CONFIG_KASAN_HW_TAGS
> > -#define IF_HAVE_PG_SKIP_KASAN_POISON(flag,string) ,{1UL << flag, string}
> > -#else
> > -#define IF_HAVE_PG_SKIP_KASAN_POISON(flag,string)
> > -#endif
> > -
> >  #define __def_pageflag_names                                           \
> >         {1UL << PG_locked,              "locked"        },              \
> >         {1UL << PG_waiters,             "waiters"       },              \
> > @@ -130,8 +124,7 @@ IF_HAVE_PG_HWPOISON(PG_hwpoison,    "hwpoison"      )               \
> >  IF_HAVE_PG_IDLE(PG_young,              "young"         )               \
> >  IF_HAVE_PG_IDLE(PG_idle,               "idle"          )               \
> >  IF_HAVE_PG_ARCH_X(PG_arch_2,           "arch_2"        )               \
> > -IF_HAVE_PG_ARCH_X(PG_arch_3,           "arch_3"        )               \
> > -IF_HAVE_PG_SKIP_KASAN_POISON(PG_skip_kasan_poison, "skip_kasan_poison")
> > +IF_HAVE_PG_ARCH_X(PG_arch_3,           "arch_3"        )
> >
> >  #define show_page_flags(flags)                                         \
> >         (flags) ? __print_flags(flags, "|",                             \
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 7136c36c5d01..2509b8bde8d5 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1380,7 +1380,7 @@ static inline bool should_skip_kasan_poison(struct page *page, fpi_t fpi_flags)
> >         return deferred_pages_enabled() ||
> >                (!IS_ENABLED(CONFIG_KASAN_GENERIC) &&
> >                 (fpi_flags & FPI_SKIP_KASAN_POISON)) ||
> > -              PageSkipKASanPoison(page);
> > +              page_kasan_tag(page) == 0xff;
>
> Please also update the comment above should_skip_kasan_poison.

Done in v2.

> I think we can drop #3 and #4 from that comment and instead add a more
> generic #3: "Page tags have not been assigned, as unpoisoning has been
> skipped".

I realized that the page tag will also be unassigned when the page is
first being initialized, so I decided to be more explicit in the
comment here about the circumstances where this will happen. I also
took the opportunity to remove the FPI_SKIP_KASAN_POISON flag, since I
realized that it is now also redundant with the page tag.

> >  }
> >
> >  static void kernel_init_pages(struct page *page, int numpages)
> > @@ -2511,22 +2511,13 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
> >                 /* Take note that memory was initialized by the loop above. */
> >                 init = false;
> >         }
> > -       if (!should_skip_kasan_unpoison(gfp_flags)) {
> > -               /* Try unpoisoning (or setting tags) and initializing memory. */
> > -               if (kasan_unpoison_pages(page, order, init)) {
> > -                       /* Take note that memory was initialized by KASAN. */
> > -                       if (kasan_has_integrated_init())
> > -                               init = false;
> > -                       /* Take note that memory tags were set by KASAN. */
> > -                       reset_tags = false;
> > -               } else {
> > -                       /*
> > -                        * KASAN decided to exclude this allocation from being
> > -                        * (un)poisoned due to sampling. Make KASAN skip
> > -                        * poisoning when the allocation is freed.
> > -                        */
> > -                       SetPageSkipKASanPoison(page);
> > -               }
> > +       if (!should_skip_kasan_unpoison(gfp_flags) &&
> > +           kasan_unpoison_pages(page, order, init)) {
> > +               /* Take note that memory was initialized by KASAN. */
> > +               if (kasan_has_integrated_init())
> > +                       init = false;
> > +               /* Take note that memory tags were set by KASAN. */
> > +               reset_tags = false;
> >         }
> >         /*
> >          * If memory tags have not been set by KASAN, reset the page tags to
> > @@ -2539,9 +2530,6 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
> >         /* If memory is still not initialized, initialize it now. */
> >         if (init)
> >                 kernel_init_pages(page, 1 << order);
> > -       /* Propagate __GFP_SKIP_KASAN_POISON to page flags. */
> > -       if (kasan_hw_tags_enabled() && (gfp_flags & __GFP_SKIP_KASAN_POISON))
> > -               SetPageSkipKASanPoison(page);
>
> With this removed, __GFP_SKIP_KASAN_POISON is no longer used and can
> be removed too.

Done in v2. Since the remaining flag will skip both poisoning and
unpoisoning, I decided to rename it to GFP_SKIP_KASAN.

Peter


      reply	other threads:[~2023-02-28  6:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24  6:51 Peter Collingbourne
2023-02-27  0:19 ` Andrey Konovalov
2023-02-28  6:33   ` Peter Collingbourne [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMn1gO6cBC6G0EC+JUM+hXmt-dsCt_BAQHn6oyT9TU6NOhYc0w@mail.gmail.com \
    --to=pcc@google.com \
    --cc=andreyknvl@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=eugenis@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=ryabinin.a.a@gmail.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox