Skip to content

L
linux

Linux-御风守护者 / linux
与 Fork 源项目一致

从无法访问的项目Fork

通知 1
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 14 10月, 2009 1 次提交
    • T
      futex: Handle spurious wake up · d58e6576
      由 Thomas Gleixner 提交于 
      The futex code does not handle spurious wake up in futex_wait and
futex_wait_requeue_pi.

The code assumes that any wake up which was not caused by futex_wake /
requeue or by a timeout was caused by a signal wake up and returns one
of the syscall restart error codes.

In case of a spurious wake up the signal delivery code which deals
with the restart error codes is not invoked and we return that error
code to user space. That causes applications which actually check the
return codes to fail. Blaise reported that on preempt-rt a python test
program run into a exception trap. -rt exposed that due to a built in
spurious wake up accelerator :)

Solve this by checking signal_pending(current) in the wake up path and
handle the spurious wake up case w/o returning to user space.
Reported-by: NBlaise Gassend <blaise@willowgarage.com>
Debugged-by: NDarren Hart <dvhltc@us.ibm.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@kernel.org
LKML-Reference: <new-submission>
      d58e6576
  3. 13 10月, 2009 1 次提交
  5. 10 10月, 2009 2 次提交
    • R
      oprofile: warn on freeing event buffer too early · c0868934
      由 Robert Richter 提交于 
      A race shouldn't happen since all workqueues or handlers are canceled
or flushed before the event buffer is freed. A warning is triggered
now if the buffer is freed too early.

Also, this patch adds some comments about event buffer protection,
reworks some code and adds code to clear buffer_pos during alloc and
free of the event buffer.

Cc: David Rientjes <rientjes@google.com>
Cc: Stephane Eranian <eranian@google.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
      c0868934
    • D
      oprofile: fix race condition in event_buffer free · 066b3aa8
      由 David Rientjes 提交于 
      Looking at the 2.6.31-rc9 code, it appears there is a race condition
in the event_buffer cleanup code path (shutdown). This could lead to
kernel panic as some CPUs may be operating on the event buffer AFTER
it has been freed. The attached patch solves the problem and makes
sure CPUs check if the buffer is not NULL before they access it as
some may have been spinning on the mutex while the buffer was being
freed.

The race may happen if the buffer is freed during pending reads. But
it is not clear why there are races in add_event_entry() since all
workqueues or handlers are canceled or flushed before the event buffer
is freed.
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
      066b3aa8
  7. 09 10月, 2009 15 次提交
  9. 08 10月, 2009 21 次提交