[PATCH v2] kasan: call clear_page with a match-all tag instead of changing page tag

[PATCH v2] kasan: call clear_page with a match-all tag instead of changing page tag

[Peter Collingbourne]

Instead of changing the page's tag solely in order to obtain a pointer
with a match-all tag and then changing it back again, just convert the
pointer that we get from kmap_atomic() into one with a match-all tag
before passing it to clear_page().

On a certain microarchitecture, this has been observed to cause a
measurable improvement in microbenchmark performance, presumably as a
result of being able to avoid the atomic operations on the page tag.

Signed-off-by: Peter Collingbourne <pcc@google.com>
Link: https://linux-review.googlesource.com/id/I0249822cc29097ca7a04ad48e8eb14871f80e711
---
v2:
- switched to kmap_local_page()

 include/linux/highmem.h | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 44242268f53b..212fd081b227 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -245,12 +245,10 @@ static inline void clear_highpage(struct page *page)
 
 static inline void clear_highpage_kasan_tagged(struct page *page)
 {
-	u8 tag;
+	void *kaddr = kmap_local_page(page);
 
-	tag = page_kasan_tag(page);
-	page_kasan_tag_reset(page);
-	clear_highpage(page);
-	page_kasan_tag_set(page, tag);
+	clear_page(kasan_reset_tag(kaddr));
+	kunmap_local(kaddr);
 }
 
 #ifndef __HAVE_ARCH_TAG_CLEAR_HIGHPAGE
-- 
2.39.2.637.g21b0678d19-goog

Re: [PATCH v2] kasan: call clear_page with a match-all tag instead of changing page tag

[Andrey Konovalov]

On Thu, Feb 16, 2023 at 8:59 PM Peter Collingbourne <pcc@google.com> wrote:
>
> Instead of changing the page's tag solely in order to obtain a pointer
> with a match-all tag and then changing it back again, just convert the
> pointer that we get from kmap_atomic() into one with a match-all tag
> before passing it to clear_page().
>
> On a certain microarchitecture, this has been observed to cause a
> measurable improvement in microbenchmark performance, presumably as a
> result of being able to avoid the atomic operations on the page tag.
>
> Signed-off-by: Peter Collingbourne <pcc@google.com>
> Link: https://linux-review.googlesource.com/id/I0249822cc29097ca7a04ad48e8eb14871f80e711
> ---
> v2:
> - switched to kmap_local_page()
>
>  include/linux/highmem.h | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
> index 44242268f53b..212fd081b227 100644
> --- a/include/linux/highmem.h
> +++ b/include/linux/highmem.h
> @@ -245,12 +245,10 @@ static inline void clear_highpage(struct page *page)
>
>  static inline void clear_highpage_kasan_tagged(struct page *page)
>  {
> -       u8 tag;
> +       void *kaddr = kmap_local_page(page);
>
> -       tag = page_kasan_tag(page);
> -       page_kasan_tag_reset(page);
> -       clear_highpage(page);
> -       page_kasan_tag_set(page, tag);
> +       clear_page(kasan_reset_tag(kaddr));
> +       kunmap_local(kaddr);
>  }
>
>  #ifndef __HAVE_ARCH_TAG_CLEAR_HIGHPAGE
> --
> 2.39.2.637.g21b0678d19-goog
>

Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>

Thanks!

Re: [PATCH v2] kasan: call clear_page with a match-all tag instead of changing page tag

[Catalin Marinas]

On Thu, Feb 16, 2023 at 11:59:24AM -0800, Peter Collingbourne wrote:
> Instead of changing the page's tag solely in order to obtain a pointer
> with a match-all tag and then changing it back again, just convert the
> pointer that we get from kmap_atomic() into one with a match-all tag
> before passing it to clear_page().
> 
> On a certain microarchitecture, this has been observed to cause a
> measurable improvement in microbenchmark performance, presumably as a
> result of being able to avoid the atomic operations on the page tag.
> 
> Signed-off-by: Peter Collingbourne <pcc@google.com>
> Link: https://linux-review.googlesource.com/id/I0249822cc29097ca7a04ad48e8eb14871f80e711

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Not sure how this will go upstream, maybe the mm tree? Otherwise happy
to take it through the arm64 tree.

Thanks.

-- 
Catalin