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 A1992C74A5B for ; Fri, 17 Mar 2023 22:41:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F072E6B0089; Fri, 17 Mar 2023 18:41:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E90056B008A; Fri, 17 Mar 2023 18:41:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D09686B008C; Fri, 17 Mar 2023 18:41:08 -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 BA8966B0089 for ; Fri, 17 Mar 2023 18:41:08 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 85FCB140834 for ; Fri, 17 Mar 2023 22:41:08 +0000 (UTC) X-FDA: 80579862216.18.8CF5E35 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 3CEF840014 for ; Fri, 17 Mar 2023 22:41:06 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=a+C8PoK8; spf=pass (imf01.hostedemail.com: domain of alex.williamson@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=alex.williamson@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679092866; a=rsa-sha256; cv=none; b=Vy9yydBHbK0KhQ2Za7diVk7tQa5sgXheah0r04vWfh4j3WVvYsNn2tJdYZzyaWxIfa+My6 0QCGD46bHR+kTQWYK1LoRKqFEvT5Hrm3OJZznI7c4ioapbcwIyisdmpy8NLwn1OZC+sAyu dBrM81XeDzn1YBtoypm8csG8FHW3/hQ= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=a+C8PoK8; spf=pass (imf01.hostedemail.com: domain of alex.williamson@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=alex.williamson@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679092866; 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=DTqXt+xo9t4MKZl9inPofpb9h7U7JlyPPD0kMbn7WHE=; b=YU5nl4MQMYCGiKNc19yX483vj/MlbPHHATdMMIKxbGXzkjti+OFwtqu/cDHhza/hP0/URa grKQaEoiQZuk30iOcX5T+Trgw1H3Iq66UKUZzxAmtsWmHSn7AdHF7OsWP1wcb9bdZe0WCl VOr8VV3kWVRR53DKGd7F7R+fPENKZa4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679092865; h=from:from: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; bh=DTqXt+xo9t4MKZl9inPofpb9h7U7JlyPPD0kMbn7WHE=; b=a+C8PoK8O6QGcj0SWnFCIAKpJxgiZnNpUhilASsf4LwCT9hsBFDGn/Izb+udWcEhohf+Iw gMC7wkupE9DjINnltKjE0jxvgeklVnSPQ9N0i6YqqMgki0SLDA9jPFonX5FkzfbhY7kiEK C5wWFz0ISi8ehlzGkXXLGCRPQBGKjm4= Received: from mail-io1-f72.google.com (mail-io1-f72.google.com [209.85.166.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-32-orR4gkxEO4yrhT7xJFe3ow-1; Fri, 17 Mar 2023 18:41:04 -0400 X-MC-Unique: orR4gkxEO4yrhT7xJFe3ow-1 Received: by mail-io1-f72.google.com with SMTP id 85-20020a6b1458000000b007545a9d6706so1379156iou.18 for ; Fri, 17 Mar 2023 15:41:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679092863; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=DTqXt+xo9t4MKZl9inPofpb9h7U7JlyPPD0kMbn7WHE=; b=ANYFr6wbFSMsdA8c7gzM9wRQ79MG5LNIPqwekDSCk6s9ModInXYmVvc4x4yd3yWkQ4 KramCx98i2gWDuc0mSiio66L9WYRMjrttGSn0TW2KULrHP/VXVtFa6D8sGwQw5HFr4hk b9FaWo31EPneSu4K4mn/hvFwtpGx7PWo57j2vib5DDqIUp2K/M8lWynn15+q0VU0FR38 CsTFuIkHb+nIt5TsFAr0Jw14uGXOfEoB+G9BtCfaB/xll3iyyAQQOjvMUpuZLyJ8AcKZ NWhV5+BGEIa2Aq64L9lANdPI6qsrgjwCQZUfDHQaSm/3YaGpC647TiHWw6jFzrCncI4O o3wQ== X-Gm-Message-State: AO0yUKU14gEfKn25ZKbIHX3IW2HTnkILnFAT341xl1/dGZc43gIq9/p3 1Q8eTZurVvpXszZHg/FdwYe58qShA7aaM3rbI9tsyGjhPFQhxC5s6de/C/NXv/QYd1YGa2is1NX QVTqkpZRx36o= X-Received: by 2002:a92:c6ca:0:b0:317:951d:1696 with SMTP id v10-20020a92c6ca000000b00317951d1696mr85604ilm.3.1679092863439; Fri, 17 Mar 2023 15:41:03 -0700 (PDT) X-Google-Smtp-Source: AK7set87c1NIAKUmEpfr4tzQnIJXEdWv1u+znmZLZ35q/KPacnrvpXDdPzfrlB+0sZFBlBtfHyN/iw== X-Received: by 2002:a92:c6ca:0:b0:317:951d:1696 with SMTP id v10-20020a92c6ca000000b00317951d1696mr85571ilm.3.1679092863136; Fri, 17 Mar 2023 15:41:03 -0700 (PDT) Received: from redhat.com ([38.15.36.239]) by smtp.gmail.com with ESMTPSA id x10-20020a92300a000000b0030c0dce44b1sm930381ile.15.2023.03.17.15.41.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Mar 2023 15:41:01 -0700 (PDT) Date: Fri, 17 Mar 2023 16:40:59 -0600 From: Alex Williamson To: Suren Baghdasaryan 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?B?Q8OpZHJpYw==?= Le Goater , dimitri.sivanich@hpe.com Subject: Re: [PATCH v4 0/7] introduce vm_flags modifier functions Message-ID: <20230317164059.466d1c70.alex.williamson@redhat.com> In-Reply-To: References: <20230126193752.297968-1-surenb@google.com> <20230314141144.6a0892e6.alex.williamson@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 3CEF840014 X-Rspamd-Server: rspam01 X-Stat-Signature: aq8twoouzh3e9yno4aehoa9m9qtsfq5g X-HE-Tag: 1679092866-796121 X-HE-Meta: U2FsdGVkX1+lQTc+C5m76fUUU8VzNiZcoGrDeDQMTCyeTnCVkapIPxYTQqZcz/KYogPReexmhzexE2LBV/SPM818i3LJmU+VkMTH71Z/E5rgutC+KMTwrINphsDe8J4bTXJuJBIOvBn670h1nXbgdnObJkLf8MyE034TO9esjAZTzA2IzF3w4d/vEH+QtdV+LcKuK34kQf4egXV4uDOygHzQ7yvOcCiuVIAkV5cDEYhRji1SiaypTav40+CRsQcm9WR+NKNX4/UH3elUu+wfoAc407NMPEvwqHIzgY9cSTYC+EVwSKvpzfVw7nr/2Tz/xodyo0Bs7gytXezCjVddhBSHo4NzMDPu4cyxw3MrjyQsFyyHMUBUTa2+kTZWdBVBZjE+FDY6GjYaL9IjqyfSxL7x+vXlm8I5+xnZFibqpjEqkWNZj8ysLK3gt1PPQt8mQcLJvR/Rs0jMtatm5Du/antRHwYT0zN8QuKRlS1jTR9G+2YKEP65E+7fmBxQH++EjtC8L6WYV3uCFlOkDN9B70LSwhavsDQEAsivvmn1VLo1TIo7pQM6+xTUU27/R3k/NzD9sfMT4USzTwXAabFlltitzLKpsuWSW04/E4YBNagYhwr5nhAj7jl9HNFX8BihwdMldWSmthtIqaooocEhR70b99S4e5sOib3u2LGEwumk09TTmDFlNCKURr9MA7uqrgeA/lYYJLjhSSBBX21xfHEiELvCUwRf2b5uyvuXuTgEPaK0GhnAyBL5eVsmru+hkf8SQkdWjhYuKUc/+6vVobsWMInhx3HPts4/96HA95OZ8XK1CnUUO09c1bbI1FeaBD+k3cbd9lTT65jkKqhUeX9Is2j2rEzCyS3cyFdu0VVeXq37X2gmwIEJQ8S1QYevNTzz9KAom0g7H/c2l4uEFyJwZsSq6BlL8HNEvwRHeYxDIdFyGOnwUltXEVRGgxNN86ZzWPXyT4awZM64BCd /Xc5OFI1 L89E9uFq0wOxTH6aUNXRHNyiRXZpGWjHVx9hAzKqJV5oIwiQzWhxODvvj37jb+0nOxXAEwHYX05e1WUhIZlENSbeq9uoI6Uz/WU8lcoP8vuCSMV0CstoB9Ab2SwtZKSop1KA2JMcjZPcu4ii/bGGMxiyF/Plq3tVefajB+rmqu5uTV4iCslDq800nh8XSAxwPnuh2VnR7IYnGDiAtopL35r9ASN6vYscVKvC8OabbflayCD9M8+ok0ahZMMaadY+So+fQO/DtOL+86g789aNjIM8n6PEXCV2Vpi+UaBFs0md9s6Jj4IUB1wmZZbrhkeaFZV+x4gYq2F2n2aVda0R1qX/UHrxArcTWj3+xnN4ZkbETLGtEkWTyvtpBuNw+LwBIld7diLsh6lKv+HPBUaMFHjMrzKhr+H8IJ+VOSsctUJqfiIYYItF0ULff8beT/2Xkd/rBvsgLIuH+XVxVRcATl5KW6tDRk/dBGyP/HVlCW/dp5IgYW7gnFWraYTc/d5aGZIG+b+Uvi7IUUHRT396n/w5wg3rUT7zo2ELvqMbWFY/Gu+1j7MRxKYFG81FNJGWeNP5b X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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: > > =20 > > > 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 facilit= ate > > > 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 V= MA when > > > vm_flags are being updated. > > > > > > VMA vm_flags modifications are usually done under exclusive mmap_lock > > > protection because this attrubute affects other decisions like VMA me= rging > > > or splitting and races should be prevented. Introduce vm_flags modifi= er > > > functions to enforce correct locking. > > > > > > The patchset applies cleanly over mm-unstable branch of mm tree. =20 > > > > 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 disabled > > and we'd rather zap the mapping when that occurs so that we can sigbus > > 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 the > > mappings might be more inline with mm expectations relative to touching > > vm_flags during fault. What's the right solution here? Can the fault > > handling be salvaged, is proactive remapping the right approach, or is > > there something better? Thanks, =20 >=20 > 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, Alex