Re: [PATCH v3 04/20] mm: VMA sequence count
From: Sergey Senozhatsky <hidden>
Date: 2017-09-14 08:14:04
Also in:
linux-mm, lkml
From: Sergey Senozhatsky <hidden>
Date: 2017-09-14 08:14:04
Also in:
linux-mm, lkml
Hi, On (09/14/17 09:55), Laurent Dufour wrote: [..]
quoted
so if there are two CPUs, one doing write_seqcount() and the other one doing read_seqcount() then what can happen is something like this CPU0 CPU1 fs_reclaim_acquire() write_seqcount_begin() fs_reclaim_acquire() read_seqcount_begin() write_seqcount_end() CPU0 can't write_seqcount_end() because of fs_reclaim_acquire() from CPU1, CPU1 can't read_seqcount_begin() because CPU0 did write_seqcount_begin() and now waits for fs_reclaim_acquire(). makes sense?Yes, this makes sense. But in the case of this series, there is no call to __read_seqcount_begin(), and the reader (the speculative page fault handler), is just checking for (vm_seq & 1) and if this is true, simply exit the speculative path without waiting. So there is no deadlock possibility.
probably lockdep just knows that those locks interleave at some
point.
by the way, I think there is one path that can spin
find_vma_srcu()
read_seqbegin()
read_seqcount_begin()
raw_read_seqcount_begin()
__read_seqcount_begin()
-ss