| Message ID | 20230301003545.282859-2-pcc@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | kasan: bugfix and cleanup | expand |
On Tue, 28 Feb 2023 16:35:44 -0800 Peter Collingbourne <pcc@google.com> wrote: > This reverts commit 487a32ec24be819e747af8c2ab0d5c515508086a. > > The should_skip_kasan_poison() function reads the PG_skip_kasan_poison > flag from page->flags. However, this line of code in free_pages_prepare(): > > page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP; > > clears most of page->flags, including PG_skip_kasan_poison, before calling > should_skip_kasan_poison(), which meant that it would never return true > as a result of the page flag being set. Therefore, fix the code to call > should_skip_kasan_poison() before clearing the flags, as we were doing > before the reverted patch. What are the user visible effects of this change? > Cc: <stable@vger.kernel.org> # 6.1 Especially if it's cc:stable. Thanks.
On Wed, Mar 8, 2023 at 5:46 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Tue, 28 Feb 2023 16:35:44 -0800 Peter Collingbourne <pcc@google.com> wrote: > > > This reverts commit 487a32ec24be819e747af8c2ab0d5c515508086a. > > > > The should_skip_kasan_poison() function reads the PG_skip_kasan_poison > > flag from page->flags. However, this line of code in free_pages_prepare(): > > > > page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP; > > > > clears most of page->flags, including PG_skip_kasan_poison, before calling > > should_skip_kasan_poison(), which meant that it would never return true > > as a result of the page flag being set. Therefore, fix the code to call > > should_skip_kasan_poison() before clearing the flags, as we were doing > > before the reverted patch. > > What are the user visible effects of this change? > > > Cc: <stable@vger.kernel.org> # 6.1 > > Especially if it's cc:stable. This fixes a measurable performance regression introduced in the reverted commit, where munmap() takes longer than intended if HW tags KASAN is supported and enabled at runtime. Without this patch, we see a single-digit percentage performance regression in a particular mmap()-heavy benchmark when enabling HW tags KASAN, and with the patch, there is no statistically significant performance impact when enabling HW tags KASAN. That can be added as a paragraph to the end of my commit message, or I can send a v4 if you prefer. Peter
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index ac1fc986af44..7136c36c5d01 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1398,6 +1398,7 @@ static __always_inline bool free_pages_prepare(struct page *page, unsigned int order, bool check_free, fpi_t fpi_flags) { int bad = 0; + bool skip_kasan_poison = should_skip_kasan_poison(page, fpi_flags); bool init = want_init_on_free(); VM_BUG_ON_PAGE(PageTail(page), page); @@ -1470,7 +1471,7 @@ static __always_inline bool free_pages_prepare(struct page *page, * With hardware tag-based KASAN, memory tags must be set before the * page becomes unavailable via debug_pagealloc or arch_free_page. */ - if (!should_skip_kasan_poison(page, fpi_flags)) { + if (!skip_kasan_poison) { kasan_poison_pages(page, order, init); /* Memory is already initialized if KASAN did it internally. */