Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp981708iob; Fri, 13 May 2022 18:29:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwlEO5KwZf0QfF2MlsPox5u+FE0Zb0SunTzuA91C40CxH5hNi0ArNcFQJysA92Rt8jEsTzJ X-Received: by 2002:a7b:ce8f:0:b0:394:46ae:549e with SMTP id q15-20020a7bce8f000000b0039446ae549emr6946444wmj.54.1652491794626; Fri, 13 May 2022 18:29:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652491794; cv=none; d=google.com; s=arc-20160816; b=fFZlXE42pYlzX93Jardco9hyd9P4kIP38dGaIrv2/d0TyfpFihI1HC6O9Hi9sf+5BF IaXBBUm4WzUthOm0k97Dt/sBT2nrEDGQV/Kg83heeTzXa9Ycl6i6R7FPITSj0Yl6aNmp 7YaFmyR51X2cOt5dMBtzT7vyu8t8Thi0D4QNaH2qAcsspoyv/3ZhIFLkrS1epbwzK9ne mISr6GBp+rKFdmMl7ZVsKzM6Uk4Y38G+BDB421BDQ/hYNaQR+1xFTjMxLQ++WdX94Fbg Uj97KU92ikq1mvBWeTFX669suazOv0SUCyvgaxk5OgFH/PCvPL965relW+TsrvjLR4y0 pksw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:accept-language:in-reply-to:references:message-id:date :thread-index:thread-topic:subject:cc:to:from; bh=bSQU+skWxgwk8KFh35pNaBrysndazXdkuyyBFCEvQSY=; b=z744lndLYs+52y93UK20ea49yljtiBOLPZuigqQR/e1W7vyqq7ZwiSYMYlpby/R5by qFhMHWY9CCjLDX3yO28AuMXKAtKRPtxfG0JCWqA/ozsg6IX+DwER03rCd3hxh3RMiwTv zUL7wvmrPuEiW/JonIcJMkSwWGz3uZXwjmBebW42QICfI/uumA/gjmJrycU+ySF/X4+9 cbpagxjChvRoiG3Oq0HuKBO1Ssnh7ILi2DO+OSvxBaknsxbRVKDlSEs0f8ZUI0g4gQVK Nmw/79yddZrVj8SUahZl29uWsVxdRMw2MCp2RW8FDdEr/ATtk1uj7kppVRV0NoAPQAiG jp4A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=aculab.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id b4-20020a05600018a400b00203e9019690si5191408wri.1044.2022.05.13.18.29.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 18:29:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=aculab.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D82953F662A; Fri, 13 May 2022 16:58:22 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379293AbiEMKOa convert rfc822-to-8bit (ORCPT + 99 others); Fri, 13 May 2022 06:14:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229822AbiEMKO3 (ORCPT ); Fri, 13 May 2022 06:14:29 -0400 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0FB3F880EC for ; Fri, 13 May 2022 03:14:26 -0700 (PDT) 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 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)