[Bug kprobes/3541] New: unsafe printk calls in hand-coded kprobe handlers

[Bug kprobes/3541] New: unsafe printk calls in hand-coded kprobe handlers

[jkenisto at us dot ibm dot com]

printk is supposed to be callable from anywhere, but various people have noted
that that's not really the case.  See, for example, bugs 1594, 1837, 1564, and
1776.  This bug report has a little more in the way of specifics on that topic.

In 1776, calling printk from a handler for a probe in activate_task yielded
oopses and/or hangs.  In that particular case, I think a deadlock is caused as
follows: activate_task -> handler -> printk -> release_console_sem [locks
logbuf_lock] -> up -> __up_wakeup -> __up -> wake_up -> __wake_up ->
__wake_up_common -> default_wake_function -> try_to_wake_up -> activate_task ->
handler -> printk [goes for logbuf_lock again].

This is not a problem for SystemTap, which doesn't emit printk calls, but it
could be for kprobes users.  Possible actions we could take include:

1) Document this type of scenario in Documentation/kprobes.txt.  I.e., a handler
for any function callable while logbuf_lock is held shouldn't call printk.

2) Push for an enhancement to printk.c -- e.g.,
a) In release_console_sem, consider releasing logbuf_lock and console_sem in
reverse order.  Unfortunately, while logbuf_lock is held there's also a call to
down_trylock, which can indirectly call wake_up_locked, so that doesn't buy us much.
b) Upon entry to printk, consider calling spin_trylock instead of spin_lock, and
print nothing (and maybe atomic_inc a miss-counter to report later) if we can't
get logbuf_lock.

-- 
           Summary: unsafe printk calls in hand-coded kprobe handlers
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: kprobes
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: jkenisto at us dot ibm dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=3541

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug kprobes/3541] unsafe printk calls in hand-coded kprobe handlers

[jkenisto at us dot ibm dot com]

------- Additional Comments From jkenisto at us dot ibm dot com  2006-11-22 00:05 -------
Since kprobes doesn't allow handlers to re-enter, the likely deadlock scenario
is anybody -> printk -> release_console_sem [locks logbuf_lock] -> up -> ... ->
try_to_wake_up -> activate_task -> handler -> printk [goes for logbuf_lock again].

Re: (2b), spin_trylock_irqsave() (which is what we want) can fail in perfectly
benign scenarios.  If it does, it's a deadlock only if printk_cpu ==
smp_processor_id().  Otherwise, just go for the lock again with spinlock_irq_save().

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3541

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug kprobes/3541] unsafe printk calls in hand-coded kprobe handlers

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-04-01 17:35 -------
I propose a CLOSED/WONTFIX for this one.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=3541

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug kprobes/3541] unsafe printk calls in hand-coded kprobe handlers

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-10-07 14:58 -------
closing, a kernel design issue rather than something in kprobes/systemtap land,
to some extent mooted by recent kernel developments

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WONTFIX


http://sourceware.org/bugzilla/show_bug.cgi?id=3541

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.