linux-kernel - Re: [PATCH] mremap: enforce rmap src/dst vma ordering in case of vma_merge succeeding in copy

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:	Mon, 7 Nov 2011 13:14:13 +0000
From:	Mel Gorman <mgorman@...e.de>
To:	Nai Xia <nai.xia@...il.com>
Cc:	Andrea Arcangeli <aarcange@...hat.com>,
	Hugh Dickins <hughd@...gle.com>, Pawel Sikora <pluto@...k.net>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	jpiszcz@...idpixels.com, arekm@...-linux.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mremap: enforce rmap src/dst vma ordering in case of
 vma_merge succeeding in copy_vma

On Sat, Nov 05, 2011 at 10:00:52AM +0800, Nai Xia wrote:
> > <SNIP>
> > The only safe way to do it is to have _two_ different vmas, with two
> > different ->vm_pgoff. Then it will work. And by always creating a new
> > vma we'll always have it queued at the end, and it'll be safe for the
> > same reasons fork is safe.
> >
> > Always allocate a new vma, and then after the whole vma copy is
> > complete, look if we can merge and free some vma. After the fact, so
> > it means we can't use vma_merge anymore. vma_merge assumes the
> > new_range is "virtual" and no vma is mapped there I think. Anyway
> > that's an implementation issue. In some unlikely case we'll allocate 1
> > more vma than before, and we'll free it once mremap is finished, but
> > that's small problem compared to solving this once and for all.
> >
> > And that will fix it without ordering games and it'll fix the *vmap=
> > new_vma case too. That case really tripped on me as I was assuming
> > *that* was correct.
> 
> Yes. "Allocating a new vma, copy first and merge later " seems
> another solution without the tricky reordering. But you know,
> I now share some of Hugh's feeling that maybe we are too
> desperate using racing in places where locks are simpler
> and guaranteed to be safe.
> 

I'm tending to agree. The number of cases that must be kept in mind
is getting too tricky. Taking the anon_vma lock may be slower but at
the risk of sounding chicken, it's easier to understand.

> But I think Mel indicated that anon_vma_locking might be
> harmful to JVM SMP performance.
> How severe you expect this to be, Mel ?
> 

I would only expect it to be a problem during garbage collection when
there is a greater likelihood that mremap is heavily used. While it
would have been nice to avoid additional overhead in mremap, I don't
think the JVM GC case on its own is sufficient justification to avoid
taking the anon_vma lock.

-- 
Mel Gorman
SUSE Labs
--
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/