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 3E4CDC433EF for ; Fri, 13 May 2022 10:14:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51F326B0073; Fri, 13 May 2022 06:14:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CFFE6B0075; Fri, 13 May 2022 06:14:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3BE4B6B0078; Fri, 13 May 2022 06:14:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 29CC56B0073 for ; Fri, 13 May 2022 06:14:29 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 00A0021310 for ; Fri, 13 May 2022 10:14:28 +0000 (UTC) X-FDA: 79460310258.23.5249C9F Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by imf16.hostedemail.com (Postfix) with ESMTP id B80431800D3 for ; Fri, 13 May 2022 10:14:18 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-320-3fGZbADZPVKzjU4bvG8Wfg-1; Fri, 13 May 2022 11:14:24 +0100 X-MC-Unique: 3fGZbADZPVKzjU4bvG8Wfg-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Fri, 13 May 2022 11:14:23 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.033; Fri, 13 May 2022 11:14:23 +0100 From: David Laight To: 'Thomas Gleixner' , Peter Zijlstra CC: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , "x86@kernel.org" , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , "Rick Edgecombe" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: RE: [RFCv2 05/10] x86/mm: Provide untagged_addr() helper Thread-Topic: [RFCv2 05/10] x86/mm: Provide untagged_addr() helper Thread-Index: AQHYZlYbkN98ikiNG0u1ah6OjFcYAq0ck+jA Date: Fri, 13 May 2022 10:14:23 +0000 Message-ID: <6f206d410f5b49789e986166ea473a6a@AcuMS.aculab.com> References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511022751.65540-7-kirill.shutemov@linux.intel.com> <87a6bmx5lt.ffs@tglx> <87sfpevl1g.ffs@tglx> <87wneqtkb8.ffs@tglx> In-Reply-To: <87wneqtkb8.ffs@tglx> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B80431800D3 Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com; dmarc=pass (policy=none) header.from=aculab.com X-Rspam-User: X-Stat-Signature: a78yhtdsydiz7w9w1gujz5xw4wbx1cgz X-HE-Tag: 1652436858-577597 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: From: Thomas Gleixner > Sent: 13 May 2022 00:15 ... > But whatever we chose, it's sad, that we need to have support for > interfaces which swallow any pointer (user or kernel) because otherwise > this really boils down to a single OR resp. AND operation plus the > according mov to retrieve the mask. Are there any of those left? Most will have gone with setfs(KERNEL_DS) removal. Almost all code has to know whether an address is user or kernel - the value can't be used because of architectures that use the same address values in user and kernel. How often do addresses actually need de-tagging? Probably only code that is looking for page table entries for virtual addresses? How often does that happen for user addresses? If the hardware is ignoring the bits then you don't need to remove them before memory accesses. That would include all userspace accesses. Clearly access_ok() has to work with tagged addresses, but that doesn't require the tag be masked off. It can just check the transfer doesn't cross 1u<<63. It (probably) just requires the fault handler to treat non-canonical address faults as page faults. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)