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 9C16EEEAA42 for ; Fri, 15 Sep 2023 04:15:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E72346B0315; Fri, 15 Sep 2023 00:15:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DFB326B0317; Fri, 15 Sep 2023 00:15:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9C616B0319; Fri, 15 Sep 2023 00:15:48 -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 B85DF6B0315 for ; Fri, 15 Sep 2023 00:15:48 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6E065A07D0 for ; Fri, 15 Sep 2023 04:15:48 +0000 (UTC) X-FDA: 81237518376.08.E4553BC Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf23.hostedemail.com (Postfix) with ESMTP id B1514140017 for ; Fri, 15 Sep 2023 04:15:46 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zsWxGJcV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694751346; 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=FamDpRRxOJ58SltchwNZF7P11BnxlXwApaRPCg7sEgs=; b=DFOh7yEntr/5rRfc338BQXLahKupke8LlnjewNQaawPdD3fwoZ+ry1pkEnO5ZVT56eiBhx kWZOp0oCx/RHbllyN1O3Yu21TLMdfsFdYfBe/dPckeNgPkEs40BUztl5EgLcTzUxCqB1QM wjfDx2JcI31ooymkRQgLnUxgRiAejVE= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zsWxGJcV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694751346; a=rsa-sha256; cv=none; b=bEFbruxjfETPJ6sN0elB4x4WOHWRRAi6eGhE9BYww+Rv+p/tP1yPZ/Kqu4HI0B1W1AUpyU RiOBpgjmr9r6nCatyLaTHxYZ95ly5gUvh7g4xjwhPW8xUR+OLjJimPwH7XHPmKxcsOaFZI 52jcuisQHzBL0yxQZ/MrPE1S+pZaZ+Q= Received: by mail-yb1-f180.google.com with SMTP id 3f1490d57ef6-d81adf0d57fso970079276.1 for ; Thu, 14 Sep 2023 21:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694751346; x=1695356146; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FamDpRRxOJ58SltchwNZF7P11BnxlXwApaRPCg7sEgs=; b=zsWxGJcVNkm5Gr/dWD/ktbISMgU79mNmEhlOVTcXK4H8KVQur+jNbpnId5ocPBcdUe juOVZOhVW7xgqkdgS08r+nEAVwX2wX3rSKAK/pKZXq+JnWbvLamSuo0B5NskKUD9wwBE FNWj08cW4Tf7JbexauP80zjhJ53XJLB++doEqlZrOBUCDrJPQeGPPfaKkatT2MImqC0Y FNe+hHq6aCn/VncsN3aKkkomKPphJ4G2tok+AFqebkjT09hoQOBxN6e5XzyKEnWfZZjt oHJlws7pUMEILtc4yPMOuDquOD3XDX4bWJ4YN8cGxSpb25hoacp1HojHNcJwrSQQGK2v xO+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694751346; x=1695356146; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FamDpRRxOJ58SltchwNZF7P11BnxlXwApaRPCg7sEgs=; b=rpKJBhI1dLRTtR3cr1tDy6r+6EgfOQHJx0+CHh8YI4hBnjyQEFuiTDStE4Evgu2780 Il8KRPW07z380yYq9BbzdvbHoCNCxGPoP5qPFblwCe/v7GY4d3uPJ1HnwQDD1XJYPYBG wVCQkJWJ/itOHJOHYSDhSq74S735/G9jTvJ69OJ1VWh/l8YFEsUJjxJEhh/YDsalq4NO ojPyIcIjQhOczh+dG7zHaGvaaaG9Ph/tDIocq0lFjIZjorJQubn6rwS5WzuXawfdr3/x 3bk+mFO5m4sZw47bZd64BlXOLhO9niOxX26IciujTu8lgVxOfZkysUzSZenMsnxzIwzO OLIg== X-Gm-Message-State: AOJu0Yzm0CDmNT0j0EDYqqkQQmmcUcLaLOfVw175mtfJSV3GkFE59LZU 3ds7YZb+dTFFuSqKHUTPpQhABMWISuTZ9g6QfmcxbA== X-Google-Smtp-Source: AGHT+IFnqWx0uXRyMpqiHFFl7wXq7TmCLUPNB45WfzsSh3Iwf38WnhwAFRVFx/qVUqXsUALqr8w0a8O7MgSyOCVK4No= X-Received: by 2002:a25:ae1c:0:b0:d4d:f157:9673 with SMTP id a28-20020a25ae1c000000b00d4df1579673mr418753ybj.26.1694751345603; Thu, 14 Sep 2023 21:15:45 -0700 (PDT) MIME-Version: 1.0 References: <20230914152620.2743033-1-surenb@google.com> <20230914152620.2743033-3-surenb@google.com> <4F9BBE45-22D0-4F8D-BA56-CA3459998DC4@gmail.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 14 Sep 2023 21:15:31 -0700 Message-ID: Subject: Re: [PATCH 2/3] userfaultfd: UFFDIO_REMAP uABI To: Nadav Amit Cc: Andrew Morton , viro@zeniv.linux.org.uk, brauner@kernel.org, shuah@kernel.org, Andrea Arcangeli , lokeshgidra@google.com, Peter Xu , David Hildenbrand , Hugh Dickins , mhocko@suse.com, Axel Rasmussen , Mike Rapoport , Matthew Wilcox , Liam.Howlett@oracle.com, Jann Horn , zhangpeng362@huawei.com, bgeffon@google.com, kaleshsingh@google.com, ngeoffray@google.com, jdduke@google.com, linux-mm , linux-fsdevel@vger.kernel.org, Linux Kernel Mailing List , linux-kselftest@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: hat8si3jis3ss6hfer51tcm4j9874ngi X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B1514140017 X-HE-Tag: 1694751346-343713 X-HE-Meta: U2FsdGVkX18T8EF/O7JSBYUky7j+n5oSbUJ6gdCZrkAlNz9g2yVRLZmcazbwALtiZALkOqVR/3DyRpmh1zT9XtRJCrKx9oni5fYxTXoD+KrzRzkPHq9S56Dsi1Z39H83TyBcC3JQSZsbg/vHHLamHxd5hqbtyciCTD6A7MlvS6c2cMHx1FGOgYBWC/L8i9aPcegldjszWa34jp1D7OGPfbx9rIML/Npq1uIySpjBviC1jz4bIZGMRiEPOIvLwy3k2QMaY79tRwX0+hk32FL37WSHjwgKmgRNKMiMEO5kzPqXRy+dWl8PuQ06zt8SVL6NT6s/4ZAfXZYVdQFTVhFPaCvUhg2Smequbka0yW6RzzhJGNsGPMEaz4n1gFcIcZu/Y0YJRWfnNzlxAb8CIjOERXyilbbGRaabkCiZunxISIxrw46c5ErHHNzpOP0GZY0UTJ0FcAvpwh8lPvgd/RaItptsU+CAelG7x0dQ8icNZqG6PU9RcLytk5KYAKFpWcrbG11VdaqoneB8k2k7Rq3y90BBCAUQqSG+rLbysYs+ZgfJq5nbLf3aONS2dxV+nFAEEPs2d1PB/FhIsL99C4ebk6gQAy1HmjZ2qoj3+m2DJoa8Hlid08/VGvxh8jaDESsShJvDaa5xgj3z5eVYvOCUw0U4OM2x0OqORW2JjPCEKHqv9tOKndrNxspL+MBKMor8bnzlD9COn4JoYH8J9Q/l8iaHmg/nclu1KHrMy9kjQcA4U10p3mdJBaCNfvMa0krOrUWVilvE0o6Kxyk0nr9/2/A7Bb5joU2XLJeEXSwFWrCwe8hdm2HbEK8KxEMsx6RN0VToWmXcMLKa8FQbY3Q2YLkhCkXWXGNTmDDZ82FmnFRr6oRWW0OIvS0/66BhkOBHPRnzASpUPOBssBi4asI+C/nUZaBcPkEQ7Bg3ktxFIXwgPrqxRYe88X0+1KsKSkonkvKlngkrWdtkxg6wbNX nyHKGhpB rmwnWRJZ/F/+82koxbBwU+Zdef8xcutrZ8SOvHQmUF7iHD86267TarQy1WP2SjLfrwlE4pF1ZW7YvURPUl4ncPTIxNj/RohhLgkn+h7J2J/NxbgV69Lf7jJ49HtON7qSNUVMIXKHbwLB6/4lDrhtRnhTZdLv9sgd3vG0yFdTzCKU1i90vOK/lGedzOu6/lmt/ecmVR65HDIPvmr64lEZxnu4UUQ+pfxlX4FNPOZZf38UkOh+KQiksMUqF1UnZjFOcpmQXjXMMGua0/NZ0XZn2ngoi4+/OP+vt3bUKXvDupH8Uh5V/IlMzfttspgYKsWFc2BkICb0C42s08dKY5did1PyAetpPq/pzCYH6aLXTQpdYACFh3bEPqExZrzvghXxRZe9l3UfzeeTnHoxvCUkzzYrE81WQxi2CLMxgTtEoVcxk8QvLXX6FtmB7CbMYPvRMBsCV 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, Sep 15, 2023 at 4:04=E2=80=AFAM Nadav Amit w= rote: > > > > > On Sep 14, 2023, at 8:28 PM, Suren Baghdasaryan wro= te: > > > > On Thu, Sep 14, 2023 at 2:57=E2=80=AFPM Nadav Amit wrote: > >> > >> > >>> On Sep 14, 2023, at 8:26 AM, Suren Baghdasaryan w= rote: > >>> > >>> + if (!pte_same(ptep_clear_flush(src_vma, src_addr, src_pte), > >>> + orig_src_pte)) > >>> + BUG_ON(1); > >> > >> Just a minor detail regarding these few lines: > >> > >> Besides the less-than-ideal use of BUG_ON() here, I think that this co= de > >> assumes that the PTE cannot change at this point. However, as the PTE = was > >> still mapped at this point, I think the access and dirty bits can be s= et. > > > > At this point we are holding PTLs for both PTEs (see > > double_pt_lock()). Can a PTE be modified from under us in this > > situation? > > PTEs has several parts: access-control bits (e.g., writable), physical > frame number, software-only bits and log-bits. The log-bits, which are > =E2=80=9Caccess=E2=80=9D and =E2=80=9Cdirty=E2=80=9D on x86, track whethe= r the PTE has ever been used > for translation or write correspondingly. > > Without getting into all the subtleties (e.g., =E2=80=9Caccess" can be se= t > speculatively even if no actual access take place), as long as the PTE > is present, it might be used for access (and write if it is writable) > by other cores. The page-table locks are irrelevant here, because the > PTE is not updated by software, but it is updated by the CPU itself > during the page-walk/write. Ah, I see. I believe Jann also pointed this out in one of his comments and I didn't realize that. Thanks for the note! I'll see how I can rework this. > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >