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  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:	Tue, 7 Oct 2014 09:13:20 -0700
From:	Peter Feiner <>
To:	Andrea Arcangeli <>
Cc:	Linus Torvalds <>,
	"Dr. David Alan Gilbert" <>,, KVM list <>,
	Linux Kernel Mailing List <>,
	linux-mm <>,
	Linux API <>,
	Andres Lagar-Cavilla <>,
	Dave Hansen <>,
	Paolo Bonzini <>,
	Rik van Riel <>, Mel Gorman <>,
	Andy Lutomirski <>,
	Andrew Morton <>,
	Sasha Levin <>,
	Hugh Dickins <>,
	Christopher Covington <>,
	Johannes Weiner <>,
	Android Kernel Team <>,
	Robert Love <>,
	Dmitry Adamushko <>,
	Neil Brown <>, Mike Hommey <>,
	Taras Glek <>, Jan Kara <>,
	KOSAKI Motohiro <>,
	Michel Lespinasse <>,
	Minchan Kim <>,
	Keith Packard <>,
	"Huangpeng (Peter)" <>,
	Isaku Yamahata <>,
	Anthony Liguori <>,
	Stefan Hajnoczi <>,
	Wenchao Xia <>,
	Andrew Jones <>,
	Juan Quintela <>
Subject: Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

On Tue, Oct 07, 2014 at 05:52:47PM +0200, Andrea Arcangeli wrote:
> I probably grossly overestimated the benefits of resolving the
> userfault with a zerocopy page move, sorry. [...]

For posterity, I think it's worth noting that most expensive aspect of a TLB
shootdown is the interprocessor interrupt necessary to flush other CPUs' TLBs.
On a many-core machine, copying 4K of data looks pretty cheap compared to
taking an interrupt and invalidating TLBs on many cores :-)

> [...] So if we entirely drop the
> zerocopy behavior and the TLB flush of the old page like you
> suggested, the way to keep the userfaultfd mechanism decoupled from
> the userfault resolution mechanism would be to implement an
> atomic-copy syscall. That would work for SIGBUS userfaults too without
> requiring a pseudofd then. It would be enough then to call
> mcopy_atomic(userfault_addr,tmp_addr,len) with the only constraints
> that len must be a multiple of PAGE_SIZE. Of course mcopy_atomic
> wouldn't page fault or call GUP into the destination address (it can't
> otherwise the in-flight partial copy would be visible to the process,
> breaking the atomicity of the copy), but it would fill in the
> pte/trans_huge_pmd with the same strict behavior that remap_anon_pages
> currently has (in turn it would by design bypass the VM_USERFAULT
> check and be ideal for resolving userfaults).
> mcopy_atomic could then be also extended to tmpfs and it would work
> without requiring the source page to be a tmpfs page too without
> having to convert page types on the fly.
> If I add mcopy_atomic, the patch in subject (10/17) can be dropped of
> course so it'd be even less intrusive than the current
> remap_anon_pages and it would require zero TLB flush during its
> runtime (it would just require an atomic copy).

I like this new approach. It will be good to have a single interface for
resolving anon and tmpfs userfaults.

> So should I try to embed a mcopy_atomic inside userfault_write or can
> I expose it to userland as a standalone new syscall? Or should I do
> something different? Comments?

One interesting (ab)use of userfault_write would be that the faulting process
and the fault-handling process could be different, which would be necessary
for post-copy live migration in CRIU (

Aside from the asthetic difference, I can't think of any advantage in favor of
a syscall.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists