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 7FEC6C433EF for ; Wed, 20 Jul 2022 00:57:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9CF06B0072; Tue, 19 Jul 2022 20:57:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B4C116B0073; Tue, 19 Jul 2022 20:57:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A13AE6B0074; Tue, 19 Jul 2022 20:57:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 930D26B0072 for ; Tue, 19 Jul 2022 20:57:40 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5DA0F80273 for ; Wed, 20 Jul 2022 00:57:40 +0000 (UTC) X-FDA: 79705665480.16.9841DB5 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf27.hostedemail.com (Postfix) with ESMTP id 9079540007 for ; Wed, 20 Jul 2022 00:57:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658278659; x=1689814659; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=F7g3ynXWOMTKVN0gg82mLeRiQZLN1+/2VVU531tlYIM=; b=nQFjkHQ5YTBpcFDX1SXykke8ruptCexFHt1phpGwMrZvZkWLmr73UOMO 1xkvqnzFMr2YjCGIxtU7uEV2h/A9VGPjZrTsWC37qqtzUYYR/927fRRSw Z0QgqRUmolZUaonTNYmOk9DPDVsIqJLG21Cg44kpnEJUBZleCC058WQFI e5VUoJG6lctQgsaPJgRuzeO9Gy6g6g9RqGONTTN3dxsvbzHdahlnKDpsM Xql/MpEkm1iyHdJAQ8NGGmJk1thO8kodKuO2v1IQFpTWNzHzTQdUls2Jx PZfQ80xlHwbulF/eiA+W43QsfK7FQa/girPBkxDQC9zh7lBwb+YNNMAbT Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10413"; a="312337369" X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="312337369" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 17:57:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="724466919" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga004.jf.intel.com with ESMTP; 19 Jul 2022 17:57:16 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 16292136; Wed, 20 Jul 2022 03:57:24 +0300 (EEST) Date: Wed, 20 Jul 2022 03:57:24 +0300 From: "Kirill A. Shutemov" To: Alexander Potapenko 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 Subject: Re: [PATCHv5 06/13] x86/mm: Provide ARCH_GET_UNTAG_MASK and ARCH_ENABLE_TAGGED_ADDR Message-ID: <20220720005724.mwodxwm5r5gayqrm@black.fi.intel.com> References: <20220712231328.5294-1-kirill.shutemov@linux.intel.com> <20220712231328.5294-7-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658278659; a=rsa-sha256; cv=none; b=JZfK+GDAtmsgMBrId1ZenrVjXt/Evyx1dzqptorVP0UEZLovcyYZnk/pmWdkIEKFiDYoJ3 sD23YNGxau5nbdMeECoVD6fx7b3/ACk4NQIP8vAClGlXM+DynqBcwSAmgYZ+FVB+7nRS0z 8wE+5kXskI3M04GRxWFHuVKFlPp/AFU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=nQFjkHQ5; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf27.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658278659; 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=UF9VFqIXr3ldmev2l7Hw50/k5At0fmfHNSR9uJ1VRQ8=; b=JQH63qdJtN8FbuxHG/5dZ66qlGJo0MKwUTj0BUQUXzVlhDwuCZKuYKgs9g/g36Q27+lbEJ 0AJl3CxcvtJ2oCXIgpUky3vxq0fVLD/TNddWtN2m5dhSzopE/0b5nIb/rneVkPko7xlbfH c/UgJxRuvZu85NRhhGre7LPTDaowJzk= X-Rspam-User: Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=nQFjkHQ5; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf27.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kirill.shutemov@linux.intel.com X-Stat-Signature: h3k5xsyj9uno4pf9nxmtcapqs1u4xtwb X-Rspamd-Queue-Id: 9079540007 X-Rspamd-Server: rspam02 X-HE-Tag: 1658278659-64753 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, 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 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. > > > > 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 long nr_bits) > > +{ > > + int ret = 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 = 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. Why is -ENODEV better here? Looks like just more work for userspace. > > > + case ARCH_ENABLE_TAGGED_ADDR: > > + return prctl_enable_tagged_addr(task->mm, arg2); > > default: > > ret = -EINVAL; > > break; > > -- > > 2.35.1 > > > > > -- > Alexander Potapenko > Software Engineer > > Google Germany GmbH > Erika-Mann-Straße, 33 > 80636 München > > Geschäftsführer: Paul Manicle, Liana Sebastian > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg -- Kirill A. Shutemov