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 2DE3BC43334 for ; Sun, 12 Jun 2022 21:04:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D8008D0138; Sun, 12 Jun 2022 17:04:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9871C8D0135; Sun, 12 Jun 2022 17:04:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8013D8D0138; Sun, 12 Jun 2022 17:04:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6C4778D0135 for ; Sun, 12 Jun 2022 17:04:08 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 29FA21208AC for ; Sun, 12 Jun 2022 21:04:08 +0000 (UTC) X-FDA: 79570811376.15.529B5B2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id AF3FE1C0094 for ; Sun, 12 Jun 2022 21:04:07 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B7A9161004; Sun, 12 Jun 2022 21:04:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B41AFC34115; Sun, 12 Jun 2022 21:04:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655067846; bh=aYXiIBYKvoFj5z94fquzqeoEWIZqOnibRde30CWTxP4=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=GPjhlV70l5vBYnlKCrhK3eRHlAmchzSOeHrT48cyliYhfqhl85PEQl2ozJ2uwdjXU bnDhG2Tjog3ANCw2W8SP6kgHiivwIht4TU+bDLpqN2m9iNAQ31/oGv24IVkuQJLGoj mKPHMKogD4++HD8WXC591dJmngLX7liLRhIIYW4X/bPNG62q6RkmFyHNel8UdCwmvX qfLUoyIO/zFfPjeyXaIqFqUBhrjZgJB2qs9XP57gJdYLbM94KkR0SbQEHF9Way3Wbo EvVTHrft1VLP/lH81RQUzdOQST1e5Zy+Z5ksk9yTX1NiMUItvHeLy8LITU90utzsNC A5lM1qi4jn5Ew== Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 94ABB27C0054; Sun, 12 Jun 2022 17:04:04 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Sun, 12 Jun 2022 17:04:04 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudduhedgudehgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdet nhguhicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenuc ggtffrrghtthgvrhhnpedvhfeuvddthfdufffhkeekffetgffhledtleegffetheeugeej ffduhefgteeihfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedu keehieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinh hugidrlhhuthhordhush X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E136331A0062; Sun, 12 Jun 2022 17:04:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361 Mime-Version: 1.0 Message-Id: <5d3b281f-3d8b-4bbd-9681-b226810c3e8b@www.fastmail.com> In-Reply-To: References: <20220610143527.22974-1-kirill.shutemov@linux.intel.com> <20220610143527.22974-7-kirill.shutemov@linux.intel.com> <20220610180635.l44opq2votd3gxpl@black.fi.intel.com> <5b56c88e477d879e5a0e3c15627cb05901a812f4.camel@intel.com> Date: Sun, 12 Jun 2022 14:03:43 -0700 From: "Andy Lutomirski" To: "Rick P Edgecombe" , "Kirill A. Shutemov" Cc: "Linux Kernel Mailing List" , "Peter Zijlstra (Intel)" , "H.J. Lu" , "linux-mm@kvack.org" , "Dave Hansen" , "andreyknvl@gmail.com" , "kcc@google.com" , "Andi Kleen" , "dvyukov@google.com" , "the arch/x86 maintainers" , "ryabinin.a.a@gmail.com" , "glider@google.com" Subject: Re: [PATCHv3 6/8] x86/mm: Provide ARCH_GET_UNTAG_MASK and ARCH_ENABLE_TAGGED_ADDR Content-Type: text/plain ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655067847; a=rsa-sha256; cv=none; b=M9zqGM+NCLxzNrN3zftQWlkIBALeRb1SF6dvXIijEmHGp0nQ+3/xIjeenyiULcFRB86WDZ gdraAXx4guRDkLzmcsxRID0q8pgQhrrSKRmnBIo1vallyKMC4C46Djg/4ksRLZV0ahhufs FJ6wiCXvYZFjZazPkIhi3bVKgyNE1dk= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GPjhlV70; spf=pass (imf21.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655067847; 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=J0O7YUoyjNt/FuixLFKgSL2TwM+n7Vzm9WZko1GIpNI=; b=1SMfEBk7TyZbYjIcyMEsE/npltTTo4nlVnylV/YUdyt7vMfWRPPgoMmDYC6xdLz9JPcBTR mo1UXgzXDT2bawOnOIvCazJj3Sk3BGMnlzjaOdioKzmOgtyAEoQfk9ZPEKS4ppO5nY63mQ ZU3jrMgepafXfB6ucjkGZxX2d56I5m0= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AF3FE1C0094 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GPjhlV70; spf=pass (imf21.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: khfxhui5yybicry1ozp1umpp1tqy7u59 X-HE-Tag: 1655067847-845792 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 Fri, Jun 10, 2022, at 3:18 PM, Edgecombe, Rick P wrote: > On Fri, 2022-06-10 at 11:08 -0700, Edgecombe, Richard P wrote: >> On Fri, 2022-06-10 at 21:06 +0300, Kirill A. Shutemov wrote: >> > On Fri, Jun 10, 2022 at 04:16:01PM +0000, Edgecombe, Rick P wrote: >> > > On Fri, 2022-06-10 at 17:35 +0300, Kirill A. Shutemov wrote: >> > > > +static int prctl_enable_tagged_addr(unsigned long nr_bits) >> > > > +{ >> > > > + struct mm_struct *mm = current->mm; >> > > > + >> > > > + /* Already enabled? */ >> > > > + if (mm->context.lam_cr3_mask) >> > > > + return -EBUSY; >> > > > + >> > > > + /* LAM has to be enabled before spawning threads */ >> > > > + if (get_nr_threads(current) > 1) >> > > > + return -EBUSY; >> > > >> > > Does this work for vfork()? I guess the idea is that locking is >> > > not >> > > needed below because there is only one thread with the MM, but >> > > with >> > > vfork() another task could operate on the MM, call fork(), etc. >> > > I'm >> > > not >> > > sure... >> > >> > I'm not sure I follow. vfork() blocks parent process until child >> > exit >> > or >> > execve(). I don't see how it is a problem. >> >> Oh yea, you're right. > > Actually, I guess vfork() only suspends the calling thread. So what if > you had: > 1. Parent spawns a bunch of threads > 2. vforks() > 3. Child enables LAM (it only has one thread, so succeeds) > 4. Child exits() > 5. Parent has some threads with LAM, and some not > > It's some weird userspace that doesn't deserve to have things work for > it, but I wonder if it could open up little races around untagging. As > an example, KVM might have a super narrow race where it checks for tags > in memslots using addr != untagged_addr(addr) before checking > access_ok(addr, ...). See __kvm_set_memory_region(). If mm- >>context.untag_mask got set in the middle, tagged memslots could be > added. get_nr_threads() is the wrong thing. Either look at mm->mm_users or find a way to get rid of this restriction entirely. IMO it would not be insane to have a way to iterate over all tasks using an mm. But doing this for io_uring, etc might be interesting.