From: Jason Gunthorpe <jgg@nvidia•com>
To: Alex Williamson <alex.williamson@redhat•com>
Cc: michel@lespinasse•org, joelaf@google•com, songliubraving@fb•com,
mhocko@suse•com, leewalsh@google•com, david@redhat•com,
peterz@infradead•org, bigeasy@linutronix•de,
"Cédric Le Goater" <clg@redhat•com>,
peterx@redhat•com, dhowells@redhat•com, linux-mm@kvack•org,
edumazet@google•com, jglisse@google•com,
punit.agrawal@bytedance•com, will@kernel•org,
arjunroy@google•com, dave@stgolabs•net, minchan@google•com,
x86@kernel•org, hughd@google•com, willy@infradead•org,
gurua@google•com, mingo@redhat•com,
linux-arm-kernel@lists•infradead.org, rientjes@google•com,
axelrasmussen@google•com, kernel-team@android•com,
"Jason Wang" <jasowang@redhat•com>,
soheil@google•com, paulmck@kernel•org, jannh@google•com,
liam.howlett@oracle•com, shakeelb@google•com, luto@kernel•org,
gthelen@google•com, ldufour@linux•ibm.com,
"Suren Baghdasaryan" <surenb@google•com>,
vbabka@suse•cz, dimitri.sivanich@hpe•com, posk@google•com,
lstoakes@gmail•com, peterjung1337@gmail•com,
linuxppc-dev@lists•ozlabs.o
Subject: Re: [PATCH v4 0/7] introduce vm_flags modifier functions
Date: Wed, 22 Mar 2023 10:48:00 -0300 [thread overview]
Message-ID: <ZBsHENhAFsBYN4HI@nvidia.com> (raw)
In-Reply-To: <20230314141144.6a0892e6.alex.williamson@redhat.com>
On Tue, Mar 14, 2023 at 02:11:44PM -0600, Alex Williamson wrote:
> On Thu, 26 Jan 2023 11:37:45 -0800
> Suren Baghdasaryan <surenb@google•com> 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.
Yeah, IMHO this whole approach has always been a bit sketchy, it was
never intended that remap_pfn would be called from a fault handler,
you are supposed to use a vmf_insert_pfn() type API from fault
handlers.
> 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.
Yes, I feel the same - along with completing the address_space
conversion you had started. IIRC that was part of the reason we needed
this design in vfio.
Jason
prev parent reply other threads:[~2023-03-22 13:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-26 19:37 [PATCH v4 0/7] introduce vm_flags modifier functions Suren Baghdasaryan
2023-01-26 19:37 ` [PATCH v4 1/7] kernel/fork: convert vma assignment to a memcpy Suren Baghdasaryan
2023-01-26 19:40 ` Mike Rapoport
2023-01-26 19:37 ` [PATCH v4 2/7] mm: introduce vma->vm_flags wrapper functions Suren Baghdasaryan
2023-01-26 19:42 ` Mike Rapoport
2023-02-08 1:48 ` Hyeonggon Yoo
2023-01-26 19:37 ` [PATCH v4 3/7] mm: replace VM_LOCKED_CLEAR_MASK with VM_LOCKED_MASK Suren Baghdasaryan
2023-01-27 17:45 ` Davidlohr Bueso
2023-01-27 20:56 ` Suren Baghdasaryan
2023-01-26 19:37 ` [PATCH v4 4/7] mm: replace vma->vm_flags direct modifications with modifier calls Suren Baghdasaryan
2023-01-27 14:23 ` Liam R. Howlett
2023-01-31 8:32 ` Hyeonggon Yoo
2023-01-31 18:54 ` Suren Baghdasaryan
2023-01-31 20:53 ` Andrew Morton
2023-01-31 21:08 ` Suren Baghdasaryan
2023-01-31 23:12 ` Andrew Morton
2023-02-01 0:03 ` Suren Baghdasaryan
2023-02-01 12:23 ` Hyeonggon Yoo
2023-01-26 19:37 ` [PATCH v4 5/7] mm: replace vma->vm_flags indirect modification in ksm_madvise Suren Baghdasaryan
2023-01-26 22:45 ` Michael Ellerman
2023-02-08 1:54 ` Hyeonggon Yoo
2023-01-26 19:37 ` [PATCH v4 6/7] mm: introduce __vm_flags_mod and use it in untrack_pfn Suren Baghdasaryan
2023-01-26 19:44 ` Mike Rapoport
2023-01-26 19:37 ` [PATCH v4 7/7] mm: export dump_mm() Suren Baghdasaryan
2023-03-14 20:11 ` [PATCH v4 0/7] introduce vm_flags modifier functions Alex Williamson
2023-03-17 19:08 ` Suren Baghdasaryan
2023-03-17 22:40 ` Alex Williamson
2023-03-17 23:04 ` Suren Baghdasaryan
2023-03-22 13:48 ` Jason Gunthorpe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZBsHENhAFsBYN4HI@nvidia.com \
--to=jgg@nvidia$(echo .)com \
--cc=alex.williamson@redhat$(echo .)com \
--cc=arjunroy@google$(echo .)com \
--cc=axelrasmussen@google$(echo .)com \
--cc=bigeasy@linutronix$(echo .)de \
--cc=clg@redhat$(echo .)com \
--cc=dave@stgolabs$(echo .)net \
--cc=david@redhat$(echo .)com \
--cc=dhowells@redhat$(echo .)com \
--cc=dimitri.sivanich@hpe$(echo .)com \
--cc=edumazet@google$(echo .)com \
--cc=gthelen@google$(echo .)com \
--cc=gurua@google$(echo .)com \
--cc=hughd@google$(echo .)com \
--cc=jannh@google$(echo .)com \
--cc=jasowang@redhat$(echo .)com \
--cc=jglisse@google$(echo .)com \
--cc=joelaf@google$(echo .)com \
--cc=kernel-team@android$(echo .)com \
--cc=ldufour@linux$(echo .)ibm.com \
--cc=leewalsh@google$(echo .)com \
--cc=liam.howlett@oracle$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-mm@kvack$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.o \
--cc=lstoakes@gmail$(echo .)com \
--cc=luto@kernel$(echo .)org \
--cc=mhocko@suse$(echo .)com \
--cc=michel@lespinasse$(echo .)org \
--cc=minchan@google$(echo .)com \
--cc=mingo@redhat$(echo .)com \
--cc=paulmck@kernel$(echo .)org \
--cc=peterjung1337@gmail$(echo .)com \
--cc=peterx@redhat$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=posk@google$(echo .)com \
--cc=punit.agrawal@bytedance$(echo .)com \
--cc=rientjes@google$(echo .)com \
--cc=shakeelb@google$(echo .)com \
--cc=soheil@google$(echo .)com \
--cc=songliubraving@fb$(echo .)com \
--cc=surenb@google$(echo .)com \
--cc=vbabka@suse$(echo .)cz \
--cc=will@kernel$(echo .)org \
--cc=willy@infradead$(echo .)org \
--cc=x86@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox