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 16EDE407CF6 for ; Thu, 30 Jul 2026 11:17:24 +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=1785410246; cv=none; b=WqfofAPTp2TnKp03ZxESYIcnFHT5JI1TkuzAz3PzZ2P4CJjT16LvWHCNWatCrFoCj3O1lSyIp/olbtFi8omy7B63viOJJiWyDO3z5GtGVszK5+zTzGJsafOyahgUmU/gx/Ja3aztLj6KIgUTfq0SW67K9bNUlsjXmyvsWrHHU/Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785410246; c=relaxed/simple; bh=klEoplTjiFqp556czapQXzjyUE8zZ0Q/Cd3jFnUvHd8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k7sS1/JqCppy/unAEji8sWDH3Gl+YFcRbWS4y/naRoDI4F8udxJSir0LWRft3U3+AmeBM2F3i/924kDYmBbwXa3SdEK2hNi58vwvuY9QRwOFgHfxTd/8fGcd7Qt09nh4cuNMr/s/guNgFFXVqKGYnkbtA4QtGHB3miNT8ArwYCM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dJSn2uKq; 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="dJSn2uKq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9288D1F00A3A; Thu, 30 Jul 2026 11:17:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785410244; bh=J0EIPu9PN0yu7q+s4rPgyOAd/4Zfoyra3jhu843lc4c=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=dJSn2uKqy4X1N8KpDU9tw0HfzTaEO2Pj6MHEBeEXgjSVM5Xbr7EZVdWtj3WSxKFM5 adOwt+KFYRhEgEorTkdoEUV7gHnv13kdZqukzTfqtuVipJ3B5uCKc3XoasaVAVqSzl hQ7h+egoWcwwlM6k2yeAtbaMFRVC9VrCHMsnv2G7Sohhnuzv5XptqxN+RKP+SvuNFE Rd6g54eipNLuFBelDtsKnFmkiMA5vXjQRdmTnMnWHcgsw+DIwT0iXkAAar6JrjxrRZ 2PTQK3hHN41LuVF7FEfbokbmneesooU2GWZC6RfcrLXZqvmIP8r6Qfq9z49zi0ipRm eODOrYYcUDPEA== Date: Thu, 30 Jul 2026 14:17:13 +0300 From: Mike Rapoport To: Peter Zijlstra Cc: Dave Hansen , linux-kernel@vger.kernel.org, Andy Lutomirski , Borislav Petkov , David Hildenbrand , Ingo Molnar , Jason Gunthorpe , Juergen Gross , Kevin Tian , Kiryl Shutsemau , "Liam R. Howlett" , Lorenzo Stoakes , Lu Baolu , "H. Peter Anvin" , Shakeel Butt , Suren Baghdasaryan , Thomas Gleixner , Toshi Kani , Vlastimil Babka , Will Deacon , linux-mm@kvack.org, x86@kernel.org Subject: Re: [PATCH 3/3] x86/mm: Fix and document DEBUG_PAGEALLOC Message-ID: References: <20260729110807.797920433@infradead.org> <20260729111119.604452135@infradead.org> <20260729144838.GM651302@noisy.programming.kicks-ass.net> <20260730104333.GE751831@noisy.programming.kicks-ass.net> 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: <20260730104333.GE751831@noisy.programming.kicks-ass.net> On Thu, Jul 30, 2026 at 12:43:33PM +0200, Peter Zijlstra wrote: > On Wed, Jul 29, 2026 at 10:07:27PM +0300, Mike Rapoport wrote: > > > > > I like my version with your comments added there more as it localizes the > > > > DEBUG_PAGEALLOC exception in the lock wrappers. > > > > > > So I don't like removing cpa_lock entirely; it is still serializing cpa > > > > I meant static inline cpa_lock(), not removing it entirely. > > With your comment why DEBUG_PAGEALLOC is special. > > That is, I despise the whole: > > if (!debug_pagealloc_enabled()) > spin_lock(&cpa_lock); > > with a passion. It blanked kills cpa_lock as whole and changes the rules > for everyone when debug_pagealloc is on. > > cpa_lock ensures that concurrent cpa() calls on an overlapping region > have a well defined outcome. By removing it entirely you can get random > state. > > In practise this isn't likely to matter, but relaxing this for a debug > option is insane. Debug stuff should tighten rules, not relax them. In practice it's the same, either the thread that won the race for lock updates the pte or just the first one to get to actual set_pte and it's pretty random for overlapping regions anyway. But I can see your point. Anyway, we need Lorenzo's fixes from the set I sent [1] to protect against other races and they conflict with your patches :( If you are planning to send v2 maybe you can take them on top as well? [1] https://lore.kernel.org/all/20260728-cpa-fixes-v1-0-2ed2352300b3@kernel.org -- Sincerely yours, Mike.