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 21AA3C4167B for ; Tue, 27 Dec 2022 19:10:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 786078E0002; Tue, 27 Dec 2022 14:10:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 735C58E0001; Tue, 27 Dec 2022 14:10:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D6328E0002; Tue, 27 Dec 2022 14:10:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4BB918E0001 for ; Tue, 27 Dec 2022 14:10:52 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 236E71C637F for ; Tue, 27 Dec 2022 19:10:52 +0000 (UTC) X-FDA: 80289028344.20.50B3F70 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf23.hostedemail.com (Postfix) with ESMTP id 44B1814001C for ; Tue, 27 Dec 2022 19:10:50 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Aq+2ymtx; spf=pass (imf23.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.180 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=1672168250; 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=ala6gezAzOfA3A3+kxaw4LGN1hrXw5q3ThDReQX0bOs=; b=NNxOPECk5eINxaADqGTIY8XTh/0BouJnUF8PRz+eu1CjZVQC7wlbsSscIsHlhXmbW7jCQK 3Kv/OwEwz5yTMZFsdFpKko+bMyTxhZQwXfPQNBS8e1u6PWiuyF++wG58MCdr/kO0G1wpiK 9YYRC+MDv85ZSvjvaXXD2wjx1NqfDJM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Aq+2ymtx; spf=pass (imf23.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.180 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672168250; a=rsa-sha256; cv=none; b=mx+8/4eSrD8qvsliFJDzJx0FyjXTeUqjFgainRsXQbi+2SwCpdy9LmsBiT68Dt5JAe8QzF H7ODbVeHfglkEqxUe1AMm/op2R2+NO4Rw2Ad75vABglMcGMybjUp+lAt7oL6R18vAJi0lB bmfLYyT5yMNKzlDe7GMVKg4cwJDlKC0= Received: by mail-qt1-f180.google.com with SMTP id h21so11101810qta.12 for ; Tue, 27 Dec 2022 11:10:49 -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=ala6gezAzOfA3A3+kxaw4LGN1hrXw5q3ThDReQX0bOs=; b=Aq+2ymtxux+AtiI6SM1Qao0amZsbwS0ltaNHroJ1yK+FXjtMBIs4FZ/ap33ecVvtop zLMLr3qZTfkf+X7A2HhvWFboTHPoyDfdayA+DKXHj8wMG8eeFJ0JpgFReEC98ZD8BAYu yyBev6KA6UgXGxdqumz7UzO+CDDcI10az/6YM= 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=ala6gezAzOfA3A3+kxaw4LGN1hrXw5q3ThDReQX0bOs=; b=6qzwIKATEIH6bNvyaQCwKHcHq4jK2HyPYhZ4/Q+EKrtT3YdT4wCC/ukQFLVv/4UTAj 0fsXaCw4Cq1AtQ9yVj9sMbbRrjjdx29s1K6dZ9wUHMSby0R39G3R8b3M1x5vv9wlENB0 QW+sagVvoKvcdvMsqipA3khZidK41xxTuK5lCC8wwTyktEzECCB1flaAeCVPT/m35va0 E+cbKBHpaVj2ikjlrzSXHlARLJAGN60EaaaEnIgVY36GULf/C6HBi+JAl2rUMCSqbVvp y9EDrinCZSmTD3xe3FlQ+b+1t9Q5tZ7rQdG5kQAlIvtLMNlyGpjhUzW7O2Sv0BLFLRR3 LYng== X-Gm-Message-State: AFqh2kqrEgMbuzuLpp3biAmFZVR288ABd9NeRHK28Hrn5rhzkC+C1xPV Unh+PtIy6To4LVrHYH2wAK0L80bNjR9gTT5A X-Google-Smtp-Source: AMrXdXuotmi6bLdsHwwfNvCNVECK/6xJ+4la8j1ohsZRuE7Hr0D/WXRjLF0QclPdCkiXehXfFtzpaA== X-Received: by 2002:ac8:73c7:0:b0:3a7:f3e7:5149 with SMTP id v7-20020ac873c7000000b003a7f3e75149mr27734868qtp.61.1672168248783; Tue, 27 Dec 2022 11:10:48 -0800 (PST) Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com. [209.85.219.51]) by smtp.gmail.com with ESMTPSA id cb20-20020a05622a1f9400b003ab5d6cd6c5sm8543812qtb.16.2022.12.27.11.10.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Dec 2022 11:10:47 -0800 (PST) Received: by mail-qv1-f51.google.com with SMTP id o17so5670788qvn.4 for ; Tue, 27 Dec 2022 11:10:47 -0800 (PST) X-Received: by 2002:a05:6214:1185:b0:4c6:608c:6b2c with SMTP id t5-20020a056214118500b004c6608c6b2cmr1025269qvv.130.1672168247410; Tue, 27 Dec 2022 11:10:47 -0800 (PST) MIME-Version: 1.0 References: <20221227030829.12508-1-kirill.shutemov@linux.intel.com> <20221227030829.12508-6-kirill.shutemov@linux.intel.com> In-Reply-To: <20221227030829.12508-6-kirill.shutemov@linux.intel.com> From: Linus Torvalds Date: Tue, 27 Dec 2022 11:10:31 -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: 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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 44B1814001C X-Rspam-User: X-Stat-Signature: g4jn8gyga8pez8dcxrxcbj8rdxz9wgow X-HE-Tag: 1672168250-197458 X-HE-Meta: U2FsdGVkX1/UgWPgd6Qmx5TmUjNOmt7cObgebgvfdk7n11U+qfk0+vpRCG32eCylsMYAF8PVTT9ExmlLTAW2Qce36xsR7e1sMykf3rPGmngVlifowlWpcGL4DvLR6NTAFJwbog5xB0ZMlGg0hjSKwuLMNR/AGDKG6Uxoikb6iVyCUa8dF3h3tzmUc9tGxBvFdtKjKSZejopY/G4Av9rbqTVCoiaD4kDg4v7C8Zxth2HeE5owSjjclvLgoY7WvCnNVL7MrV2zGPVyON/VG5waQyXuSzm3cqxXUeSl+Vuqx6eaP59rkZqgwa+MRrBNDCd5Ng/NDlC1fEEa19I/IMFw2ABFwUhmexQ3COWKS/48Sx+efWVMHh3D0k5n8AIVBu5pTxk3uSkiCSVDBkD46l7ikVO4UP/B4kjrDgPTrhpiphMoOH1RMb59Uw5bs4LmTT2qDojjXw9utATjHrMnsgHkcxPmIOZW1W7vnUj0ogmeq1PvkUzWqjLmZwzD5bcH2db5o4I8xUvqshtDHZeuPJ3ikHWoQSLGx1jGecgEd6+2keitacMueNfub2xmtdwk/nSBo2/S+s9q7ZnzSjGI+w/Lngo+Cp/WgbaZgiif5tev2MIW7tbgUnSw1POsAPCdbaXVUnajE3WroHo1ZcHqZ6rH9JU0jnpZzTkShYsFfSwgk+TEOzjL0N8yY751jaPlsMEvgrh62v9XGaQDO4zzvP5Mid4nO1Jm/+pJDfgqeQJGhsuL3crV2yFHwXqkMF9jvz/Z5dAbUgZ1RFkS+rwO4umClbaDLWU6sKivOJHkzh8havds5/BuyNzDNCo+Q60uXvhgtJ+OFsvD/HCWl+u21JTRgbnGIWw7Gc20Tdg3mAls8DINdaAohAaJ775PeYPmwjYDBlzatpLoo4Hm/v+fEgx8xY5vZxlFZW5E8LIBWPd0tUTrHPdSAP0LsrrQI9JqNPluYRBV2mkTHbqGSSFGedu y41DyBEh C8wAqEI3k8umPDDQf0wM032FRMEW6DhxCvz6NRnLRYSun0w5gyWvhKdwWT3zE8W8JqoxPq2T5UlrkLGt+HBdQ8slrTBDpVh98/Mf1rNZSq9i6lldvJleyIfx0f+sfTKSfK/duMwV8K9EBKZTFHp9eajpuIVzVrRTBhvSkdlb99mXOeUEtF7yLpXc+B5tcH2xiEnwhhl50xgAVv/xjBlMgpZDkvtCi3Vw4+N6ockAWHVri1Ib7o8J+qod/YJNgXaH0Y7j5Csy2IYhllOUkJE2yWCZ/yQ/NSyFYJSQgYH5IMUr5iQyyWzjc5hI82ukBfaIGXu2VtLTCsYAjsP3M5qQdu25LOmjBMl7UG1yyRA8un7MyuFvmxcTiJfNyYaME5TQS4dmLU9rOzJa23b6cofnErBGU5g== 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 Mon, Dec 26, 2022 at 7:08 PM Kirill A. Shutemov wrote: > > --- a/arch/x86/include/asm/uaccess.h > +++ b/arch/x86/include/asm/uaccess.h > @@ -21,6 +22,37 @@ static inline bool pagefault_disabled(void); > # define WARN_ON_IN_IRQ() > #endif > > +#ifdef CONFIG_X86_64 I think this should be CONFIG_ADDRESS_MASKING or something like that. This is not a "64 vs 32-bit feature". This is something else. Even if you then were to select it unconditionally for 64-bit kernels (but why would you?) it reads better if the #ifdef's make sense. > +#define __untagged_addr(mm, addr) ({ \ > + u64 __addr = (__force u64)(addr); \ > + s64 sign = (s64)__addr >> 63; \ > + __addr &= READ_ONCE((mm)->context.untag_mask) | sign; \ Now the READ_ONCE() doesn't make much sense. There shouldn't be any data races on that thing. Plus: > +#define untagged_addr(addr) __untagged_addr(current->mm, addr) I think this should at least allow caching it in 'current' without the mm indirection. In fact, it might be even better off as a per-cpu variable. Because it is now in somewhat crititcal code sections: > -#define get_user(x,ptr) ({ might_fault(); do_get_user_call(get_user,x,ptr); }) > +#define get_user(x,ptr) \ > +({ \ > + might_fault(); \ > + do_get_user_call(get_user,x,untagged_ptr(ptr)); \ > +}) This is disgusting and wrong. The whole reason we do do_get_user_call() as a function call is because we *don't* want to do this kind of stuff at the call sites. We used to inline it all, but with all the clac/stac and access_ok checks, it all just ended up ballooning so much that it was much better to make it a special function call with particular calling conventions. That untagged_ptr() should be done in that asm function, not in every call site. Now, the sad part is that we got *rid* of all this kind of crap not that long ago when Christoph cleaned up the old legacy set_fs() mess, and we were able to make the task limit be a constant (ok, be _two_ constants, depending on LA57). So we'd have to re-introduce that nasty "look up task size dynamically". See commit 47058bb54b57 ("x86: remove address space overrides using set_fs()") for the removal that would have to be re-instated. But see above about "maybe it should be a per-cpu variable" - and making that ALTERNATIVE th8ing even nastier. Another alternative mght be to *only* test the sign bit in the get_user/put_user functions, and just take the fault instead. Right now we warn about non-canonical addresses because it implies somebody might have missed an access_ok(), but we'd just mark those get_user/put_user accesses special. That would get this all entirely off the critical path. Most other address masking is for relatively rare things (ie mmap/munmap), but the user accesses are hot. Hmm? Linus