Doug / smarc-fsl-linux-kernel

20 Mar, 2012

1 commit

09 Jun, 2010

1 commit

  • 9a40ac861   ARM: 6164/1: Add kto and kfrom to input operands list. ... Browse Code »

    When functions incoming parameters are not in input operands list gcc
    4.5 does not load the parameters into registers before calling this
    function but the inline assembly assumes valid addresses inside this
    function. This breaks the code because r0 and r1 are invalid when
    execution enters v4wb_copy_user_page ()

    Also the constant needs to be used as third input operand so account
    for that as well.

    Tested on qemu arm.

    CC:
    Signed-off-by: Khem Raj
    Signed-off-by: Russell King

    Khem Raj
     

05 Oct, 2009

2 commits

  • 2725898fc   ARM: Flush user mapping on VIVT processors when copying a page ... Browse Code »

    Steven Walter 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:
    Signed-off-by: Russell King

    Russell King
     
  • f00a75c09   ARM: Pass VMA to copy_user_highpage() implementations ... Browse Code »

    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

    Russell King
     

13 Mar, 2009

1 commit

  • 446c92b29   [ARM] 5421/1: ftrace: fix crash due to tracing of __naked functions ... Browse Code »

    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
    Tested-by: Matthias Kaehlcke

    Cc: Abhishek Sagar
    Cc: Steven Rostedt
    Cc: Ingo Molnar
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Russell King

    Uwe Kleine-König
     

28 Nov, 2008

4 commits