Messages in this thread | | | Date | Mon, 12 Feb 2024 10:14:30 +0200 | From | Mike Rapoport <> | Subject | Re: [PATCH v2 2/3] userfaultfd: protect mmap_changing with rw_sem in userfaulfd_ctx |
| |
On Wed, Feb 07, 2024 at 12:24:52PM -0800, Lokesh Gidra wrote: > On Wed, Feb 7, 2024 at 7:27 AM Mike Rapoport <rppt@kernel.org> wrote: > > > > > > The write-lock is not a requirement here for correctness and I don't see > > > > why we would need userfaultfd_remove_prep(). > > > > > > > > As I've said earlier, having a write-lock here will let CRIU to run > > > > background copy in parallel with processing of uffd events, but I don't > > > > feel strongly about doing it. > > > > > > > Got it. Anyways, such a change needn't be part of this patch, so I'm > > > going to keep it unchanged. > > > > You mean with a read lock? > > No, I think write lock is good as it enables parallel background copy. > Also because it brings consistency in blocking userfaultfd operations. > > I meant encapsulating remove operations within > userfaultfd_remove_prep() and userfaultfd_remove_complete(). I > couldn't figure out any need for that.
I don't think there is a need for that. With fork/mremap prep is required to ensure there's uffd context for new vmas.
-- Sincerely yours, Mike.
| |