* Ingo Molnar <[EMAIL PROTECTED]> wrote: > could you please try the patch below? This is pretty much the only > condition under which we can silently 'leak' pending softirqs, and > trigger the new warning: if something does cond_resched_softirq() in > non-runnable state. (which is a no-no, but nothing enforced this, so > it could in theory happen.) So the question is, with this patch > applied, do you get these new warnings from sched.c?
it just triggered on one of my boxes: BUG: at kernel/sched.c:4692 cond_resched_softirq() [<c03ce128>] cond_resched_softirq+0x5f/0x7b [<c0369078>] release_sock+0x42/0x81 [<c03693bc>] sk_wait_data+0x57/0x9d [<c0129a00>] autoremove_wake_function+0x0/0x33 [<c03942ff>] tcp_recvmsg+0x39c/0x973 [<c0368e39>] sock_common_recvmsg+0x3e/0x54 [<c0367903>] sock_aio_read+0x106/0x112 [<c0159b0c>] do_sync_read+0xc8/0x105 [<c0129a00>] autoremove_wake_function+0x0/0x33 [<c0159e82>] vfs_read+0xc1/0x15a [<c015a7d2>] sys_read+0x41/0x67 [<c0103c10>] syscall_call+0x7/0xb ======================= so tcp_recvmsg() definitely gets into this condition. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/