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 44A7118CC13 for ; Thu, 4 Jun 2026 19:07:09 +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=1780600031; cv=none; b=pmxfqr/2aG3gv6jKM1tR/6NhS4SbYTIIpBlywm+6YxkSP2lQ+BwjKAdTXgXvhZLhvbrqGa/jr1G+7QcgMnjKeUYpPCYLF7tHMP03GjKcZOte+jBpWtwdkrRjy8dODpDjg6FV3BYVjxVx+VfXlc7N0nDXz9wGe6fU+S6sfj91+og= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780600031; c=relaxed/simple; bh=oO+SBkAi/2dYDGCD49L9YXel2ID7UsEW3I1OgWUPMlw=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=KIny3+TuZ4tEXh6irmX+dVrLJ2j8Wh8k0qEGLMXsRhsZHuShBTp+YJeQIUEnF298ZylL8Wysx2G2+c4gMlM3y0xVL9ctDwwEpmLqNUyfnKAfplgNqXLeOMAWrWjuaIcv060lnoZ+3c0fZCAYQt+7xc0bFZRntWpgotDFA9sVizY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=X95QMe1D; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="X95QMe1D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70F391F00893; Thu, 4 Jun 2026 19:07:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1780600029; bh=tPNx0ceI7jZ/wZ7ZeuZoSeTQHDWTmdvA1iGMDZOoaVw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=X95QMe1DQa/bJlL5J7XNBmh5eWEZZpUvPc5iH6tAfn7srWo9BFzIMrHrRCpQqEYT7 yIS85dWrunomN7GvekNplK3OwKOtRGBKYDkIpVnVNS4kCOZH8lG3DsRoXWUrG1xTKX PvIP+1YCFjvAqfzbl503rus1E0k4bL1Lh8whxHQo= Date: Thu, 4 Jun 2026 12:07:09 -0700 From: Andrew Morton To: Kaitao Cheng Cc: Dennis Zhou , Tejun Heo , Christoph Lameter , Uladzislau Rezki , Pedro Falcato , Vlastimil Babka , Michal Hocko , muchun.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kaitao Cheng Subject: Re: [PATCH v2 3/3] mm/percpu: Avoid IO/FS reclaim in backing allocations Message-Id: <20260604120709.445c027637b3ad72ad13279a@linux-foundation.org> In-Reply-To: <20260604113101.89510-4-kaitao.cheng@linux.dev> References: <20260604113101.89510-1-kaitao.cheng@linux.dev> <20260604113101.89510-4-kaitao.cheng@linux.dev> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Thu, 4 Jun 2026 19:31:01 +0800 Kaitao Cheng wrote: > From: Kaitao Cheng > > Commit 9a5b183941b5 ("mm, percpu: do not consider sleepable > allocations atomic") allows sleepable GFP_NOIO and GFP_NOFS percpu > allocations to take pcpu_alloc_mutex. This avoids premature allocation > failures, but it also makes the mutex visible to callers from constrained > IO/FS contexts. > > Thread A calls pcpu_alloc_noprof() with GFP_KERNEL and takes > pcpu_alloc_mutex. Since the internal allocation is not constrained by > NOFS, it may enter FS reclaim while still holding pcpu_alloc_mutex, > creating a dependency like: pcpu_alloc_mutex -> fs_reclaim -> FS lock > > At the same time, Thread B may already hold an FS lock and then call > pcpu_alloc_noprof() with GFP_NOFS. It will try to acquire > pcpu_alloc_mutex and block, creating the reverse dependency: > FS lock -> pcpu_alloc_mutex > > This can still form a potential deadlock cycle. > > Avoid the dependency by restricting percpu backing allocations to GFP_NOIO. > The public allocation still uses the caller's GFP context to decide whether > it may block, but the internal memory allocations performed while > pcpu_alloc_mutex is held cannot recurse into IO or FS reclaim. > > ... > > --- a/mm/percpu.c > +++ b/mm/percpu.c > @@ -1726,9 +1726,8 @@ static void pcpu_alloc_tag_free_hook(struct pcpu_chunk *chunk, int off, size_t s > * @gfp: allocation flags > * > * Allocate percpu area of @size bytes aligned at @align. If @gfp doesn't > - * contain %GFP_KERNEL, the allocation is atomic. If @gfp has __GFP_NOWARN > - * then no warning will be triggered on invalid or failed allocation > - * requests. > + * allow blocking, the allocation is atomic. If @gfp has __GFP_NOWARN then no > + * warning will be triggered on invalid or failed allocation requests. > * > * RETURNS: > * Percpu pointer to the allocated area on success, NULL on failure. > @@ -1749,8 +1748,14 @@ void __percpu *pcpu_alloc_noprof(size_t size, size_t align, bool reserved, > size_t bits, bit_align; > > gfp = current_gfp_context(gfp); > - /* whitelisted flags that can be passed to the backing allocators */ > - pcpu_gfp = gfp & (GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN); > + /* > + * Whitelisted flags that can be passed to the backing allocators. We're supposed to say "allowlist". > + * Backing allocations under pcpu_alloc_mutex must not recurse into > + * IO/FS reclaim. Otherwise a GFP_KERNEL caller holding the mutex can > + * block on reclaim while a GFP_NOIO/NOFS caller holding an IO/FS lock > + * waits for the same mutex. > + */ > + pcpu_gfp = gfp & (GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN); AI review (https://sashiko.dev/#/patchset/20260604113101.89510-1-kaitao.cheng@linux.dev) asked why we're currently removing __GFP_NOFAIL here. There are probably good reasons for this, but it would be good to describe them in that comment.