Re: [Lsf10-pc] Current MM topics for LSF10/MM Summit 8-9 August in Boston

[Gleb Natapov <gleb@redhat.com>]

CCing Avi,

On Mon, Jun 21, 2010 at 04:09:39PM +0200, Andrea Arcangeli wrote:
> On Mon, Jun 21, 2010 at 04:22:38PM +0300, Gleb Natapov wrote:
> > On Mon, Jun 21, 2010 at 03:16:08PM +0200, Andrea Arcangeli wrote:
> > > > KOSAKI Motohiro		get_user_pages vs COW problem
> > > 
> > > Just a side note, not sure exactly what is meant to be discussed about
> > > this bug, considering the fact this is still unsolved isn't technical
> > > problem as there were plenty of fixes available, and the one that seem
> > > to had better chance to get included was the worst one in my view, as
> > > it tried to fix it in a couple of gup caller (but failed, also because
> > > finding all put_page pin release is kind of a pain as they're spread
> > > all over the place and not identified as gup_put_page, and in addition
> > > to the instability and lack of completeness of the fix, it was also
> > > the most inefficient as it added unnecessary and coarse locking) plus
> > > all gup callers are affected, not just a few. I normally call it gup
> > > vs fork race. Luckily not all threaded apps uses O_DIRECT and fork and
> > > pretend to do the direct-io in different sub-page chunks of the same
> > > page from different threads (KVM would probably be affected if it
> > > didn't use MADV_DONTFORK on the O_DIRECT memory, as it might run fork
> > > to execute some network script when adding an hotplug pci net device
> > > for example). But surely we can discuss the fix we prefer for this
> > > bug, or at least we can agree it needs fixing.
> > > 
> > KVM is actually affected by the bug. The fix was posted today:
> > http://www.mail-archive.com/kvm@vger.kernel.org/msg36759.html
> 
> Interesting... so this is the page returned by gup that doesn't match
> anymore the page after an user write into qemu context after
> fork. Clearly any of the fixes proposed would have prevented this bug
> in the first place as they would assign a copy to the child, so yes
> it's likely this same bug. It's quite sad to have this workload that
> is superfluous if gup would behave as supposed by the caller. Also I'd
> prefer if you would use MADV_DONTFORK for the fix, as that will at
> least optimize fork and it would still be ok to keep even after we fix
> the VM while this workaround of using tmpfs should be backed out.
Avi did the fix. We discussed using MADV_DONTFORK for that, but calling
madvise() from kernel deemed to be messy.

--
			Gleb.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>