On Tue, Aug 1, 2023 at 2:46 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote: > > 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. v2 posted at https://lore.kernel.org/all/20230801220733.1987762-1-surenb@xxxxxxxxxx/ > Thanks, > Suren. > > > > > Thanks, > > > > -- > > Peter Xu > >
