On Tue, Aug 1, 2023 at 2:34 PM Peter Xu <peterx@xxxxxxxxxx> wrote: > > On Tue, Aug 01, 2023 at 01:28:56PM -0700, Suren Baghdasaryan wrote: > > I have the new patchset ready but I see 3 places where we walk the > > pages after mmap_write_lock() while *I think* we can tolerate > > concurrent page faults (don't need to lock the vmas): > > > > s390_enable_sie() > > break_ksm() > > clear_refs_write() > > This one doesn't look right to be listed - tlb flushing is postponed after > pgtable lock released, so I assume the same issue can happen like fork(): > where we can have race coditions to corrupt data if, e.g., thread A > writting with a writable (unflushed) tlb, alongside with thread B CoWing. Ah, good point. > > It'll indeed be nice to know whether break_ksm() can avoid that lock_vma > parameter across quite a few function jumps. I don't yet see an immediate > issue with this one.. No idea on s390_enable_sie(), but to make it simple > and safe I'd simply leave it with the write vma lock to match the mmap > write lock. Thanks for taking a look, Peter! Ok, let me keep all three of them with vma locking in place to be safe and will post v2 for further discussion. Thanks, Suren. > > Thanks, > > -- > Peter Xu >
