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@xxxxxxxxxx> 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.
