From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 948B836683B for ; Tue, 2 Jun 2026 07:17:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780384626; cv=none; b=DEs0FzhWFrnTMWVphDMKEweXJaQ486Vz+8RYWdp+xhZQdUt2hp1sEtZsgVF2XbJt7V22uG06p2KwmM+NEtwrtjtPD29a1tsj8bxHliGeFDRIkLuZ4PzrITAMkBg576rsQiXlnlE3Y/YdIr6/rG0e3nQpMSDJYiUIGIIWSzn6Wn8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780384626; c=relaxed/simple; bh=LpgVf0AufS17ryjV7Kt7QJa45jYeNznHh34r2KvVtfA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ILVej0E3imx8GqZdd68NkyWYugoc1CZXy/sNscFGdV1XtrqTq7bm9ajy6vuWgwvvQWSUjbtEBJVWffUWBT4qZCkcpgfPhjkHeXI4XvrP+Yh8YO97PCRfMNXn8OlAiqQTUf1rGNSOZZfX9q5oELwvcScKOCYAa3Dp82JoigGVstE= 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=SLvtp4/b; arc=none smtp.client-ip=209.85.128.53 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="SLvtp4/b" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-490a762db7aso16248775e9.0 for ; Tue, 02 Jun 2026 00:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1780384623; x=1780989423; 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=p50DgJ115/c2k9lCONJvF062SqeHxHHdcjhkSa/vml0=; b=SLvtp4/btx5csHGxpQqisUNF0DmmbbamUeBXrpUf3Z4U0Z91xOG+IEpXSWij8lafIK 402Qovpq0oX3OPZCMnvnjPqS4d17jdCuZ7eq2dSpvHOigUCAvkmdz80mKouYUDl5MUtK 6cyLMNXTDScPacws/vdeDub0zXClSfyw2EgYEZ8njplVdvzG/kkmbccJ0c8PFnMarAl1 Z4kHzGCk0kjhQGOzTIilQM+4uDUENVB+lI8AbrpFVKu5dcPGqqaOMXWAAqWC5HCh00ya 4oGEGsaAvA9n5IdnHgQL/vm5NWxHf1K77ppwq0Ouvye21XJfSKWCBn2OEOTprGxReFUk s2nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780384623; x=1780989423; 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=p50DgJ115/c2k9lCONJvF062SqeHxHHdcjhkSa/vml0=; b=TFpLU3OpSyfEQxyFo9/uY4xdUTGimzXlC+RYSZMIPvzub/UCtYc8k0P9ciGR7+jE60 Zsebw9MZCnMswktogkJ4qHO6lTxTVsi8rqgBswpLEwbBKXVunWikTKLAp67ZRVsl6C0e +1QQ3W3b/mfxO5vcCHaHrwQs3eKediQ5PMV1tR87DHYwEUjh1H+wW3m7FaXFKHKDKnWa rCHVxQb1GWElX1OvU5dcqUOSlVSk9BFB1fv5Kt1HdetONnT0Qzh/QQZIxQ3++qEhAgq/ iKIQCGXqDEKJelu2f4y26YbrTlxq9COk+i20bKJ5/pHPfuVVFHCR3NECFlN0Zhyr02bj i+aw== X-Forwarded-Encrypted: i=1; AFNElJ8s+19lS/4HtUTHPPV6XGB6yQvT5eij72BNz9e8hMPGyF4RvdbRgqb8BZ45MACt74x3AfrDaEoIh5lKNws=@vger.kernel.org X-Gm-Message-State: AOJu0YxU1RFeR9B+v0PN8IBNXf91FArw0faJg0uDwNstekTf04/QP6vK YQKLLT8cRI1fq8YXTR/EdpO4XgQrOxfVND6NjbphaVOY4Kh9Kzyr/aO48smRJK4eMLiHpprNMtQ PXO5a X-Gm-Gg: Acq92OF5CqCVkGDvFEbgZpanlpM8wp2suPv8tmsioNJx+MY2wCwau4yifXsyixjnxRA OvQbETqSNe4jgljdvk7zwhbtJ/Bh8RbeXmGYbiW9mMG3d+U3uqJOIL/qxaBSLgtRW3NWFdk6Roi 0ryNUzNb7d++FsfgZhso/6xkn+8T0XdsV12WwqLPKcn0ZuNb1SBEIpgMl0NipbgxbX5pgIDNL0I kbTEC8kFfJnkNn4R9/Ny+s2tXugAiiSLSkXleflw26p2bnAFo24A85sO+UJ+7D3kKtcgZW4iOTo xJCHg+5MSw/4Tb2Oc/15eGIqLuBItX5F4YNoUFl52GVHs+CZyzkCV9eE2CJPRp5Tp+ELYRrTvcj 00DrIwFALXexp6rqAE799zi0jPrNajoUtHEEU9OEsg7mi1LO85NdCEKCtq5NzE+o7uNz9Q9pGW8 kCaXpSBOS368TR3y8Ryk65YFytmtNFi+LFKyaZhyOG3ejxAUc= X-Received: by 2002:a05:600c:4755:b0:490:3cb4:f1b3 with SMTP id 5b1f17b1804b1-490a293322dmr249691305e9.16.1780384622865; Tue, 02 Jun 2026 00:17:02 -0700 (PDT) Received: from localhost (109-81-85-133.rct.o2.cz. [109.81.85.133]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4909c0e8c1bsm127891955e9.3.2026.06.02.00.17.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 00:17:02 -0700 (PDT) Date: Tue, 2 Jun 2026 09:17:01 +0200 From: Michal Hocko To: Kaitao Cheng Cc: Dennis Zhou , Pedro Falcato , akpm@linux-foundation.org, tj@kernel.org, cl@gentwo.org, vbabka@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, muchun.song@linux.dev, Kaitao Cheng Subject: Re: [PATCH 1/2] mm/percpu: Preserve NOFS/NOIO scope during chunk create and populate Message-ID: References: <20260528132917.81123-1-kaitao.cheng@linux.dev> <20260528132917.81123-2-kaitao.cheng@linux.dev> <5a4aa532-77a0-436a-8f5e-1bbcf2db6bbb@linux.dev> <7e913ba8-fa91-4916-a871-66de7c80cd29@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: <7e913ba8-fa91-4916-a871-66de7c80cd29@linux.dev> On Tue 02-06-26 11:03:15, Kaitao Cheng wrote: > > > 在 2026/6/1 23:45, Michal Hocko 写道: > > On Mon 01-06-26 10:27:53, Kaitao Cheng wrote: > >> However, if we revert 9a5b183941b, it seems that all of these issues would > >> be resolved. The only downside is that the failure rate of pcpu_alloc_noprof() > >> allocations may increase, which might be acceptable. > > > > That has practical impact on some versions of iscsid which do not have > > PR_SET_IO_FLUSHER. And maybe some more so I would rather not revert > > based on a theoretical concerns which I believe is the case here. > > > > Based on the previous discussion, I think we have a way to address most > of the concurrency issues around percpu allocation. > > However, there still seems to be one remaining case that I do not yet > have a good way to solve. For example: > > 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. Correct. > Does anyone have a good suggestion for how to handle this remaining case? > Or should we simply treat all GFP_KERNEL/GFP_NOFS allocation behavior in > pcpu_alloc_noprof() as GFP_NOIO? Yes, weakening the reclaim context would work around these dependencies. This seems like a viable option as long as pcp allocations are not in latency sensitive paths and stalling them under memory pressure is acceptable. My insight into pcp allocator users is very limited so I cannot really make any judgment call here. -- Michal Hocko SUSE Labs