Re: Multiple potential races on vma->vm_flags
From: Davidlohr Bueso
Date: Wed Sep 23 2015 - 18:59:14 EST
On Wed, 23 Sep 2015, Kirill A. Shutemov wrote:
On Tue, Sep 22, 2015 at 06:39:52PM -0700, Hugh Dickins wrote:
[...]
I'd rather wait to hear whether this appears to work in practice,
and whether you agree that it should work in theory, before writing
the proper description. I'd love to lose that down_read_trylock.
You mention how Sasha hit the "Bad page state (mlocked)" back in
November: that was one of the reasons we reverted Davidlohr's
i_mmap_lock_read to i_mmap_lock_write in unmap_mapping_range(),
without understanding why it was needed. Yes, it would lock out
a concurrent try_to_unmap(), whose setting of PageMlocked was not
sufficiently serialized by the down_read_trylock of mmap_sem.
But I don't remember the other reasons for that revert (and
haven't looked very hard as yet): anyone else remember?
Yeah, I don't think this was ever resolved, but ultimately the patch
got reverted[1] because it exposed issues in the form of bad pages
(shmem, vmsplice) and corrupted vm_flags while in untrack_pfn() causing,
for example, vm_file to dissapear.
I hoped Davidlohr will come back with something after the revert, but it
never happend. I think the reverted patch was responsible for most of
scalability boost from rwsem for i_mmap_lock...
Actually no, the change that got reverted was something we got in very
last minute, just because it made sense and had the blessing of some
key people. The main winner of the series was migration (rmap), which
later Hugh addressed more specifically for unmapped pages:
https://lkml.org/lkml/2014/11/30/349
So I really didn't care about the reverted patch, and therefore was never
on my radar.
[1] https://lkml.org/lkml/2014/12/22/375
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/