From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 57E14383C87 for ; Fri, 13 Mar 2026 08:37:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773391028; cv=none; b=UuPDJAVnsYnQuqwANhecWeMx/TPRTTLuG52fBaaGyZDXMj4CLXVYgsIwvkY7Rn+TVjNIHWil4xHbL7ygNh9qGGSxN/W8ylRQ/pPTvAdRjXkuOMfRx0ekYhxo0IWxSQAa5kxbxW43I71T8VokNwU/WhFXb/+JnHt2ZvOrfTrBXwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773391028; c=relaxed/simple; bh=aWaICGHHci8ysQOgY5rzKmiNR5dU47bo0mNLYWbgJ08=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OlWT+5k7HIe+nJ/LUfyMSvd9NMH1io4R5bPZGc2k7Yz+mMYuaFPiANPbcS3IMgwONLG7PaDwjo++NbJDZp1icqf6IqF+wrh+afI8GlKyYlOIuadcx0BOFCo4UB+ctQ0D50SzOFmiTWFtWPEARKbjoMi+b4KhxO7LjOUsTQBN2u4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=GpSkwo/L; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="GpSkwo/L" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=QcDxLG5uEtNMt8xXPoJ/gCvBirV4EE92pOMRGDkziaE=; b=GpSkwo/L2sSnDnVnfSKWuHvFAp P6sXe6koOWOcMu0noMrnxQSEswq+HzXtaZmGp94O7Nfu0NqPmEvRG1TAAOG5xZjX4mrza+kg+2/MU GqohM0p1yGqwjUdvcuM2C3OFRENUwD73fbmW9RB+j7W6+/tQyPAx7bijo4bdIEyWFMaEjNyDQHpJF 6ZqMAI88RpbrCA4oNfWoi4wDYGGDXfBhKNUXeS4wc/5/LHjZnwZNZjAoOdVUVIElDoFtfrAH2pT7K m+2K6VouAhxn8rZIUK1H5er403cqB9/neIM+yIHwSyn+XbXbgyKlPpOmsS43F3070xdguxXcpTuWh Od8rNoPw==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w0y0s-00000002sTv-3H3S; Fri, 13 Mar 2026 08:36:55 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B6634301BD5; Fri, 13 Mar 2026 09:36:53 +0100 (CET) Date: Fri, 13 Mar 2026 09:36:53 +0100 From: Peter Zijlstra To: Dan Williams Cc: Dmitry Ilvokhin , Vlastimil Babka , Steven Rostedt , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH 1/8] mm: use zone lock guard in reserve_highatomic_pageblock() Message-ID: <20260313083653.GI606826@noisy.programming.kicks-ass.net> References: <20260306095336.a79fcc869a7f6d2b2e97501b@linux-foundation.org> <20260306130052.7da8eab3@gandalf.local.home> <20260307131641.GX606826@noisy.programming.kicks-ass.net> <20260309164516.GE606826@noisy.programming.kicks-ass.net> <69b34efd5bd1a_213210038@dwillia2-mobl4.notmuch> 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: <69b34efd5bd1a_213210038@dwillia2-mobl4.notmuch> On Thu, Mar 12, 2026 at 04:40:45PM -0700, Dan Williams wrote: > Peter Zijlstra wrote: > [..] > > However, looking at things again, I think we can get rid of that > > unconditional __GUARD_IS_ERR(), something like the below, Dan? > > I think it makes sense, do not make everyone pay the cost of > __GUARD_IS_ERR() at least until a better __GUARD_IS_ERR() comes along. > > I gave the below a run through the CXL subsystem tests which uses > conditional guards quite a bit. Worked fine, and looks good to me. > > So feel free to add a "tested by" from me. Not putting the actual tag > here so that b4 does not slurp a tag for the wrong patchset. Excellent, thanks for having a look. Let me go write it up.