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 1095DC74A5B for ; Fri, 17 Mar 2023 23:04:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 755156B008C; Fri, 17 Mar 2023 19:04:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7056F6B0092; Fri, 17 Mar 2023 19:04:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CC406B0093; Fri, 17 Mar 2023 19:04:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4CA576B008C for ; Fri, 17 Mar 2023 19:04:19 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F3FE98061D for ; Fri, 17 Mar 2023 23:04:18 +0000 (UTC) X-FDA: 80579920596.06.03E7C46 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by imf04.hostedemail.com (Postfix) with ESMTP id 27D6640017 for ; Fri, 17 Mar 2023 23:04:16 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="qadP/ybP"; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679094257; a=rsa-sha256; cv=none; b=OgRDjWVDhzI+J1ZTnn65+f2GfytoB+HoqwuA/edJzlOU9b0ow2r4G98/RoozdOz9RkhAdf c11bqZpASPbm705ShpZ6F/+mnxQhZK7gqRZ4PpvFrHPrW/XE7uA8f+tO3omtemZ0xip/fk 9MMDMb6vRMujafq9DwN88EPOQllDdSU= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="qadP/ybP"; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679094257; 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=w2C+V/8voXxzsC2KICa9qM/vADLcn6b/HYkR0aaSEj8=; b=tD2RI/y3BaUhrTBrIMYUpmAXGsiunN2lH9onJETmdcJaFt5iT87cZTL+EHUQIHYJy2hory DzJduis2ReP+qE90c5WQ11DbpJKlVo88vQxnxZDiAZoTxQyPe4Zycceaja8itX4gFDLWrY gsHI0DeRns0JvAOdMgWpTcKHF128biQ= Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-5419d4c340aso120663937b3.11 for ; Fri, 17 Mar 2023 16:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1679094256; 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=w2C+V/8voXxzsC2KICa9qM/vADLcn6b/HYkR0aaSEj8=; b=qadP/ybP7YOevfO52m8wnUG+YiHdnOn5wiTDCLm2VjUVfUOG5wAohBATwM/IL4n8wK EUonCnQCrjtmnZRLgAC03JV9/+QCTi0BqZVDxpFq8SqiyAubeFWwbgMfqbnZcZRTl18c P1tSJdCagaQjOfouDP1NBm1bVz0SB49wHTXq7N7Gtb10cvdkyrfhhznn8dfTLLzfQ5xn VHTktar+xrik+S2ltlWJ4wrDf2vjCcW8doNdhQxWFwKhPnui+CRO0C1yWNJIJNiJ5rCB wKdladKdkllKCIdJYUqadUqaVvHHE+1Xq2vf4P6OzQfmw3LxIqhH43Ggd4aPaJltT2yX CDQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679094256; 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=w2C+V/8voXxzsC2KICa9qM/vADLcn6b/HYkR0aaSEj8=; b=KcVcap18ZBmNBP+CwuDnS+tVK9/h0fHdj2Kb57aI+ieROMxBrusyVUUnvHKZVfgXbT yUmwu744bDDD+bf0GdSaGyIVQgZnarM2PYrX4y8Ne+q3MTsXWqekTdJCveH/87BMdr+g UqaTp19YsAROAhPhiaRvT+X58yfFBFkA1d8pLyG8HXSbrvLzMzFKCZMKAPDznuRJdRfh n+zLqoLnzkFf2+UP/PLZOjAOZ2yWRFk8IaX/oWohRvMsArFK+15wz85SnjFQzfKZYv8w Jvdpr83SKkDeuD8/v/+4eV6bmdXKxBb+OJrKiKeREFcREwPYE78k/Fh6fqQpaZby9i/8 TEGQ== X-Gm-Message-State: AO0yUKW+xKbDqCBW1iDazDobKkWWHgcxZH9kxl0aldoPXfGdjrwVkxxH IQh+pnXrD3H12aEQSHZmIoF0wIBOcQfDgFqL6+dmwg== X-Google-Smtp-Source: AK7set8hywCBVoHzE2HL9COIHr0uPX9RzbYv5voQJIobm2WkCY5b7MlTeFVb42odO3dQtnivkNUSPb3IzOuPUKYTNlk= X-Received: by 2002:a81:c148:0:b0:544:51f7:83c5 with SMTP id e8-20020a81c148000000b0054451f783c5mr5551479ywl.1.1679094255994; Fri, 17 Mar 2023 16:04:15 -0700 (PDT) MIME-Version: 1.0 References: <20230126193752.297968-1-surenb@google.com> <20230314141144.6a0892e6.alex.williamson@redhat.com> <20230317164059.466d1c70.alex.williamson@redhat.com> In-Reply-To: <20230317164059.466d1c70.alex.williamson@redhat.com> From: Suren Baghdasaryan Date: Fri, 17 Mar 2023 16:04:05 -0700 Message-ID: Subject: Re: [PATCH v4 0/7] introduce vm_flags modifier functions To: Alex Williamson Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, rppt@kernel.org, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com, "Michael S. Tsirkin" , Jason Wang , Jason Gunthorpe , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , dimitri.sivanich@hpe.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 27D6640017 X-Rspamd-Server: rspam01 X-Stat-Signature: 8mr47w6ok9g1fidzh3hgprsn6ikbdj8c X-HE-Tag: 1679094256-603532 X-HE-Meta: U2FsdGVkX1942RHFa7JsViJanswrW62oq0VF8R1nIXyBtfMYZXRXNCNywXIgordorTtEPMNZASxWUzthjJkW5aZui/myL83HO+CTHxJLQhMNbjkLE10rp6G/3mgjBJGrOyHWVqXj8pjiBI9mXA4Mk854lxMbtWmmP3G2vtD6d1UGtKf6myJJO09u+dR4kcQXVKZempiOp2ebX9jOpNyq2ulcnHxos+/P/FFBbLwOyP45t0x6sJRyXAE6PDlsfpntClCkRjb3P9r9Vi2y9yLQUZydsjykXMKOP1ehSeOa7Air7B8LjcZMXbP70Vt7jT+3swbEGSEyM43AMX8HHwjTzT0srQHMsWNzyM219VQYEO9wEoxH+OksKSRm0rQHsCb4ehQFiRzRAM0e9qwmgeqJK/KyAE8PMcSXzMhvkbwQVTuX8iC1fqx/ZAWJu720RxSyOC0pqREjS8RGBdulL3zTVklVo8HaNet2KUmxprGF2Duvh9bGixinP01RhGU3/pmG8pFB4HxvnAflorfhrJqfDEwLG80xtLQQfbO4xqcrYmCkk+HBoDPJ7Y3ODkkdmH4wkFnrGxlcxl68GRJ6zVnx8cXDFj0q9U9RlanH507gnkklNTaJzkWakCrVJNqOa307af8uGLIRpzhZquA2BhC/YIa+wMwQnG73DNsjR9FxWk3BWbWTSe6Q0jOdGWGbph2srMrhnUuD5WLG38XnQ2MH2tzkhQzdv0fxEajedLxqyyFnkYI7fXzTrZEkGsQD/BdpDVzOCUQAaRd/XaYIg1zF62n/p3rMk1zR9PgTTyqFL1uIk4tTe6kdJtoKOPc3bIOuzlg1xhIGeqyiEmZXGscjYdnZmrS4gMQNeL/w4nRx19VoovuYqxiAjMYZKkET76Tm9xz7hX7YqW5Nm9Lumd2bT1KMKiDaZeDXTxZnN9s5PvSX8CS1HrdovCVQh7yXjXnyIp7JaPhvxutOQr1rfY0 Z1+p7o/x N5nLvak2q/5znOWIHdg3E3UKhLms/YkuAQhfFbyHaDVif8cwNU4+rHMuljY4Bc/HZ66htStyGrrO0jj0RaYLyzr8aDOl2JS30vKu8O1L7xBs/oXsH4Gt82nteOoaGBUbSWOv2qhFy+uP5UVlIHUFuq4jbC8EvfMixo7kawya3LTK2Dh6WgkqfivF9GaYD7CZFQ/GfEjaObLx/9xqgc3ghK4KF8KCBiRsXTYLQB9Tw5vXqGiVzcyyJVs6FmQ9NpKNQzdsBLMETnuID8iElO1XTyX/Ht8Nz5oLqGtQ5HWkKDHQfbr49ReQgjDHLB3TsEU8wYjcpl6HY+4cFD2PU/X1Ir/msyBZZ0ea/5eRH4qYKwB59IMJ5aXzFPfFJKK3rWdzA4QLiPAwffcC5i1pC95ZEBiMeeLGzC1qyCIQfK1VOfFlhcAYPqOFVPv0n3Z4khMcE3NFN 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, Mar 17, 2023 at 3:41=E2=80=AFPM Alex Williamson wrote: > > On Fri, 17 Mar 2023 12:08:32 -0700 > Suren Baghdasaryan wrote: > > > On Tue, Mar 14, 2023 at 1:11=E2=80=AFPM Alex Williamson > > wrote: > > > > > > On Thu, 26 Jan 2023 11:37:45 -0800 > > > Suren Baghdasaryan wrote: > > > > > > > This patchset was originally published as a part of per-VMA locking= [1] and > > > > was split after suggestion that it's viable on its own and to facil= itate > > > > the review process. It is now a preprequisite for the next version = of per-VMA > > > > lock patchset, which reuses vm_flags modifier functions to lock the= VMA when > > > > vm_flags are being updated. > > > > > > > > VMA vm_flags modifications are usually done under exclusive mmap_lo= ck > > > > protection because this attrubute affects other decisions like VMA = merging > > > > or splitting and races should be prevented. Introduce vm_flags modi= fier > > > > functions to enforce correct locking. > > > > > > > > The patchset applies cleanly over mm-unstable branch of mm tree. > > > > > > With this series, vfio-pci developed a bunch of warnings around not > > > holding the mmap_lock write semaphore while calling > > > io_remap_pfn_range() from our fault handler, vfio_pci_mmap_fault(). > > > > > > I suspect vdpa has the same issue for their use of remap_pfn_range() > > > from their fault handler, JasonW, MST, FYI. > > > > > > It also looks like gru_fault() would have the same issue, Dimitri. > > > > > > In all cases, we're preemptively setting vm_flags to what > > > remap_pfn_range_notrack() uses, so I thought we were safe here as I > > > specifically remember trying to avoid changing vm_flags from the > > > fault handler. But apparently that doesn't take into account > > > track_pfn_remap() where VM_PAT comes into play. > > > > > > The reason for using remap_pfn_range() on fault in vfio-pci is that > > > we're mapping device MMIO to userspace, where that MMIO can be disabl= ed > > > and we'd rather zap the mapping when that occurs so that we can sigbu= s > > > the user rather than allow the user to trigger potentially fatal bus > > > errors on the host. > > > > > > Peter Xu has suggested offline that a non-lazy approach to reinsert t= he > > > mappings might be more inline with mm expectations relative to touchi= ng > > > vm_flags during fault. What's the right solution here? Can the faul= t > > > handling be salvaged, is proactive remapping the right approach, or i= s > > > there something better? Thanks, > > > > Hi Alex, > > If in your case it's safe to change vm_flags without holding exclusive > > mmap_lock, maybe you can use __vm_flags_mod() the way I used it in > > https://lore.kernel.org/all/20230126193752.297968-7-surenb@google.com, > > while explaining why this should be safe? > > Hi Suren, > > Thanks for the reply, but I'm not sure I'm following. Are you > suggesting a bool arg added to io_remap_pfn_range(), or some new > variant of that function to conditionally use __vm_flags_mod() in place > of vm_flags_set() across the call chain? Thanks, I think either way could work but after taking a closer look, both ways would be quite ugly. If we could somehow identify that we are handling a page fault and use __vm_flags_mod() without additional parameters it would be more palatable IMHO... Peter's suggestion to avoid touching vm_flags during fault would be much cleaner but I'm not sure how easily that can be done. > > Alex > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >