linux-kernel - Re: [PATCH 08/10] mm/mremap: share the i_mmap

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]

Message-ID: <20141104122901.GA28274@node.dhcp.inet.fi>
Date:	Tue, 4 Nov 2014 14:29:01 +0200
From:	"Kirill A. Shutemov" <kirill@...temov.name>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Davidlohr Bueso <dave@...olabs.net>,
	"Kirill A. Shutemov" <kirill.shutemov@...el.linux.com>,
	Michel Lespinasse <walken@...gle.com>,
	akpm@...ux-foundation.org, riel@...hat.com, mgorman@...e.de,
	peterz@...radead.org, mingo@...nel.org,
	linux-kernel@...r.kernel.org, dbueso@...e.de, linux-mm@...ck.org
Subject: Re: [PATCH 08/10] mm/mremap: share the i_mmap_rwsem

On Mon, Nov 03, 2014 at 10:04:24PM -0800, Hugh Dickins wrote:
> I'm glad to see this series back, and nicely presented: thank you.
> Not worth respinning them, but consider 1,2,3,4,5,6,7 and 9 as
> Acked-by: Hugh Dickins <hughd@...gle.com>
> 
> On Thu, 30 Oct 2014, Davidlohr Bueso wrote:
> 
> > As per the comment in move_ptes(), we only require taking the
> > anon vma and i_mmap locks to ensure that rmap will always observe
> > either the old or new ptes, in the case of need_rmap_lock=true.
> > No modifications to the tree itself, thus share the i_mmap_rwsem.
> > 
> > Signed-off-by: Davidlohr Bueso <dbueso@...e.de>
> > Acked-by: Kirill A. Shutemov <kirill.shutemov@...el.linux.com>
> 
> But this one is Nacked by me.  I don't understand how you and Kirill
> could read Michel's painstaking comment on need_rmap_locks, then go
> go ahead and remove the exclusion of rmap_walk().
> 
> I agree the code here does not modify the interval tree, but the
> comment explains how we're moving a pte from one place in the tree
> to another, and in some cases there's a danger that the rmap walk
> might miss the pte from both places (which doesn't matter much to
> most of its uses, but is critical in page migration).
> 
> Or am I the one missing something?

You're completely right.

I've seen the comment (and I've added the missed need_rmap_locks case for
move_huge_pmd() before). What happened is I've over-extrapolated my
experience of rmap walk in case of split_huge_page(), which takes exclusive
anon_vma lock, to the rest of rmap use-cases. This of course was hugely
wrong.

I'm ashamed and feel really bad about the situation. Sorry.

-- 
 Kirill A. Shutemov
--
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/