From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10525 invoked by alias); 17 Nov 2006 23:19:12 -0000 Received: (qmail 10489 invoked by uid 48); 17 Nov 2006 23:19:02 -0000 Date: Sat, 18 Nov 2006 14:27:00 -0000 From: "jkenisto at us dot ibm dot com" To: systemtap@sources.redhat.com Message-ID: <20061117231901.3541.jkenisto@us.ibm.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug kprobes/3541] New: unsafe printk calls in hand-coded kprobe handlers X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00463.txt.bz2 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.