Skip to content

L
linux
Switch branch/tag
  1. 04 Nov, 2006 4 commits
    • Suresh Siddha's avatar
      [PATCH] mm: fix a race condition under SMC + COW · f7bc3d8e
      Suresh Siddha authored 
      Failing context is a multi threaded process context and the failing
sequence is as follows.

One thread T0 doing self modifying code on page X on processor P0 and
another thread T1 doing COW (breaking the COW setup as part of just
happened fork() in another thread T2) on the same page X on processor P1.
T0 doing SMC can endup modifying the new page Y (allocated by the T1 doing
COW on P1) but because of different I/D TLB's, P0 ITLB will not see the new
mapping till the flush TLB IPI from P1 is received.  During this interval,
if T0 executes the code created by SMC it can result in an app error (as
ITLB still points to old page X and endup executing the content in page X
rather than using the content in page Y).

Fix this issue by first clearing the PTE and flushing it, before updating
it with new entry.

Hugh sayeth:

  I was a bit sceptical, in the habit of thinking that Self Modifying Code
  must look such issues itself: but I guess there's nothing it can do to avoid
  this one.

  Fair enough, what you're changing it to is pretty much what powerpc and
  s390 were already doing, and is a more robust way of proceeding, consistent
  with how ptes are set everywhere else.

  The ptep_clear_flush is a bit heavy-handed (it's anxious to return the pte
  that was atomically cleared), but we'd have to wander through lots of arches
  to get the right minimal behaviour.  It'd also be nice to eliminate
  ptep_establish completely, now only used to define other macros/inlines: it
  always seemed obfuscation to me, what you've got there now is clearer.
  Let's put those cleanups on a TODO list.
Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
Acked-by: default avatar"David S. Miller" <davem@davemloft.net>
Acked-by: default avatarHugh Dickins <hugh@veritas.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      f7bc3d8e
    • Martin Schwidefsky's avatar
      [PATCH] __div64_32 for 31 bit. · 3bc587b9
      Martin Schwidefsky authored 
      The clocksource infrastructure introduced with commit
ad596171 broke 31 bit s390.
The reason is that the do_div() primitive for 31 bit always
had a restriction: it could only divide an unsigned 64 bit
integer by an unsigned 31 bit integer. The clocksource code
now uses do_div() with a base value that has the most
significant bit set. The result is that clock->cycle_interval
has a funny value which causes the linux time to jump around
like mad.
The solution is "obvious": implement a proper __div64_32
function for 31 bit s390.
Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      3bc587b9
    • Jens Axboe's avatar
      [PATCH] splice: fix pipe_to_file() ->prepare_write() error path · f44a15da
      Jens Axboe authored 
      Don't jump to the unlock+release path, we already did that.
Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      f44a15da
    • Patrick McHardy's avatar
      [PATCH] Fix sfuzz hanging on 2.6.18 · 5bb10961
      Patrick McHardy authored 
      Dave Jones wrote:
> sfuzz         D 724EF62A  2828 28717  28691                     (NOTLB)
>        cd69fe98 00000082 0000012d 724ef62a 0001971a 00000010 00000007 df6d22b0
>        dfd81080 725bbc5e 0001971a 000cc634 00000001 df6d23bc c140e260 00000202
>        de1d5ba0 cd69fea0 de1d5ba0 00000000 00000000 de1d5b60 de1d5b8c de1d5ba0
> Call Trace:
>  [<c05b1708>] lock_sock+0x75/0xa6
>  [<e0b0b604>] dn_getname+0x18/0x5f [decnet]
>  [<c05b083b>] sys_getsockname+0x5c/0xb0
>  [<c05b0b46>] sys_socketcall+0xef/0x261
>  [<c0403f97>] syscall_call+0x7/0xb
> DWARF2 unwinder stuck at syscall_call+0x7/0xb
>
> I wonder if the plethora of lockdep related changes inadvertantly broke something?

Looks like unbalanced locking.
Acked-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      5bb10961
  3. 14 Oct, 2006 1 commit
  5. 13 Oct, 2006 35 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7