From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 428FEC77B7F for ; Thu, 26 Jun 2025 05:56:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6ED16B00BF; Thu, 26 Jun 2025 01:56:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C46986B00C1; Thu, 26 Jun 2025 01:56:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B83CF6B00C4; Thu, 26 Jun 2025 01:56:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A7EB46B00BF for ; Thu, 26 Jun 2025 01:56:16 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4E47514016C for ; Thu, 26 Jun 2025 05:56:16 +0000 (UTC) X-FDA: 83596491552.27.6AC87B9 Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf28.hostedemail.com (Postfix) with ESMTP id 1F7FCC0009 for ; Thu, 26 Jun 2025 05:56:13 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of christophe.leroy@csgroup.eu designates 93.17.236.30 as permitted sender) smtp.mailfrom=christophe.leroy@csgroup.eu; dmarc=pass (policy=quarantine) header.from=csgroup.eu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750917374; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MRQSDqU8wyvRI4kJVe1JEIgxi46WZlk0UdrU8AUDALg=; b=DOE1miSaYv4/QMwfv30SY+LnBWMjAl1Ak+QQqpGJveCY+sQKhE1v0S2KUv/DS0+NK9AMQ6 1YVhVC8LmyukHimB2eh/Q9UAs7fD8Ph3o9yPY1g9fteDYakKM8oJ8du0vu4ksDKxIs2tNL xvtRDtg13iGS2f6DSB8RxfI1lEG0UXc= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of christophe.leroy@csgroup.eu designates 93.17.236.30 as permitted sender) smtp.mailfrom=christophe.leroy@csgroup.eu; dmarc=pass (policy=quarantine) header.from=csgroup.eu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750917374; a=rsa-sha256; cv=none; b=HFOGXno+ZLl/v/2cn8TE0W0XdJtSMZ74SUsECTiPT20vQSbuGT1jFpPcW74+vycAGCsVbH TAEt5xrkAgnFaZaKeiA1F0kH4LfSrZhaS7FSuUZGQ0hEQTPx4BES/uLxYTexqq9yOgRbPv HxZWbMLf+iaIOv74f+GBNkXgo75345Q= Received: from localhost (mailhub3.si.c-s.fr [192.168.12.233]) by localhost (Postfix) with ESMTP id 4bSSbw1jqdz9vG4; Thu, 26 Jun 2025 07:56:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0xrpHJGhTt6; Thu, 26 Jun 2025 07:56:12 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4bSSbw0vypz9vFr; Thu, 26 Jun 2025 07:56:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 157358B7B7; Thu, 26 Jun 2025 07:56:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KbYfiNafM5QK; Thu, 26 Jun 2025 07:56:11 +0200 (CEST) Received: from [192.168.235.99] (unknown [192.168.235.99]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 13B658B7A7; Thu, 26 Jun 2025 07:56:11 +0200 (CEST) Message-ID: <83fb5685-a206-477c-bff3-03e0ebf4c40c@csgroup.eu> Date: Thu, 26 Jun 2025 07:56:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/5] powerpc: Implement masked user access To: David Laight , Segher Boessenkool Cc: Michael Ellerman , Nicholas Piggin , Naveen N Rao , Madhavan Srinivasan , Alexander Viro , Christian Brauner , Jan Kara , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Darren Hart , Davidlohr Bueso , Andre Almeida , Andrew Morton , Dave Hansen , Linus Torvalds , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org References: <20250622172043.3fb0e54c@pumpkin> <20250624131714.GG17294@gate.crashing.org> <20250624175001.148a768f@pumpkin> <20250624182505.GH17294@gate.crashing.org> <20250624220816.078f960d@pumpkin> Content-Language: fr-FR From: Christophe Leroy In-Reply-To: <20250624220816.078f960d@pumpkin> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 1F7FCC0009 X-Stat-Signature: bfw16d9romhn6atgqo46huaohnmy19ak X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1750917373-641420 X-HE-Meta: U2FsdGVkX1+a6j+A5GhzTIN/dL0JzuZtJG17Vs/EnGWUSi7oGDshqGD0RUbMMJ72moJywbNX9LupHrlVjk6M95ZbDDK56mYt88KVhf+lBBFt8MBrgt7BZJ7q/L88xZ05PdZ2/W2KmWLTtc+JCxUjy9lKAClcrlfGx57+uxf+RKwIktVvSCe2DX/QHlXdQ9L4nt+h8tf3+qBtvRG4kvGI+GyBtaamUpL8ub3BCnDXBfFuWzbmO8vrtBxx2Rm3yY1BAASMihREalKr/TimHuOdpJlvKBQKbeMon9BSmGpRd1Tpeh/psLzOXyR5UOnw7zC09HJ4cJEXkeJlzVspw+3r8URrglGC0GKJ6n3hFQDRxRM2zia5JRXHnBqHg8ksyiql9kb5q/rLqVvLnJLuXHuCUslRnSWsj3jFShVyMFKtfc7DQc4okH4RNcWlGkvNVUFYyKR1mf71SHwO74D61AYruzoXS8CVg6v1FWNokH4CYx/ddIgCwBKSTqrbDsXqeRoyWRUMYob69vVmxZz2miR29wBnxAJ587h2xYtcr7H3DPmuwbaWOnIKixzdrqQH2TZ9eCgyNq9srOsOqdb1zKdxC4O+4JLzVoU+Zczo+3GtohFBvqImNgREnlhaQFeYAj7Ms3K5fgNqOtcP//U+vFdXJWSp2DY5MQ0vuw4DcX1tdqP4okTPAOnSLOlyZK/lTgwmukwkaDx9xrg8in6e+PxuyoMwDoi3Xz9D6+tUlV8DfFmYSKHbRU8K/I0E2G4KmF6KAeBrmNHTyLgMQ+VB/V/YikGzaZyuMIa/JrlNFu8B8bnH0MUG6gm8BBSlzLDiSnX/CXgJPwJNEn/gPsVKcnC7r6/sr6ShQoO3Pq942r9ABEm8Xm/GcLAoN/Jfz/nK63gu5U7fMs8ZKICMsMgXHzi8sj5W9u3jQinaaWAZLNDzZy+hojMX4C8vKWtE4wiXAojtIm1EYrkt3gc5JSAcVjo VWA75byQ qfTT7PkMv8lLHIozkAzD066uluimji17LEBmWxbX64c619X+n42sTeTLXbGDUI1tUNH8Gor4YiB5G5XPalP+4ohOIgAis5vQqo1DCZrh4Glaowm0RiZfKkVN2M1O7sL0xlu/ppkuIsrdooAeBJ8fZY6qE+0GYyp3v09WKrjK+p7/TFfisHvZc7xeFXezCxUzSf8MZESY/JxfTqFeezdUW21+I/YV2kUASMYmcTDkiA4UsqalyVKcjVQeA355zhnxKgGv6IfY7TRgilHr6462Vr+5C5VbTiJa8apbRfuBotln5qOIMn1LKkwh4I4YxuWm40+tlm7rxbtnP/W6rNHbhSQykGSHp4INY0ACrO+O36UN0QJJ+mjtY+F2AWaE8rAFgY1D1Y7oKWP1vfsL3wQBJNxbqYg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Le 24/06/2025 à 23:08, David Laight a écrit : > On Tue, 24 Jun 2025 13:25:05 -0500 > Segher Boessenkool wrote: > >>>> isel (which is base PowerPC, not something "e500" only) is a >>>> computational instruction, it copies one of two registers to a third, >>>> which of the two is decided by any bit in the condition register. >>> >>> Does that mean it could be used for all the ppc cpu variants? >> >> No, only things that implement architecture version of 2.03 or later. >> That is from 2006, so essentially everything that is still made >> implements it :-) >> >> But ancient things do not. Both 970 (Apple G5) and Cell BE do not yet >> have it (they are ISA 2.01 and 2.02 respectively). And the older p5's >> do not have it yet either, but the newer ones do. For book3s64, GCC only use isel with -mcpu=power9 or -mcpu=power10 >> >> And all classic PowerPC is ISA 1.xx of course. Medieval CPUs :-) > > That make more sense than the list in patch 5/5. Sorry for the ambiguity. In patch 5/5 I was addressing only powerpc/32, and as far as I know the only powerpc/32 supported by Linux that has isel is the 85xx which has an e500 core. For powerpc/64 we have less constraint than on powerpc32: - Kernel memory starts at 0xc000000000000000 - User memory stops at 0x0010000000000000 So we can easily use 0x8000000000000000 as demarcation line, which allows a 3 instructions sequence: sradi r9,r3,63 => shirt right algebric: r9 = 0 when r3 >= 0; r9 = -1 when r3 < 0 andc r3,r3,r9 => and with complement: r3 unchanged when r9 = 0, r3 = 0 when r9 = -1 rldimi r3,r9,0,1 => Rotate left and mask insert: Insert highest bit of r9 into r3 Whereas using isel requires a 4 instructions sequence: li r9, 1 => load immediate: r9 = 1 rotldi r9, r9, 63 => rotate left: r9 = 0x8000000000000000 cmpld r3, r9 => compare logically iselgt r3, r9, r3 => integer select greater than: select r3 when result of above compare is <= ; select r9 when result of compare is > > >> >>>> But sure, seen from very far off both isel and cmove can be used to >>>> implement the ternary operator ("?:"), are similar in that way :-) >>> >>> Which is exactly what you want to avoid speculation. >> >> There are cheaper / simpler / more effective / better ways to get that, >> but sure, everything is better than a conditional branch, always :-) > > Everything except a TLB miss :-) > > And for access_ok() avoiding the conditional is a good enough reason > to use a 'conditional move' instruction. > Avoiding speculation is actually free. > And on CPUs that are not affected by Spectre and Meltdown like powerpc 8xx or powerpc 603, masking the pointer is still worth it as it generates better code, even if the masking involves branching. That's the reason why I did: - e500 (affected by Spectre v1) ==> Use isel ==> 3 instructions sequence: lis r9, TASK_SIZE@h => load immediate shifted => r9 = (TASK_SIZE >> 16) << 16 cmplw r3, r9 => compare addr with TASK_SIZE iselgt r3, r9, r3 => addr = TASK_SIZE when addr > TASK_SIZE; addr = addr when <= TASK_SIZE For others: - If TASK_SIZE <= 0x80000000 and kernel >= 0x80000000 ==> 3 instructions sequence similar to the 64 bits one above: srawi r9,r3,63 andc r3,r3,r9 rlwimi r3,r9,0,0,0 - Otherwise, if speculation mitigation is required (e600), use the 6-instructions masking sequence (r3 contains the address to mask) srwi r9,r3,17 => shift right: shift r3 by 17 to keep 15 bits (positive 16 bits) subfic r9,r9,22527 => sub from immediate: r9 = (TASK_SIZE >> 17) - r9 => r9 < 0 when r3 is greater srawi r9,r9,31 => shift right algebric: r9 = 0 when r9 >= 0; r9 = -1 when r9 < 0 andis. r10,r9,45056 => and immediat shifted: r10 = r9 and upper part of TASK_SIZE => r10 = TASK_SIZE when r3 > TASK_SIZE, r10 = 0 otherwise andc r3,r3,r9 => and with complement: r3 is unchanged when r9 = 0 so when r3 <= TASK_SIZE, r3 is cleared when r9 = -1 so when r3 > TASK_SIZE or r3,r3,r10 => r3 = r3 | r10 - If no speculation mitigation is required, let GCC do as it wants List of affected CPUs is available here: https://docs.nxp.com/bundle/GUID-805CC0EA-4001-47AD-86CD-4F340751F6B7/page/GUID-17B5D04F-6471-4EC6-BEB9-DE4D0AFA034A.html