All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Shakeel Butt <shakeelb@google.com>
Cc: Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
	Roman Gushchin <guro@fb.com>, Wang Hai <wanghai38@huawei.com>,
	Muchun Song <songmuchun@bytedance.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH] slub: fix kmalloc_pagealloc_invalid_free unit test
Date: Mon, 2 Aug 2021 16:52:23 -0700	[thread overview]
Message-ID: <YQiFNwdFb4DRwykI@archlinux-ax161> (raw)
In-Reply-To: <20210802180819.1110165-1-shakeelb@google.com>

On Mon, Aug 02, 2021 at 11:08:18AM -0700, Shakeel Butt wrote:
> The unit test kmalloc_pagealloc_invalid_free makes sure that for the
> higher order slub allocation which goes to page allocator, the free is
> called with the correct address i.e. the virtual address of the head
> page.
> 
> The commit f227f0faf63b ("slub: fix unreclaimable slab stat for bulk
> free") unified the free code paths for page allocator based slub
> allocations but instead of using the address passed by the caller, it
> extracted the address from the page. Thus making the unit test
> kmalloc_pagealloc_invalid_free moot. So, fix this by using the address
> passed by the caller.
> 
> Should we fix this? I think yes because dev expect kasan to catch these
> type of programming bugs.
> 
> Fixes: f227f0faf63b ("slub: fix unreclaimable slab stat for bulk free")
> Signed-off-by: Shakeel Butt <shakeelb@google.com>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Roman Gushchin <guro@fb.com>
> Cc: Muchun Song <songmuchun@bytedance.com>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Andrew Morton <akpm@linux-foundation.org>

Thank you for the quick fix! It passes my tests on arm64 and x86_64 in
QEMU with a few different clang versions.

Tested-by: Nathan Chancellor <nathan@kernel.org>

> ---
>  mm/slub.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index af984e4990e8..60aeedc436d5 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3236,12 +3236,12 @@ struct detached_freelist {
>  	struct kmem_cache *s;
>  };
>  
> -static inline void free_nonslab_page(struct page *page)
> +static inline void free_nonslab_page(struct page *page, void *object)
>  {
>  	unsigned int order = compound_order(page);
>  
>  	VM_BUG_ON_PAGE(!PageCompound(page), page);
> -	kfree_hook(page_address(page));
> +	kfree_hook(object);
>  	mod_lruvec_page_state(page, NR_SLAB_UNRECLAIMABLE_B, -(PAGE_SIZE << order));
>  	__free_pages(page, order);
>  }
> @@ -3282,7 +3282,7 @@ int build_detached_freelist(struct kmem_cache *s, size_t size,
>  	if (!s) {
>  		/* Handle kalloc'ed objects */
>  		if (unlikely(!PageSlab(page))) {
> -			free_nonslab_page(page);
> +			free_nonslab_page(page, object);
>  			p[size] = NULL; /* mark object processed */
>  			return size;
>  		}
> @@ -4258,7 +4258,7 @@ void kfree(const void *x)
>  
>  	page = virt_to_head_page(x);
>  	if (unlikely(!PageSlab(page))) {
> -		free_nonslab_page(page);
> +		free_nonslab_page(page, object);
>  		return;
>  	}
>  	slab_free(page->slab_cache, page, object, NULL, 1, _RET_IP_);
> -- 
> 2.32.0.554.ge1b32706d8-goog
> 
> 

  reply	other threads:[~2021-08-02 23:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 18:08 [PATCH] slub: fix kmalloc_pagealloc_invalid_free unit test Shakeel Butt
2021-08-02 18:08 ` Shakeel Butt
2021-08-02 23:52 ` Nathan Chancellor [this message]
2021-08-03  3:30 ` Roman Gushchin

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=YQiFNwdFb4DRwykI@archlinux-ax161 \
    --to=nathan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=guro@fb.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=shakeelb@google.com \
    --cc=songmuchun@bytedance.com \
    --cc=vbabka@suse.cz \
    --cc=wanghai38@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.