From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED3A0C433EF for ; Thu, 27 Jan 2022 02:53:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75E706B0075; Wed, 26 Jan 2022 21:53:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 70CB06B0078; Wed, 26 Jan 2022 21:53:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AD6F6B007B; Wed, 26 Jan 2022 21:53:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id 48AA66B0075 for ; Wed, 26 Jan 2022 21:53:48 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id EBF0B8249980 for ; Thu, 27 Jan 2022 02:53:47 +0000 (UTC) X-FDA: 79074546894.25.FD3F43E Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf06.hostedemail.com (Postfix) with ESMTP id 96842180005 for ; Thu, 27 Jan 2022 02:53:46 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E78E0B81EA5; Thu, 27 Jan 2022 02:53:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4020FC340E7; Thu, 27 Jan 2022 02:53:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1643252023; bh=hPXwuHX97gtrZ2qX/gY+pvj3t/ttZmCqUDNaDC2UqWk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=zmL+oDzWp8h60f/hTpsBb/c0cN3xGb1HUsjOr0f1L2FsqRE8CCVW56DND4NIB10NB 1NCvo0OI2yBh+r4RUcHO8TUwfvJlMkoCqSLI1qXFOHCulp9Ml6pBEgieNapbBd6TYO KCT87NO3QaXFALF2tX3LiALDtI36NqSBp9b/c3hI= Date: Wed, 26 Jan 2022 18:53:40 -0800 From: Andrew Morton To: Manfred Spraul Cc: LKML , Vasily Averin , cgel.zte@gmail.com, shakeelb@google.com, rdunlap@infradead.org, dbueso@suse.de, unixbhaskar@gmail.com, chi.minghao@zte.com.cn, arnd@arndb.de, Zeal Robot , linux-mm@kvack.org, 1vier1@web.de, stable@vger.kernel.org, Michal Hocko Subject: Re: [PATCH] mm/util.c: Make kvfree() safe for calling while holding spinlocks Message-Id: <20220126185340.58f88e8e1b153b6650c83270@linux-foundation.org> In-Reply-To: <20211222194828.15320-1-manfred@colorfullife.com> References: <20211222194828.15320-1-manfred@colorfullife.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: gsmbiecbzkssqox4dxf6n7eqifsc13kf X-Rspam-User: nil Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=zmL+oDzW; spf=pass (imf06.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 96842180005 X-HE-Tag: 1643252026-646554 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 22 Dec 2021 20:48:28 +0100 Manfred Spraul wrote: > One codepath in find_alloc_undo() calls kvfree() while holding a spinlock. > Since vfree() can sleep this is a bug. > > 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. > > Disadvantage: Releasing vmalloc'ed memory will be delayed a bit. I know we've been around this loop a bunch of times and deferring was considered. But I forget the conclusion. IIRC, mhocko was involved? > --- 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); > }