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 C4A88C433EF for ; Tue, 12 Jul 2022 13:12:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43A3894006E; Tue, 12 Jul 2022 09:12:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E63C940063; Tue, 12 Jul 2022 09:12:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AE7D94006E; Tue, 12 Jul 2022 09:12:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 182E4940063 for ; Tue, 12 Jul 2022 09:12:41 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id E2F35120CF4 for ; Tue, 12 Jul 2022 13:12:40 +0000 (UTC) X-FDA: 79678487280.31.1F42C4B Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf26.hostedemail.com (Postfix) with ESMTP id 7C0C514005A for ; Tue, 12 Jul 2022 13:12:40 +0000 (UTC) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-2ef5380669cso80245927b3.9 for ; Tue, 12 Jul 2022 06:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KBJt/ZY7JUr2TOwBsMYX0RVyZ0ct+EhUSprZZakawl8=; b=Ac6aJ8LymDQtz3c/Bhq/2F/pkevtouN0FhnMH20eci3WDinrK4xqnrc6G0GgM60KCT pg3r0lYFx3p+/pOEgbZmSki8x1dAeNg1RxxhY2V4NZ1gxqhPlj5XKRjh5oDOLhOwi1Wx rf/3MdPLWZZ4f+uRuCxsCadjJZbTL+i2ns//0z31IpMiRchtC9If+DCNDNoevXNEEOlq RNzMo+NNEMlcTOdEqV2OnfLDmetEl+IzXY61yDYwAgHrW/nVPZOsEspeQ5Q1Ix8hYZOt rxrBGvnThpnknWq2yCBpW0cS3kuvo839ZDc1nK1ydyZ51B2W8C0wGBXvaiHaMgtoXVpN sPPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KBJt/ZY7JUr2TOwBsMYX0RVyZ0ct+EhUSprZZakawl8=; b=zza/HCny/0DDXSa3Ni8iTn0kR3NgQbv8Ddx7Fs35cxv6WvUyLm1LnHCHxLNKOWrtDD lhk6BTn4iyj57yGwe/7j9AaV2zfVza7qd9DnUr6jHLHhhl5U4nzVUYLjIKYOGcH7A6ah MslLMFxsHZHSZ/FYFceSnockfp8XVdlDPyUzdX0EojJLdD1d/+TEZ+nx73u/vPS9nUPk GJoJycmJmKu6wxKBnw3QxIS4PN7tJTitTVgxs7H7uwroey8OuP4Ik6BJ3w9YqKeX+0u5 i1a8vpI3oBNqn43ceA17/hn1raHjPjSErzLNqSRpsx8BK/ppxmwFgEn8Sa+iN5LMlj97 zWTw== X-Gm-Message-State: AJIora/CHn6GbKXDKZgWusfJUrANsDKly20yLqBrBRnD5rQn6pfQTM9w A9jRbQ8lZ4Aii7uDvwwa0narjWRb/0pc1X7WD3oYCw== X-Google-Smtp-Source: AGRyM1sRIADhc2NCqhuRXWHxMrZcmI73f2iorfJMM2ojLdc4BKcArJh2yO46VZXMeBPCTNxK7WcZ9SF4eKVlGjQcEKg= X-Received: by 2002:a81:6cf:0:b0:31c:913c:144c with SMTP id 198-20020a8106cf000000b0031c913c144cmr25626639ywg.437.1657631559629; Tue, 12 Jul 2022 06:12:39 -0700 (PDT) MIME-Version: 1.0 References: <20220622162230.83474-1-kirill.shutemov@linux.intel.com> <20220622162230.83474-7-kirill.shutemov@linux.intel.com> In-Reply-To: <20220622162230.83474-7-kirill.shutemov@linux.intel.com> From: Alexander Potapenko Date: Tue, 12 Jul 2022 15:12:01 +0200 Message-ID: Subject: Re: [PATCHv4 6/8] x86/mm: Provide ARCH_GET_UNTAG_MASK and ARCH_ENABLE_TAGGED_ADDR To: "Kirill A. Shutemov" Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , "the arch/x86 maintainers" , Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657631560; 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=KBJt/ZY7JUr2TOwBsMYX0RVyZ0ct+EhUSprZZakawl8=; b=7LGBCrP9wRtpNglFJzH4f2egESrufEgwF4+2RYMIA7QOMlvV1dq00zc2oWG404T6bLPPWc XBO7+HQZO0yXpckHi2SFlG8xGAih8ZMeuLGLPthZfosoFkmRkUuKvoJ1JnQUzetbXRL1vy n/ZrxxesgWx5tq3z3DyaERVYM2WEcw0= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ac6aJ8Ly; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of glider@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=glider@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657631560; a=rsa-sha256; cv=none; b=5QW5jNJzE9WJ+f4WBNiiybh3zzBVu/bA76tPZrCLptsMPzBncGGbxeqJmpFpnRTSyjUskX n8xJwndbcVe9IN34DrB6gWtGMuy/lDGsHQdA2uSk+7GyKPzl8fM0WxARj82P/MFAl2bNUN QD2MD6+J8gk8fPC0rdUvHSwCDF9qkFs= X-Stat-Signature: ybap5tg9jniz51dh3wgh47kc58uo6wei X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 7C0C514005A Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ac6aJ8Ly; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of glider@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=glider@google.com X-Rspam-User: X-HE-Tag: 1657631560-840254 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 Wed, Jun 22, 2022 at 6:22 PM Kirill A. Shutemov wrote: > > Add a couple of arch_prctl() handles: > > - ARCH_ENABLE_TAGGED_ADDR enabled LAM. The argument is required number > of tag bits. It is rounded up to the nearest LAM mode that can > provide it. For now only LAM_U57 is supported, with 6 tag bits. > > - ARCH_GET_UNTAG_MASK returns untag mask. It can indicates where tag > bits located in the address. > Am I right that the desired way to detect the presence of LAM without enabling it is to check that arch_prctl(ARCH_GET_UNTAG_MASK, ...) returns zero? Overall, I think these new arch_prctls should be documented following the spirit of PR_SET_TAGGED_ADDR_CTRL/PR_GET_TAGGED_ADDR_CTRL somewhere. > + > +static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits) > +{ > + int ret = 0; > + > + if (!cpu_feature_enabled(X86_FEATURE_LAM)) > + return -ENODEV; > + > + mutex_lock(&mm->context.lock); > + > + /* Already enabled? */ > + if (mm->context.lam_cr3_mask) { > + ret = -EBUSY; > + goto out; > + } > + > + if (!nr_bits) { > + ret = -EINVAL; One would expect that `arch_prctl(ARCH_ENABLE_TAGGED_ADDR, 0)` disables tagging for the current process. Shouldn't this workflow be supported as well?