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 288D8C05027 for ; Tue, 14 Mar 2023 20:11:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86DC76B0072; Tue, 14 Mar 2023 16:11:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84E976B0074; Tue, 14 Mar 2023 16:11:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70C328E0001; Tue, 14 Mar 2023 16:11:53 -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 61C1A6B0072 for ; Tue, 14 Mar 2023 16:11:53 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 057A31C644E for ; Tue, 14 Mar 2023 20:11:53 +0000 (UTC) X-FDA: 80568599706.13.201A5FF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 8F9D440003 for ; Tue, 14 Mar 2023 20:11:50 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=E56unI+1; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of alex.williamson@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=alex.williamson@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678824710; 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=9wQYTp3YB8E8Qol6aRWb0q0ebKdxfSZQ88xnQL/Q0do=; b=gTIZTo0UrnTb2DlhudU3XDSFK6InZDwyn5gF8Q7Bw1chQzwiD6v9xxWhEUIEapHocxDQGC yFl/s+mbc7gkT2tOmqu/FGDX1EsyvXCBAdoGh5VosCOBen9ZSYn+seHjWPrylPF9YzFfQx fr2uFcbB/Lp3dOgCRCE26caDCghiqdw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=E56unI+1; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of alex.williamson@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=alex.williamson@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678824710; a=rsa-sha256; cv=none; b=Zs6iLU/DNPxAlJHLHh7PoFN20u4H6PFkdkGXtDfg7DNjSAz/fftlr1FZ9SJqhpM7tBYlgG GiXNkMI3ifPJBvJVOmCZoiGWtZQUbKPjuZFa6TIHnxuchfHA/xaTXRi3CKNRmCVvRNOhUd B9swWhedUWk8GS24mCl4eoeTp1dB8Ug= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678824709; 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=9wQYTp3YB8E8Qol6aRWb0q0ebKdxfSZQ88xnQL/Q0do=; b=E56unI+1cbX4ZmMXasSE/pWApmlgcMNuvDzarLWSvHTp21SklUPzfpCjbptpE4B5jVITYn OC05C2FRoLGVn7L3rIrnutZlr8K9vOBVVPgMha3gVAa4O/UW/OUHfoQTWkYSfgrCSHECk4 M0CGc93AKvminC3q5KutwCn9//Xu+jI= Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-558-iNWKizmJPDCr1mdrbo-nJw-1; Tue, 14 Mar 2023 16:11:49 -0400 X-MC-Unique: iNWKizmJPDCr1mdrbo-nJw-1 Received: by mail-il1-f197.google.com with SMTP id c9-20020a929409000000b0032307610dfaso3854416ili.5 for ; Tue, 14 Mar 2023 13:11:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678824708; h=content-transfer-encoding:mime-version: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=9wQYTp3YB8E8Qol6aRWb0q0ebKdxfSZQ88xnQL/Q0do=; b=psRJyx1XnHggkf5DFI3yYmdE+/ESiG683Aj1s5OAOwMK+nQSGo+09+0z4Itt/zbTzx Orclg010pCH++6mG48T36c8To5Az0Luswv0uy0YmTC0Jn1S63nGhBNfTDDonvb7snepE cLCBCVhiB+UYGo+d81We1SaUa9QMIfVW9p6eJQZ1GmNQqbDui/2fIkT0KZiGTnTZPLRT 9Ja2W4KGDFH9CZe5pgdP1+KJ3jH0YJba+9hnXsgknHVUGc/ZJLawgreodZV/hPbZOx2B VJJW5/OgSJsLORCU46DBKknJyAdpKL7IQ4TpN+hbFUszjK0OU2zQR4OAoe6cPjEgj6sq Ys2g== X-Gm-Message-State: AO0yUKW8uamZ0LU4bwKlUlJdgFU7hYpeP1LNBvYxFuThnQN2URrwHT0n Q67KTqiln0aoM0u0B+b0PyGfAOdIk12xKzTbGN2XTsk4ttrh5FEC1qWdbLzjNzJoqv+s68ueHUs arNKHMt+FSLQ= X-Received: by 2002:a05:6e02:1aa6:b0:317:83ad:a2a2 with SMTP id l6-20020a056e021aa600b0031783ada2a2mr2902961ilv.10.1678824707665; Tue, 14 Mar 2023 13:11:47 -0700 (PDT) X-Google-Smtp-Source: AK7set+WFDrvIixXmlqMGu/bCY3ZmjaTxWtCpgpTEGZODyspTTPhzeQHSA5z9/Or1gn7wARcWXseMA== X-Received: by 2002:a05:6e02:1aa6:b0:317:83ad:a2a2 with SMTP id l6-20020a056e021aa600b0031783ada2a2mr2902903ilv.10.1678824707351; Tue, 14 Mar 2023 13:11:47 -0700 (PDT) Received: from redhat.com ([38.15.36.239]) by smtp.gmail.com with ESMTPSA id q1-20020a056e02096100b00314201bcbdfsm1079964ilt.3.2023.03.14.13.11.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Mar 2023 13:11:46 -0700 (PDT) Date: Tue, 14 Mar 2023 14:11:44 -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: <20230314141144.6a0892e6.alex.williamson@redhat.com> In-Reply-To: <20230126193752.297968-1-surenb@google.com> References: <20230126193752.297968-1-surenb@google.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.35; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8F9D440003 X-Stat-Signature: 5hpygm7ucmfyaqa9cw9gwjow9yydxgem X-HE-Tag: 1678824710-662296 X-HE-Meta: U2FsdGVkX19DMSFZ9mgfRvKpEGZ79cjyD1aWdVe5QsmVabVuGlRnqtyJaxPDiIIXaeS6cI3ezonpNhff2q6Hv4h/WxBLC+TIKWKdcQjIpbhosvb2z7JHsUq1FoVM/llFAVCD52l0ydSLWXuOLYbIvyqHFhjoorPWlqQca51U0jPgS1EndMZDn1de05JVNMdKo56NXM/8M4450mFuZo6yqaBLvcMEN6cEmcqN+qZaUdC+CtASRSU2YPZAktbjDSaTTVXOJkDA425aqD5ZzxOyWno3LEYm04uf0gRmT8hi4BDYxTXWfhkS92WAJ+eiXyNV1MJPz6e+WVXTZH+fCE1x3Q2bOjK2lIIGpLY/N7F8DJ8ECtcRfcf07JrrU0GkM9MuhRi/B3d/gVdYEvW/shzSC/IxDCMYsoTBUovGZrsIy6SbESHt3cruElTqzK7gdq0qoiH+JKTvVpKyIoxHAW5k0eUxzUQEDK9Ezg20XFOXHA0MJOgpbovFSEivbYcirkF8czE6gQMrdinXJ4kILfD1V+IclbU/jHarPnAYm3Xtd6JwDGDJ8/6Qopn/9+qK5Z59Yd7Md7Jv5oWWmcuzCVRpNMvAzplF27CBOYckCMM1LKLSLXiaIOEh/6oG2ciRltj+VGlKtlGj6OGPtVfRh2JDkGvtWgo+02IACwsPrUGdTp0+mNxywVIHhmXQnUstjSPiz8YjQOOdpJ/IZjIYA4gB9IzqdoKkelQ7D4hQCf1j771EeolcY7jrmHajYLfSwiPjuVl7EKPm7ppqFnjrYbcuPsL6u2QPKizv2A8RcP1kIUW1w3KkdTVCPp601fDDmRbTk9NVOtlgTsOrnKdE3MEZZblmFfEI0bxqVqjkFN1tYu2YNQbOAXLKMgeHaf1ENsMcRaHxJZX7spAfmKoz7FIxE5vSg0zIvxis8zD4LAhE0MEprRPOJYe82GB0N3S/NYu2jEb8Ar8qVseACnPljLz Y0vd5EJp w3vPwCq1qbvU81+WF+eR3xODDnmdYIRCkfDvM8q7WlCcvMAJF7Cnt4rV+q9iLwcddJpn2vJheQiJoh8WawW2GpM4FSS/RjFWSJUE1NEYsPBKRcb9/ozR+TEw/OrQrWfp++OC0pTzCh6LBIuxCQ7Y+Au8Cu9BHmN+IL1K1+X7dSHNVacNfKq1S1DTJYcOw+3gxEUxyeIZCjjtwG0bSKweI3bLffO84xhik+jSaTLmIZUfD5Xq2zygxge1/CzRi0y2elFDnZPUva1hAiKdUoje5qRF3rE5fGyusTGoW0gqasyVomN8eoFqJbjQFku3q27HjOk45KfLIbAMTN9CcIMu8mBJaNITBRI70WbPEAMQv1SkWBRGvdxTpk32AN0KcZWkVR5JPqCsHE1a3nxRBESoUaptpOw3sDg8jwOQ2q6swy9bsCQEvJiHfJrm02/R4fhDn352AkWFygY4z5sY= 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 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 facilitate > 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_lock > protection because this attrubute affects other decisions like VMA merging > or splitting and races should be prevented. Introduce vm_flags modifier > 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 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, Alex