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 627ED3FDBF8 for ; Thu, 16 Jul 2026 13:44:35 +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=1784209476; cv=none; b=mca2gZx8/QSeiwioh0KIxA3WNu1ttIxNRYUn0xd4x0pKGRf4+RbMlK5GyrlNby3KwaIvkCslcr1GSmIS0uVcWbAL9Wola6VjIGC4MGlnmjjZS/GfYjh2o4D38xnzQBn7wXUMmPS0p0mqyIccVDW6/mMA0inH6w73cigz32pdSFU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784209476; c=relaxed/simple; bh=oJfzMMW8w5JayE3PtWFxVPWVjoYhJnMAiyLa6jZ4LiY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a2lM14WVDFjTiBVuv4bKm0d7/iJyn5hypJhQF8y0B4U+laRcgeh2xaJuJZ+fKsGEsfM6zEtvLfIen2KyxTpxQN0NIQY9Ald73mtnNC9iO9Q2QOTmf7Y35kEOg7yt8VHyEdGbbPEDsyMu8Cm8iPlXd+D20rQGgfxSwhlvFAupkC8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KaBdGqKO; 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="KaBdGqKO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB1D71F00A3E; Thu, 16 Jul 2026 13:44:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784209474; bh=cYtvT3meTNhR8Buz54ErnOO8j/sciR9eXOiZBCdvO64=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KaBdGqKO06MDIs+G2mtU7dCW/YlTicH5OkA9JKhxp4WnQ9Nz2GdgXQ26vXgUxOVBn Zm3kbRxJ4tMwpIT7CE4t2Y5hf2IxROcpWvmC4hUGq6AQU6hp/0OLen50leekSMGUuF Wkb3zkszD5ozz6XnY11WiSfe0diW3eMQtkQEcrMSoRQALFuyGG5FvU7sc7Sp13yQNX Rbyi/URBcSGRR2m/MRChauvW6O39oJvdd1Tk97aH6kKGQ0ekJU0diz+P4LHVbpSk+y bK/YDvfnPiSaEsSlXMXLzE0anJdPVbQgq/gjXdbZFoglpJJgUz+khzWJg61xwVtz/z HCiJwz20IJgNQ== Date: Thu, 16 Jul 2026 16:44:26 +0300 From: Mike Rapoport To: Dave Hansen Cc: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= , Dave Hansen , Andy Lutomirski , Borislav Petkov , Ingo Molnar , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Thomas Gleixner , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/mm/pat: fix effective RW computation in lookup_address_in_pgd_attr() Message-ID: References: <20260716-verify-rwx-fix-v1-1-d8a04854df06@kernel.org> 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 Thu, Jul 16, 2026 at 06:27:34AM -0700, Dave Hansen wrote: > On 7/16/26 02:18, Mike Rapoport wrote: > >> I don't really care how the issue is fixed, but this would result in less > >> code. > > But it will be slower 🙂 > > What does "slower" mean here? I've seen ~2% difference per set_memory call in instrumented cpa-test. > Does it matter in _practice_? Does it measurably slow down something an > end user might see? Yes, if a user is loading/unloading a BPF program in a tight loop :) We can also accumulate flags and push the masking to the final assignment like Jürgen suggested earlier in this thread: https://lore.kernel.org/all/f0d7dbe5-5472-409c-9f61-eeefe7d08591@suse.com/ I'd prefer to keep the current structure though as I'm planning to pull lookup_address_in_pgd_attr() to generic code and replace bit checks with pXd_write()/pXd_exec() helpers. > Also, I thought we had tests for this gunk. But maybe we're only testing > the leaf entry permissions or something and not the upper-level > permissions. I guess we don't often muck with those so this is > relatively unlikely to have hidden real bugs. > > BTW, my pre-coffee brain struggled with the changelog here: > > but _PAGE_RW is bit 1 while *rw only ever holds 0 or 1, so the > > Maybe it was a 0 vs. 1 bit thing, but it still took me way too long. > Could we do something like: > > _PAGE_RW is 0x2. So consider the accumulation line: > > rw &= pXd_flags(*pXd) & _PAGE_RW; > > where rw=0x1 and the right side evaluates down to 0x2. It'll end up doing: > > rw = 0x1 & 0x2 > > and rw always ends up 0. Works for me. -- Sincerely yours, Mike.