From nobody Mon Jun 8 07:22:53 2026 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 0D0443CCA11 for ; Wed, 3 Jun 2026 10:20:37 +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=1780482041; cv=none; b=FSGxRTC7O39Kgbd7bKRkrh5W9nY6H5Ch7xeZpmQLtiLHIKLjCY7bXm0f3pSzJZKTkBIumz08DEnTI9+a58gLc1p7hiVOt7ZAzCR9h7AqezNRMr0eG+NtxR1/3R8YXYtMJ7AQ6mu1sNFcrpvXWku5N2DK5sg60C9zqC4p4sXPHFs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780482041; c=relaxed/simple; bh=AFmg1cR5zKlOZUDdLC9Yafo7y1A+dPJ/ppORVoEg91Q=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Q28jIYjXJJ5oj1HbDKM2jD3e8k7GN+4YlcHPy4iU54zeX3CB9HokXfXlg15GoVO4SeiS+tHMZ69T+GDF0q5Y7OsVNRykGtNACNmRj04ixbsDOqiMKayB2HKdiRQA42AYbk7Qo7SfWxJ6HIOyG01hHUC1Fdj5YmyA4ZPnSD5HY6I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ix9CYaI5; 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="Ix9CYaI5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6E681F00893; Wed, 3 Jun 2026 10:20:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780482037; bh=oR/k1mVyyfu6WyTJCC0me1TnDDk1gSjioq9kNyproS4=; h=From:To:Cc:Subject:Date; b=Ix9CYaI5S2BEqTLsfDrNc/2TI9ZoY1r1vbNrc5JX+DpaSyOpGMyESjqcO5r9r6Sid 3aIVwjGPzfgGQwyXr/O7E5qkTafepGTna/0NSSZov0IQuRyw9zRqdv2ZEJ5ybKQYiy HgszeYCKhtYkYMyRNUo4TmUm3vGp8pRdAeprTwekzG8P4wo6g2/5TU3WsCi35AzhTv QhWquJgREAu6acdiMr/STUDpJJfnC/3jsC90qUVpIUMIVr26Zv9tlUa2EE4zgiv/sP oEH/Oc7FlMSvIXuj1qG63yvh8Now+Mv0ccK3f9jTV/8U7SujDupjTz2viGKdPOzV43 vgj7qZMtI6O0g== From: "Christophe Leroy (CS GROUP)" To: Michael Ellerman , Nicholas Piggin , Madhavan Srinivasan Cc: "Christophe Leroy (CS GROUP)" , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: [PATCH v4] powerpc: Simplify access_ok() Date: Wed, 3 Jun 2026 12:20:14 +0200 Message-ID: X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2694; i=chleroy@kernel.org; h=from:subject:message-id; bh=AFmg1cR5zKlOZUDdLC9Yafo7y1A+dPJ/ppORVoEg91Q=; b=owGbwMvMwCV2d0KB2p7V54MZT6slMWTJ/3/UUz5b9bB0j3tNYuCnwjcCvDlej6y3PfwxpyhVh iPe56xaRykLgxgXg6yYIsvx/9y7ZnR9Sc2fuksfZg4rE8gQBi5OAZhIlxkjw+yFu7U3Ckd4tKmp iz83lWlWNfNKbHqfff35ns13ar8crmFk2MjQevp20sq+l2LXwlLNuqP2Luid2RypuKnA7u4+Zfd CDgA= X-Developer-Key: i=chleroy@kernel.org; a=openpgp; fpr=10FFE6F8B390DE17ACC2632368A92FEB01B8DD78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" With the implementation of masked user access, we always have a memory gap between user memory space and kernel memory space, so use it to simplify access_ok() by relying on access fault in case of an access in the gap. Most of the time the size is known at build time. On powerpc64, the kernel space starts at 0x8000000000000000 which is always more than two times TASK_USER_MAX so when the size is known at build time and lower than TASK_USER_MAX, only the address needs to be verified. If not, a binary or of address and size must be lower than TASK_USER_MAX. As TASK_USER_MAX is a power of 2, just check that there is no bit set outside of TASK_USER_MAX - 1 mask. On powerpc32, there is a garanteed gap of 128KB so when the size is known at build time and not greater than 128KB, just check that the address is below TASK_SIZE. Otherwise use the original formula. Signed-off-by: Christophe Leroy (CS GROUP) --- v2: Fix build failure following untested last minute change :( v3: Using statically_true() following comment from David. v4: Rebased on top of today's powerpc/merge branch 3af068d1f05b ("Automatic= merge of 'next' into merge (2026-05-22 09:59)") --- arch/powerpc/include/asm/uaccess.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/= uaccess.h index e98c628e3899..7b8c56962c31 100644 --- a/arch/powerpc/include/asm/uaccess.h +++ b/arch/powerpc/include/asm/uaccess.h @@ -18,8 +18,34 @@ /* Threshold above which VMX copy path is used */ #define VMX_COPY_THRESHOLD 3328 =20 +#define __access_ok __access_ok + #include =20 +/* + * On powerpc64, TASK_SIZE_MAX is 0x0010000000000000 then even if both ptr= and size + * are TASK_SIZE_MAX we are still inside the memory gap. So make it simple. + */ +static __always_inline int __access_ok(const void __user *ptr, unsigned lo= ng size) +{ + unsigned long addr =3D (unsigned long)ptr; + + if (IS_ENABLED(CONFIG_PPC64)) { + BUILD_BUG_ON(!is_power_of_2(TASK_SIZE_MAX)); + BUILD_BUG_ON(TASK_SIZE_MAX > 0x0010000000000000); + + if (statically_true(size > TASK_SIZE_MAX)) + return false; + if (statically_true(size <=3D TASK_SIZE_MAX)) + return !(addr & ~(TASK_SIZE_MAX - 1)); + return !((size | addr) & ~(TASK_SIZE_MAX - 1)); + } else { + if (statically_true(size <=3D SZ_128K)) + return addr < TASK_SIZE; + return size <=3D TASK_SIZE && addr <=3D TASK_SIZE - size; + } +} + /* * These are the main single-value transfer routines. They automatically * use the right size if we just have the right pointer type. --=20 2.54.0