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 B0C25C43334 for ; Wed, 20 Jul 2022 08:20:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C43316B0072; Wed, 20 Jul 2022 04:20:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF42B6B0073; Wed, 20 Jul 2022 04:20:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABB2E6B0074; Wed, 20 Jul 2022 04:20:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9CCDB6B0072 for ; Wed, 20 Jul 2022 04:20:14 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 61F781A04FF for ; Wed, 20 Jul 2022 08:20:14 +0000 (UTC) X-FDA: 79706780748.19.9D86A5D Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf09.hostedemail.com (Postfix) with ESMTP id 090FD14000C for ; Wed, 20 Jul 2022 08:20:13 +0000 (UTC) Received: by mail-yb1-f171.google.com with SMTP id 64so30866024ybt.12 for ; Wed, 20 Jul 2022 01:20:13 -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:content-transfer-encoding; bh=J0M63ZbgDC7xQ5EwBxC6IcpLq6pCXZViuh69dP2t4M4=; b=grv6cjZ1OLCbVvxLWw/8kFDTJlSRkm9ybJEqphSyPWnZeLDuEqdr3GrBvDGof30V7E N+e0zxzbkxvL4S202GcKPwGLrPDatCiscatboB9DaMc1tqDiEcub9H+KNZU9/UERNW/3 u9U8R8Sl8O4GMu37Ux+bkD5jYlTEiOhlvUmr6uucfTsGYPngGe0ivN2nfrUoqDefl19h ik8weOj8635dTfoyNAzc2jriOWAgpvDE0Jvil0V9eFnDn2YejdSmrXdxk+UaGFs4Vx7g LGiAU443ow+tHu5BFnLuHl/kCyAfZJK/eSHeYbbXd03tQj5NoU+MidGoOL4lTD1mAPc2 bduw== 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:content-transfer-encoding; bh=J0M63ZbgDC7xQ5EwBxC6IcpLq6pCXZViuh69dP2t4M4=; b=HeSrmV1+8CN426+69gIhhM3UYSxaVVm5zA9ovMNfmEBQ7eQ7Q1vGyplCn2I6gqj2uT txW2DKDIRlTzqS6TH+eYfvFnRQlE+YpujMR5HQsRSZhKAaymKppQdPYqINypyiCd2Ybg Vt4JDxgD2DnZT2iT620tO/Fxg4AtBVOhLYcSK/bppFPxquVVyvVgV8JIRXsGe9F7Z6kx xAahPGvhMZZ4ioDA/odLOfI1CX1xKxGx1I/r1fHlaseP/CXRcCcXd12FwIIRRorFETgT kAlAy96sqTE7R7d30eL4evP6U9hTd60PIygArA00Odeue0Ys25xjC/NrZKh9fUbeISer N7Qw== X-Gm-Message-State: AJIora8wLyYVQbTn5UsF5+DY5x/8oy6TJCnGjfFzp+KsYWNW5OnezFvW Cs+InrwkxtNSjEDjaxKtL8BaRJx9pjXCaN80ERC2wQ== X-Google-Smtp-Source: AGRyM1txbe9fP0TCW8vkpS0DylAxl0pyGSHgCt2clQXUA3ZsUmqZ2G9C/cx/GKTb5b36/jML+lPfm0g24Zl8qdtn+Yg= X-Received: by 2002:a25:d64a:0:b0:66f:7d56:913d with SMTP id n71-20020a25d64a000000b0066f7d56913dmr38735369ybg.199.1658305213152; Wed, 20 Jul 2022 01:20:13 -0700 (PDT) MIME-Version: 1.0 References: <20220712231328.5294-1-kirill.shutemov@linux.intel.com> <20220712231328.5294-7-kirill.shutemov@linux.intel.com> <20220720005724.mwodxwm5r5gayqrm@black.fi.intel.com> In-Reply-To: <20220720005724.mwodxwm5r5gayqrm@black.fi.intel.com> From: Alexander Potapenko Date: Wed, 20 Jul 2022 10:19:36 +0200 Message-ID: Subject: Re: [PATCHv5 06/13] 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 , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=grv6cjZ1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of glider@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=glider@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658305214; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=J0M63ZbgDC7xQ5EwBxC6IcpLq6pCXZViuh69dP2t4M4=; b=yfKVnsP/vghlBNz4QkaB1JreO3D+ef5ivhRMM1KfEm8wy3ZxHIiAh6zFlKvRqA7hnxZ2kl 05xPdC33sc/BIcUMbp3m1GAQhPFcWltF9efIBRaMwAhwB3qCRFTzgd+BcUjs7KgqskeuYR ny4mLPcGVNre6ObJzIxz7C4Z2OssGGw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658305214; a=rsa-sha256; cv=none; b=T8tGBgpLt2tIsuNSJ2GSY2vgBQakCiNvNQB2Z79C4oDI99QhgcjLOPXgfzcFg0YmHCVa1W b+VuxPN8po1LrJeJaCoYbPwB6tStIfoc14HpsLHOt/3xa5bK/TGq7ivel9SnAVGZQKJeq7 ELiLTEqCgNhMUnymINfUlz4m5dCjOEs= X-Rspamd-Queue-Id: 090FD14000C Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=grv6cjZ1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of glider@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=glider@google.com X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 8jine1uniecqxxndkzz7msm5iw1zygyf X-HE-Tag: 1658305213-889584 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, Jul 20, 2022 at 2:57 AM Kirill A. Shutemov wrote: > > On Mon, Jul 18, 2022 at 07:47:44PM +0200, Alexander Potapenko wrote: > > On Wed, Jul 13, 2022 at 1:13 AM Kirill A. Shutemov > > wrote: > > > > > > Add a couple of arch_prctl() handles: > > > > > > - ARCH_ENABLE_TAGGED_ADDR enabled LAM. The argument is required numb= er > > > 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. > > > > > > Signed-off-by: Kirill A. Shutemov > > > --- > > > arch/x86/include/uapi/asm/prctl.h | 3 ++ > > > arch/x86/kernel/process_64.c | 60 +++++++++++++++++++++++++++++= +- > > > 2 files changed, 62 insertions(+), 1 deletion(-) > > > > > > > + > > > +static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned l= ong nr_bits) > > > +{ > > > + int ret =3D 0; > > > + > > > + if (!cpu_feature_enabled(X86_FEATURE_LAM)) > > > + return -ENODEV; > > > > Hm, I used to think ENODEV is specific to devices, and -EINVAL is more > > appropriate here. > > On the other hand, e.g. prctl(PR_SET_SPECULATION_CTRL) can also return = ENODEV... > > I'm fine either way. Although there are way too many -EINVALs around, so > it does not communicate much to user. > > > > long do_arch_prctl_64(struct task_struct *task, int option, unsigned= long arg2) > > > { > > > int ret =3D 0; > > > @@ -829,7 +883,11 @@ long do_arch_prctl_64(struct task_struct *task, = int option, unsigned long arg2) > > > case ARCH_MAP_VDSO_64: > > > return prctl_map_vdso(&vdso_image_64, arg2); > > > #endif > > > - > > > + case ARCH_GET_UNTAG_MASK: > > > + return put_user(task->mm->context.untag_mask, > > > + (unsigned long __user *)arg2); > > > > Can we have ARCH_GET_UNTAG_MASK return the same error value (ENODEV or > > EINVAL) as ARCH_ENABLE_TAGGED_ADDR in the case the host doesn't > > support LAM? > > After all, the mask does not make much sense in this case. > > I'm not sure about this. > > As it is ARCH_GET_UNTAG_MASK returns -1UL mask if LAM is not present or > not enabled. Applying this mask will give correct result for both. Is anyone going to use this mask if tagging is unsupported? Tools like HWASan won't even try to proceed in that case. > Why is -ENODEV better here? Looks like just more work for userspace. This boils down to the question of detecting LAM support I raised previousl= y. It's nice to have a syscall without side effects to check whether LAM can be enabled at all (e.g. one can do the check in the parent process and conditionally enable LAM in certain, but not all, child processes) CPUID won't help here, because the presence of the LAM bit in CPUID doesn't guarantee its support in the kernel, and every other solution is more complicated than just issuing a system call. Note that TBI has PR_GET_TAGGED_ADDR_CTRL, which can be used to detect the presence of memory tagging support. > > > > > > + case ARCH_ENABLE_TAGGED_ADDR: > > > + return prctl_enable_tagged_addr(task->mm, arg2); > > > default: > > > ret =3D -EINVAL; > > > break; > > > -- > > > 2.35.1 > > > > > > > > > -- > > Alexander Potapenko > > Software Engineer > > > > Google Germany GmbH > > Erika-Mann-Stra=C3=9Fe, 33 > > 80636 M=C3=BCnchen > > > > Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian > > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > -- > Kirill A. Shutemov --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg