Commit Graph

7 Commits

Author SHA1 Message Date
Russell King 2725898fc9 ARM: Flush user mapping on VIVT processors when copying a page
Steven Walter <stevenrwalter@gmail.com> writes:
> I've been tracking down an instance of userspace data corruption,
> and I believe I have found a window during fork where data can be
> lost.  The corruption is occurring on an ARMv5 system with VIVT
> caches.  Here's the scenario in question.  Thread A is forking,
> Thread B is running in userspace:
>
> Thread A: flush_cache_mm() (dup_mmap)
> Thread B: writes to a page in the above mm
> Thread A: pte_wrprotect() the above page (copy_one_pte)
> Thread B: writes to the same page again
>
> During thread B's second write, he'll take a fault and enter the
> do_wp_page() case.  We'll end up calling copy_page(), which notably
> uses the kernel virtual addresses for the old and new pages.  This
> means that the new page does not necessarily have the data from the
> first write.  Now there are two conflicting copies of the same
> cache-line in dcache.  If the userspace cache-line flushes before
> the kernel cache-line, we lose the changes made during the first
> write.  do_wp_page does call flush_dcache_page on the newly-copied
> page, but there's still a window where the CPU could flush the
> userspace cache-line before then.

Resolve this by flushing the user mapping before copying the page
on processors with a writeback VIVT cache.

Note: this does have a performance impact, and so needs further
consideration before being merged - can we optimize out some of
the cache flushes if, eg, we know that the page isn't yet mapped?

Thread: <e06498070903061426o5875ad13hc6328aa0d3f08ed7@mail.gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-10-05 15:42:16 +01:00
Russell King f00a75c094 ARM: Pass VMA to copy_user_highpage() implementations
Our copy_user_highpage() implementations may require cache maintainence.
Ensure that implementations have all necessary details to perform this
maintainence.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-10-05 15:17:45 +01:00
Uwe Kleine-König 446c92b290 [ARM] 5421/1: ftrace: fix crash due to tracing of __naked functions
This is a fix for the following crash observed in 2.6.29-rc3:
http://lkml.org/lkml/2009/1/29/150

On ARM it doesn't make sense to trace a naked function because then
mcount is called without stack and frame pointer being set up and there
is no chance to restore the lr register to the value before mcount was
called.

Reported-by: Matthias Kaehlcke <matthias@kaehlcke.net>
Tested-by: Matthias Kaehlcke <matthias@kaehlcke.net>

Cc: Abhishek Sagar <sagar.abhishek@gmail.com>
Cc: Steven Rostedt <rostedt@home.goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-03-12 21:33:03 +00:00
Nicolas Pitre 43ae286b7d [ARM] fix a couple clear_user_highpage assembly constraints
In all cases the kaddr is assigned an input register even though it is
modified in the assembly code.  Let's assign a new variable to the
modified value and mark those inline asm with volatile otherwise they
get optimized away because the output variable is otherwise not used.

Also fix a few conversion errors in copypage-feroceon.c and
copypage-v4mc.c.

Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-28 15:36:43 +00:00
Russell King 303c644365 [ARM] clearpage: provide our own clear_user_highpage()
For similar reasons as copy_user_page(), we want to avoid the
additional kmap_atomic if it's unnecessary.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-27 23:53:48 +00:00
Russell King 063b0a4207 [ARM] copypage: provide our own copy_user_highpage()
We used to override the copy_user_page() function.  However, this
is not only inefficient, it also causes additional complexity for
highmem support, since we convert from a struct page to a kernel
direct mapped address and back to a struct page again.

Moreover, with highmem support, we end up pointlessly setting up
kmap entries for pages which we're going to remap.  So, push the
kmapping down into the copypage implementation files where it's
required.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-27 23:53:47 +00:00
Russell King d73e60b714 [ARM] copypage: convert assembly files to C
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-27 23:53:46 +00:00