linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dbueso@suse.de>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vasily Averin <vvs@virtuozzo.com>,
	cgel.zte@gmail.com, shakeelb@google.com, rdunlap@infradead.org,
	unixbhaskar@gmail.com, chi.minghao@zte.com.cn, arnd@arndb.de,
	Zeal Robot <zealci@zte.com.cn>,
	linux-mm@kvack.org, 1vier1@web.de, stable@vger.kernel.org,
	mhocko@kernel.org, willy@infradead.org, vbabka@suse.cz
Subject: Re: [PATCH] mm/util.c: Make kvfree() safe for calling while holding spinlocks
Date: Wed, 22 Dec 2021 19:40:17 -0800	[thread overview]
Message-ID: <a3212f020c7e8e2efbeffbb5e0a02424@suse.de> (raw)
In-Reply-To: <20211222194828.15320-1-manfred@colorfullife.com>

Cc'ing more mm folks.

On 2021-12-22 11:48, Manfred Spraul wrote:
> One codepath in find_alloc_undo() calls kvfree() while holding a 
> spinlock.
> Since vfree() can sleep this is a bug.

afaict the only other offender is devx_async_cmd_event_destroy_uobj(), 
in drivers/infiniband/hw/mlx5/devx.c. I was expecting to find more, 
actually.

> Previously, the code path used kfree(), and kfree() is safe to be 
> called
> while holding a spinlock.
> 
> Minghao proposed to fix this by updating find_alloc_undo().
> 
> Alternate proposal to fix this: Instead of changing find_alloc_undo(),
> change kvfree() so that the same rules as for kfree() apply:
> Having different rules for kfree() and kvfree() just asks for bugs.

I agree that it is best to have the same atomic semantics across all 
family of calls.

> 
> Disadvantage: Releasing vmalloc'ed memory will be delayed a bit.

I would not expect the added latency to be a big deal unless under 
serious memory pressure, for which case things are already fragile to 
begin with. Furthermore users of kvfree() are already warned that this 
is the slower choice. Feel free to add my:

Acked-by: Davidlohr Bueso <dbueso@suse.de>

> 
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Reported-by: Minghao Chi <chi.minghao@zte.com.cn>
> Link:
> https://lore.kernel.org/all/20211222081026.484058-1-chi.minghao@zte.com.cn/
> Fixes: fc37a3b8b438 ("[PATCH] ipc sem: use kvmalloc for sem_undo 
> allocation")
> Cc: stable@vger.kernel.org
> Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
> ---
>  mm/util.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/util.c b/mm/util.c
> index 741ba32a43ac..7f9181998835 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -610,12 +610,12 @@ EXPORT_SYMBOL(kvmalloc_node);
>   * It is slightly more efficient to use kfree() or vfree() if you are 
> certain
>   * that you know which one to use.
>   *
> - * Context: Either preemptible task context or not-NMI interrupt.
> + * Context: Any context except NMI interrupt.
>   */
>  void kvfree(const void *addr)
>  {
>  	if (is_vmalloc_addr(addr))
> -		vfree(addr);
> +		vfree_atomic(addr);
>  	else
>  		kfree(addr);
>  }

  reply	other threads:[~2021-12-23  3:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-22 19:48 [PATCH] mm/util.c: Make kvfree() safe for calling while holding spinlocks Manfred Spraul
2021-12-23  3:40 ` Davidlohr Bueso [this message]
2021-12-23  7:21 ` Vasily Averin
2021-12-23 11:52   ` Manfred Spraul
2021-12-23 12:34     ` Vasily Averin
2021-12-25 18:54 ` Uladzislau Rezki
2021-12-25 22:58   ` Matthew Wilcox
2021-12-26 17:57     ` Uladzislau Rezki
2021-12-28 19:45       ` Uladzislau Rezki
2021-12-28 20:04         ` Manfred Spraul
2021-12-28 20:26           ` Uladzislau Rezki
2022-01-27  2:53 ` Andrew Morton
2022-01-27  5:59   ` Manfred Spraul
2022-01-27  8:25     ` Michal Hocko
2022-01-27 15:54       ` Uladzislau Rezki

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=a3212f020c7e8e2efbeffbb5e0a02424@suse.de \
    --to=dbueso@suse.de \
    --cc=1vier1@web.de \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=cgel.zte@gmail.com \
    --cc=chi.minghao@zte.com.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=manfred@colorfullife.com \
    --cc=mhocko@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=shakeelb@google.com \
    --cc=stable@vger.kernel.org \
    --cc=unixbhaskar@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=vvs@virtuozzo.com \
    --cc=willy@infradead.org \
    --cc=zealci@zte.com.cn \
    /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;
as well as URLs for NNTP newsgroup(s).