linux-kernel - Re: Multiple potential races on vma->vm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Sep 2015 15:58:52 -0700
From:	Davidlohr Bueso <dave@...olabs.net>
To:	"Kirill A. Shutemov" <kirill@...temov.name>
Cc:	Hugh Dickins <hughd@...gle.com>,
	Andrey Konovalov <andreyknvl@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dmitry Vyukov <dvyukov@...gle.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: Multiple potential races on vma->vm_flags

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/