From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 928D31EEA31 for ; Wed, 17 Jun 2026 07:03:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781679800; cv=none; b=VQnm6qJCu1MKpBgs+atG0kSIAOl4qjpaRcsx3QmgDuy1R+OkkaX7+qPQtQVx/iPIcUaiNjbG5EJGFq1D1OH4Y19PSuZjgWLK2IDGV3KrnU6VWmJQI/wtfMeVQIQhVHh0vZWIKG4Roa8HSI0kYV7tXWaWxsmKGGUMAEZkQVS5Oyw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781679800; c=relaxed/simple; bh=0oZmMFpFA/Ti95GXUhEddDPlTLuMgQrHsNSvQg63Ja8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W53Nlmh/yLVbuVVqtfNbdaygcFN8tfx8HNW8qpewKWlhH5N05WZSeV28ccmydc5CgdZ9yz36o55LpT0DrkqlheTyCHmKvd7qhR6lIOvAHYBRGYcQ8oEbtW+5m7gp30oGo/x0qh6NL19U9S71EPLmVPZwXdDgqEVGOtIIgJiK36U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ek6qZyIl; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ek6qZyIl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F0AD31F000E9; Wed, 17 Jun 2026 07:03:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781679799; bh=FA2Y02eZezagRsG3EdVgIrWy+bRirlt7CeSWEzPBaVM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Ek6qZyIlMX059nAqQp7ILoHOYNVLln8kdnR0ej7fSY8YGO6JdSb9TYTEmaezv9ZbU /cmvc14wGOblMQZEj4ehaH5CVigL0tUh9Lgkt8DOiyy0rbYFsbEoLjAYBFHjrIDFcp ki5+SnK0GnCFdirEhPYzjgf8ymQwyWCi5in8/n1bGOnVWqMz5rlMhsfuR78GWcbimt eJj35PXdbjvX3JEb347otpUmi908r7xOP+Ocmu5XcHo5N3sH3hqfYd6TIYFcEAW1XR +L++LXZN4j01mK4W3F7Zw6gimKV75Z8Z/ZpUX+afwGnLPWgp5C0uIf1PO2NSWgSu5i R4UZi6FSQwhnw== Date: Wed, 17 Jun 2026 00:03:17 -0700 From: Dennis Zhou To: Kaitao Cheng Cc: Andrew Morton , Uladzislau Rezki , Tejun Heo , Christoph Lameter , Vlastimil Babka , Michal Hocko , muchun.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, chengkaitao Subject: Re: [PATCH v3 0/3] mm/percpu: Fix possible NOFS/NOIO reclaim recursion Message-ID: References: <20260612022648.13008-1-kaitao.cheng@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260612022648.13008-1-kaitao.cheng@linux.dev> Hello, On Fri, Jun 12, 2026 at 10:26:45AM +0800, Kaitao Cheng wrote: > From: chengkaitao > > Hi all, > > After v1 was posted, there were many different opinions, mainly around > optimizing pcpu_alloc_mutex. This v3 is intended to describe the existing > problems more clearly and provide a conventional fix approach. > > Commit 9a5b183941b5 ("mm, percpu: do not consider sleepable allocations > atomic") allowed GFP_NOFS and GFP_NOIO percpu allocations to use > pcpu_alloc_mutex and the chunk creation slow path. This restored the > allocation capability that was lost when those constrained allocations > were treated as atomic, but it also makes the percpu slow path visible > to callers from constrained reclaim contexts. > > There are two related problems. > > First, the create and populate slow paths do not fully preserve the > caller's allocation constraints. pcpu_alloc_noprof() derives pcpu_gfp from > the caller supplied GFP mask and passes it down to the percpu backing page > allocator. However, chunk creation calls pcpu_get_vm_areas(), and chunk > population can allocate temporary metadata or vmalloc page tables while > mapping backing pages. Those internal allocations can still use GFP_KERNEL, > so a caller using GFP_NOFS or GFP_NOIO can enter unconstrained FS or IO > reclaim while holding pcpu_alloc_mutex. > > One possible case is blk-cgroup after commit 5d726c4dbeed > ("blk-cgroup: fix possible deadlock while configuring policy"). > blkg_conf_prep() now serializes against blkcg_deactivate_policy() with > q->blkcg_mutex, and blkg_alloc() uses GFP_NOIO because queue freeze and IO > reclaim dependencies can otherwise deadlock. If the percpu slow path loses > that GFP_NOIO context, direct reclaim or writeback can issue IO to a frozen > queue while q->blkcg_mutex is held. > > Second, allowing sleepable GFP_NOFS/GFP_NOIO allocations to take > pcpu_alloc_mutex means that unconstrained backing allocations made under > the mutex can create an FS/IO reclaim dependency against a constrained > caller which already holds an FS or IO lock and then waits for > pcpu_alloc_mutex. > > This series fixes those issues in three steps: > > - pass the caller supplied GFP mask into pcpu_get_vm_areas() and use it > for vmalloc metadata and KASAN shadow allocations; > - pass the GFP mask through the chunk population path, including the > temporary pages array and vmalloc page table allocation scope; > - restrict percpu backing allocations performed while holding > pcpu_alloc_mutex to GFP_NOIO, so they cannot recurse into IO or FS > reclaim. > > This keeps sleepable GFP_NOFS/GFP_NOIO percpu allocations working, while > avoiding the reclaim recursion risks introduced by making those allocations > eligible for the mutex-protected slow path. > > Changes in v3: > Allow @gfp to pass __GFP_NOFAIL through. (Andrew Morton) > > Changes in v2: > - split the previous first patch into vmalloc-area creation and chunk > population changes; (Pedro Falcato) > - pass the GFP mask explicitly to pcpu_get_vm_areas(); (Pedro Falcato) > - apply the corresponding memalloc scope around vmalloc page table > allocation during chunk population; > - replace the reclaim recursion avoidance with a GFP_NOIO backing > allocation mask instead of only rejecting nested reclaim. > (Michal Hocko) > > Link to v2: > https://lore.kernel.org/all/20260604113101.89510-1-kaitao.cheng@linux.dev/ > > Link to v1: > https://lore.kernel.org/all/20260528132917.81123-1-kaitao.cheng@linux.dev/ > > Kaitao Cheng (3): > mm/vmalloc: honor GFP constraints in pcpu_get_vm_areas() > mm/percpu: honor GFP constraints when populating chunks > mm/percpu: Avoid IO/FS reclaim in backing allocations > > include/linux/vmalloc.h | 4 ++-- > mm/percpu-vm.c | 40 +++++++++++++++++++++++++++------------- > mm/percpu.c | 18 ++++++++++++------ > mm/vmalloc.c | 23 ++++++++++++----------- > 4 files changed, 53 insertions(+), 32 deletions(-) > > -- > 2.43.0 > Thanks for taking on this work. I definitely missed this earlier. I acked patches 1 and 2. I think 3 is good but the __GFP_NOFAIL warrants more discussion. I think my take back then was a single percpu allocation can trigger a large # of backing pages. As a result, while the caller may not be asking for a lot of memory, we may need substantially more to back that allocation. Given the discrepancy, that's why __GFP_NOFAIL is just mutex_lock() vs mutex_lock_killable(). Thanks, Dennis