From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 713F41E4AF for ; Fri, 19 Jun 2026 06:02:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781848956; cv=none; b=nz3ZHRQZzEnFQBkOhqa+SRmozOr3JbncVkAd3lVpYV92YNaLcrBAAO4x8+zqt4ouRzyFaPg9EBTF4wwrthDcP28ISm/FPS+yHK+hrDYOnnAexgkphbRfLZxVfQDKgvuaOqRdUdsjPCOKXvbTHMXYHZqS+qFu89M/j66qkoo9tiI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781848956; c=relaxed/simple; bh=7kRifdpu/sb5q9xlr58u5LHu/sS/RyMz3C2qeCp2hwU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RYpFVoTxncRfS5XQZSbq47rU+RfINSvPeJ6yXTaxNDqTUID6BxAffoRxAg9FiESQDizkkqpESBjyS/yBe1LRTbuUWvAxZ0V51Sqk34bk/kg4VotmuVq0WOsC9PFPdTuB+92jf/AzUokHOfk7VplliysdPbs7ppPrO7Tnga2lzWM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=I29AdP8b; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="I29AdP8b" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4921e4dd62dso12642445e9.0 for ; Thu, 18 Jun 2026 23:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1781848953; x=1782453753; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=fn5DPboWJkI9U1kVq9yhwYF9FI1OrZduwolmjIav4rk=; b=I29AdP8bwnUdpz12XXyHKQDM4xpEu3URhHH+isxapfi23lliEM+MiOqz2MICHLLegP gkaS1u+0xtBkuZCeiUkhikRPw1bkIVwyfQVRPnrtKilqZSx4qEXPGYMTUFoQ1MbQeFpB bHtyjBumMAbIuZhVumGTsqoPpDfpSn8SlyAkqKym+HGWjU/rgpZ+Z1eTStLFM3JdYr2t BD8b4P1V9oe4d5Eskjluv8ZnfCmHKqGXYcJtUmpfquE5azjAoaaKxrfh2ho2KDpmk83F 2D7Ufe134x04tS77sSqujTnTKkDE5eaZmyG/svfo99LiafQeUAQ7eajLZiXd0f4Zme2o Omcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781848953; x=1782453753; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fn5DPboWJkI9U1kVq9yhwYF9FI1OrZduwolmjIav4rk=; b=I+DOCw7FJPSH+a5xXkaacNQiGL2D15E84Xj0rAvm08B7lfU3WiX0Vlt+U5/sl0Rda3 OYyCNabuCMImP6T4a/O1oJpLF4vHBHoRe36uqs7JHf+QBbtDJ7gHWBEUnxbz2noVfMt8 1jXbVlELc4+4QmTinYpDPK8FZPM1U4JoJc1xniQ2fCKgagS3ziRRvMGB+EdmMQ8BezqV th4ubcJGB2Dwvl5poes71UrP498fGAuevJzEmirxEU6PV7e46zID0Uh86hRbAPt3j/xJ Ked9XxTG6kfMue9sn9ECh9r+6XTbBOG7xQrFc/nTIeQ+a6oA1DSmxTYyezid0A1v0ioo U6gA== X-Forwarded-Encrypted: i=1; AFNElJ+aY64J28mymxqPcUVU0QoTc2AkBdsSSQCr1xosf0A9VH4WiNpvt/pmK1elQJevjsN1jD6rfL8Y2VUiBjk=@vger.kernel.org X-Gm-Message-State: AOJu0YyP2syEp/H0wiOurNjdHOc+0CSNPArG1Lk/NH0E9mvKRLob0U6t MvCVhs6/9SbiuCiskrHi2xyq8Sq2kUS5Qy+4Db8dj7GoxoUGsRau4ZfcHkFcAYl6sRg= X-Gm-Gg: AfdE7ckymcunwxEqsqhlFJNNqceyF4mKBeOJeXBSWCcsssu2yKO4kImiyEr7zw5Tjzm 1LqyqjeeGf2LkctoPV0sGANfNDkO4a8LFmIRBWApuk8yFFfM1+y1KqZ5Jl6KpYDDzIBVzIfCboo XR0kXBDuIlKyiwP1xWnIgaclmu+SL23Kn04/aZ79ZtuLQXY8SOoDLouK4CHR8h2OdCiRVTSqnO8 WIed9UgJJNClYaxQuUME5ntMndrzWjG2MKf+Qvbj5KNfZpOeTyV0sXe1UPBQQskjbDMBNMjS9sN NqUAAovkW3qCn8XA1dBsQ0KZ6pse8W3w6YyGkfScSbDhaRR7rBkGaM7ztSBGONwCttYO7qQD382 mFUKtUfInZ/mVkHAT7DEJlqNGQG4zX5iLO8d/UewhI512q4c60b16uOLXr/dyGcdSwv9yWioct8 xQHA9z8KHxkXB+ma9nlk+6PDZ2Fw== X-Received: by 2002:a05:600c:8218:b0:492:1e36:9a90 with SMTP id 5b1f17b1804b1-49240a598e5mr20386885e9.18.1781848952752; Thu, 18 Jun 2026 23:02:32 -0700 (PDT) Received: from localhost (109-81-26-193.rct.o2.cz. [109.81.26.193]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49240f054e3sm32544205e9.2.2026.06.18.23.02.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2026 23:02:32 -0700 (PDT) Date: Fri, 19 Jun 2026 08:02:30 +0200 From: Michal Hocko To: Kaitao Cheng Cc: Andrew Morton , Uladzislau Rezki , Dennis Zhou , Tejun Heo , Christoph Lameter , Vlastimil Babka , Pedro Falcato , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kaitao Cheng Subject: Re: [PATCH v4 4/4] mm/percpu: Avoid IO/FS reclaim in backing allocations Message-ID: References: <20260618130414.96383-1-kaitao.cheng@linux.dev> <20260618130414.96383-5-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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri 19-06-26 08:21:51, Kaitao Cheng wrote: > 在 2026/6/19 02:03, Michal Hocko 写道: > > On Thu 18-06-26 21:04:14, 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. > >> > >> Fixes: 9a5b183941b5 ("mm, percpu: do not consider sleepable allocations atomic") > >> Signed-off-by: Kaitao Cheng > > > > This seems like the only viable short term fix but long term it would be > > really better to make allocations outside of the lock. > > Acked-by: Michal Hocko > > > > Minor nit > >> @@ -1749,8 +1748,17 @@ 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); > >> + /* > >> + * Allowlisted flags that can be passed to the backing allocators. > >> + * 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. > >> + * > >> + * Do not pass __GFP_NOFAIL. A small percpu allocation may need many > >> + * backing pages, making nofail reclaim too costly under NOIO/NOFS. > >> + */ > >> + pcpu_gfp = gfp & (GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN); > > > > GFP_NOIO, NOFS are negative masks in the sense that that are lacking > > flags so the overal intention would be more readable IMHO in the > > following form > > pcpu_gfp = gfp & (GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN) > > pcpu_gfp &= ~(__GFP_IO | __GFP_FS) > > This looks a bit redundant. The newly added comment already makes the > intent clear, and the extra code seems to serve only as another hint to > readers, which is essentially the same role as the comment. > > GFP_NOIO already excludes __GFP_IO and __GFP_FS, so its semantics are > clear enough. It should not be misleading, and it is also more concise. I will certainly not insist, but this is a generally used pattern to drop IO and FS flags. So if you want to grep for the pattern you will not miss this place. Comment _is_ useful but harder to grep for. > > >> is_atomic = !gfpflags_allow_blocking(gfp); > >> do_warn = !(gfp & __GFP_NOWARN); > >> > >> -- > >> 2.50.1 (Apple Git-155) > > > > -- > Thanks > Kaitao Cheng -- Michal Hocko SUSE Labs