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 D14A8C433FE for ; Thu, 27 Jan 2022 08:25:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F7196B0071; Thu, 27 Jan 2022 03:25:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A7BD6B0072; Thu, 27 Jan 2022 03:25:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 096DC6B0073; Thu, 27 Jan 2022 03:25:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0104.hostedemail.com [216.40.44.104]) by kanga.kvack.org (Postfix) with ESMTP id EF3506B0071 for ; Thu, 27 Jan 2022 03:25:51 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9907E944D6 for ; Thu, 27 Jan 2022 08:25:51 +0000 (UTC) X-FDA: 79075383702.09.0DD71F8 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf27.hostedemail.com (Postfix) with ESMTP id 1761F40006 for ; Thu, 27 Jan 2022 08:25:50 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 97F941F782; Thu, 27 Jan 2022 08:25:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1643271949; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9Q0FkSQmm1fWntRs1C5a+2X1IC7ibgX3XsHWMAzrK8A=; b=d29mOoQK93zcDc6AY8VZqcYav5jp45qVch2NDpZxg5up8oPsZtZz9iZd0+LwB8l7Bqv8TY YB9TQdlzSXwxRuhbKWYaZQZGGFNBcIf/hdxTgwq/hG0Wk0YdHZ/TTdHlrN79DatiOy5Rou fGkimGB+7UI2sAfmcjwFZyC7OfUzo6k= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 5285CA3B81; Thu, 27 Jan 2022 08:25:49 +0000 (UTC) Date: Thu, 27 Jan 2022 09:25:48 +0100 From: Michal Hocko To: Manfred Spraul Cc: Andrew Morton , 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 Subject: Re: [PATCH] mm/util.c: Make kvfree() safe for calling while holding spinlocks Message-ID: References: <20211222194828.15320-1-manfred@colorfullife.com> <20220126185340.58f88e8e1b153b6650c83270@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1761F40006 X-Stat-Signature: 9a4ijjkatxmqk7fy8h1ahdneyedbffd7 X-Rspam-User: nil Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=d29mOoQK; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1643271950-346091 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 Thu 27-01-22 06:59:50, Manfred Spraul wrote: > Hi Andrew, > > On 1/27/22 03:53, Andrew Morton wrote: > > 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? > > I do not remember a mail from mhocko. I do not remember either. > > Shakeel proposed to use the approach from Chi. > > Decision: https://marc.info/?l=linux-kernel&m=164132032717757&w=2 And I would agree with Shakeel and go with the original change to the ipc code. That is trivial and without any other side effects like this one. I bet nobody has evaluated what the undconditional deferred freeing has. At least changelog doesn't really dive into that more than a very vague statement that this will happen. > With Reviewed-by: > > https://marc.info/?l=linux-kernel&m=164132744522325&w=2 > > > --- 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); > > > } > -- Michal Hocko SUSE Labs