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 E0861C46467 for ; Sat, 7 Jan 2023 17:28:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC00A8E0002; Sat, 7 Jan 2023 12:28:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D70228E0001; Sat, 7 Jan 2023 12:28:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C37838E0002; Sat, 7 Jan 2023 12:28:31 -0500 (EST) 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 B42468E0001 for ; Sat, 7 Jan 2023 12:28:31 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7BFB0120729 for ; Sat, 7 Jan 2023 17:28:31 +0000 (UTC) X-FDA: 80328687222.05.463FA24 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) by imf10.hostedemail.com (Postfix) with ESMTP id C5F20C0008 for ; Sat, 7 Jan 2023 17:28:28 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=g9FwzkzA; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673112508; a=rsa-sha256; cv=none; b=gjZXwrE9wQ16j3t1qLxbRAIqjXjJdIWxTUXxtFA5i2pkpMk7B06ecEvMNDix5zt48uBqta hoXFBY5ApOuSuU4NO+p3BvHnTb1U126Wxyo8JPegXXdjkADXF6BvK7BrArxmAYXnPcyZSh fLTySf7fkfbh5t5de7U7fQavETGnPzM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=g9FwzkzA; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673112508; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Qb8/dxYTtsWxSA5bIXEU6Yf2xXp3cdFqGFZ23l+BPuA=; b=gVczz2Y3mUo7CE6GaPq/GjwnOOJo89kdO8U4ovPnI0sKi7RJTJXVm9ynqhIcvDE2FQ1y3Z yfuOf/GVUIfsShLgDXbhxSnG/t0TF9JeCfFkwRpqSRaGRGwooXD5u34a5ts4Wf0BikS398 qi5+pgP5Aai7Noj5OFVq98u6LpSQkW8= Received: by mail-qv1-f44.google.com with SMTP id j9so3276150qvt.0 for ; Sat, 07 Jan 2023 09:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qb8/dxYTtsWxSA5bIXEU6Yf2xXp3cdFqGFZ23l+BPuA=; b=g9FwzkzAehlnWAOKCySz2K2WnFa5ScpJcrvi2qmP1p5u4XUjoRjjC6RF59+c+NW+t6 3q4hlcvFEY5Q0fm6YiXIfsPtmSam1MHRnpzx3hE/MeakleM6RJyrs5Iq5MX/RJ0SsPtn 7WlsbwTS50T6CNpXuIOfIXnt3taNaOKbe+my0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Qb8/dxYTtsWxSA5bIXEU6Yf2xXp3cdFqGFZ23l+BPuA=; b=brEH6bMOPVufSgg5otDEY1IA3YeaGTSheNq2X8+XL95nvGetr1ws0K6YJrq8aQDOOk +T3e8nwurgQbRfFU1M6FWCbFSAYgyvI+3GNJk18CPS0OtNGo2qxIFn32a520P1kBPPKT k0FJEbxHpwS+28TiI4Eut+dFq2AMmsYI5F8AjtC0cjv2JzAv7mIIxl5aTiZ0Ezc+eND2 Ur2pkZ/R3IrX97rnraEWiAISue4MbBZqvhm8awGYAoIFAJxBwWJtkGSH4NA3resUtEQQ ai8LMtPTt9p9fbc9+DRmVmg5CPFpwYJoIkfEDK1GnwIXfO8mLLPDTJjFtanhGGHfyM5B ffvQ== X-Gm-Message-State: AFqh2kpzvFrglBKsvvU4zzocScnZwFolJUjFNW5qpd/0DndUl1xE3fhB g3zfGOyud2JdDAANYJSal8XhMXAW6MYD5yRb X-Google-Smtp-Source: AMrXdXvemrf3rtrkwcNJlbdI7pwa8V8tzi4Ghx6MCXBdjb0cf8L447kd5YXqL8DuU+WGVwd1njE+Uw== X-Received: by 2002:a0c:f88e:0:b0:531:d60f:6a9c with SMTP id u14-20020a0cf88e000000b00531d60f6a9cmr23922215qvn.34.1673112507241; Sat, 07 Jan 2023 09:28:27 -0800 (PST) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com. [209.85.222.171]) by smtp.gmail.com with ESMTPSA id k2-20020a05620a414200b006faaf6dc55asm2488583qko.22.2023.01.07.09.28.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Jan 2023 09:28:26 -0800 (PST) Received: by mail-qk1-f171.google.com with SMTP id l1so2219693qkg.11 for ; Sat, 07 Jan 2023 09:28:26 -0800 (PST) X-Received: by 2002:a05:620a:674:b0:6ff:a7de:ce22 with SMTP id a20-20020a05620a067400b006ffa7dece22mr2972740qkh.72.1673112506080; Sat, 07 Jan 2023 09:28:26 -0800 (PST) MIME-Version: 1.0 References: <20221227030829.12508-1-kirill.shutemov@linux.intel.com> <20221227030829.12508-6-kirill.shutemov@linux.intel.com> <20221231001029.5nckrhtmwahb65jo@box> <20230107091027.xbikgiizkeegofdd@box.shutemov.name> In-Reply-To: <20230107091027.xbikgiizkeegofdd@box.shutemov.name> From: Linus Torvalds Date: Sat, 7 Jan 2023 09:28:10 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHv13 05/16] x86/uaccess: Provide untagged_addr() and remove tags before address check To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Bharata B Rao , Jacob Pan , Ashok Raj , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: C5F20C0008 X-Stat-Signature: tf9gehrmpzozxsh75dziem8niwnmctj9 X-HE-Tag: 1673112508-159849 X-HE-Meta: U2FsdGVkX18h52L9U43NHTwQOtkp56gIPdA4Exo6IHoHT/WyyC7ljKCXqjJluzGgQsIri68YPYtYWYOzlMkJ3SGwrntksVMiICa/n7o35gZIHAhcBZOJNetTjMhcjIwdFH+K+r/nbvsA7e4tT7qmK5MCQZDQXH1S5osFIer47PeYG88lZAKCAOhlBX3E5W4rbDH3bEIB4dk4ucEDng3dMSiC0sYlmoK73ivc+BmcQ7Fb5NcxRkb4PuIEFGOYqskLCECYV16FbloJ8YOKLYZYMUeoozerx1s6meazbHW82fUQeSSokp+IB63MIq8clfVEkQqU63Ly4DVYHVkwEREd55R2YeChOUzWCxgYSSpvB0azsdVdBlfd55HjATAXYY2dBu0Xdg6Edx95GRtTPcizsZoatZbRAfwSSiFOSAtnAPrjM8WuKZs3tBtwNux+UpiNU7aOnv/5UPkpNUHXp0bCHGd97vBcMXhdcm1ly7SgM1nYyR9wqiIwPEjiwMiWbbMBoApU+z/qyaBYWpmUiGcRhsIXXcOkTz6RzRDX2sQxbaC/7/LwGwySIGedC+vs9hwtNIwHc4ofnl4LD/38buvxhlJsTrsZnKtqznG16T4YyA/eL2aku5d5j2eFk8qU9ydVFwL7+ma9HkqnKqwREHcNnimtHuEheV5/nDsmuTFA40tl1JhOnsw+xaJ2rV4WGQZOvXvLZ0L/UmSBYborKuAj5sgxG0NuaL5AoGR7NTWykA/ZKkobPLaC+NLGGvZE3hNfVr9TnB32U12Aykc/ThJ9e9SLppM0TWlmmzCxi/c4JKxFCAVcxcTtH7WhDmMvbORpTnsbff9Tuthzsnop35XewhC4hMrM5T98u9Zgl7c7pdN8M3C6LNqseDfgc9xy+Z/HAXYXE1UUjF5DGBT6SrWLoa1FZEOmezMh35fZKKL6Nhea6CE/GWCgLsdS2fUMtHXTB7vsGuiOj74W/qNCndS 6gpsTaYD p4yaXuavbELeIOzjrE1tQBM+UCsnxpLTpPe1trdejkd5c/hF7ImZHqK5cpBz0uAulPpIYxI3g8bZAyYS96ChvRD5RX67K9x2NyVEiOUBnY52cnUOVILlx3QDvxcPv9wCzgBn3beWLBvjGOcQSJHgEniR7CpA+eh6wOZUpss6ij6WUxCf6HOO3l2y/ZMuDQ1juOBuznP1S1eBvi5YrvuogIiLVRxN7u7rgdvCGh91chk8QtOlRbPbUew/9BEEV7cO3/x8YuWnygadfpjOBmiSqnkBpaKbx22bE4KsfG7Ybf12NPYAUsKT+tms+d4gY+iVOnv/vnsQQZhZX6PkCg92eK7uAByW/OD1qrD50iis4HLwOFXmgO5SZL5ZiYphfR8Ujvhn1G3TIEYL1uN8uAqnW9QPvCA== 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: On Sat, Jan 7, 2023 at 1:10 AM Kirill A. Shutemov wrote: > > On Fri, Dec 30, 2022 at 04:42:05PM -0800, Linus Torvalds wrote: > > in ex_handler_uaccess() for the GP trap that users can now cause by > > giving a non-canonical address with the high bit clear. So we'd > > probably just want a new EX_TYPE_* for these cases, but that still > > looks fairly straightforward. > > Plain _ASM_EXTABLE() seems does the trick. Ack, for some reason I stupidly thought we'd have to change the _ASM_EXTABLE_UA logic. Thanks for setting me straight. > Here's what I've come up with: This looks good to me. And I like how you've used assembler macros instead of the C preprocessor, it makes things more readable. I'm personally so unused to asm macros that I never use them (and the same is obviously true of Christoph who did that previous task size thing), but I can appreciate others doing a better job at it. So ack on this from me (I assume you tested it - hopefully even with LAM), but maybe the x86 maintainers disagree violently? The one possible downside is that *if* somebody passes non-valid user addresses to get/put_user() intentionally (expecting an EFAULT), we will now handle that much more slowly with a fault. But it would have to be some really crazy use-case, and the normal case should be simpler and faster. But honestly, to me the upside is mainly "no need to worry about LAM masking in asm code". Linus