Am I right in blaming FUSE for this? BUG: scheduling while atomic: python/6728/0x10000001 Modules linked in: ip6table_filter ip6_tables binfmt_misc vmnet vmblock vsock vmci vmmon ipt_M Pid: 6728, comm: python Not tainted 2.6.35-23-generic #41-Ubuntu Call Trace: [<c013eb32>] __schedule_bug+0x62/0x70 [<c05c7700>] schedule+0x760/0x7a0 [<c05c94ef>] ? _raw_spin_lock_irqsave+0x2f/0x50 [<c01316e0>] ? gup_pte_range+0x100/0x170 [<c05c7882>] _cond_resched+0x32/0x50 [<c020c828>] kmem_cache_alloc_notrace+0x78/0xb0 [<c0131795>] ? gup_pud_range+0x45/0x80 [<c02ea58a>] ? fuse_notify_inval_entry+0x2a/0x1b0 [<c02ea58a>] fuse_notify_inval_entry+0x2a/0x1b0 [<f83b47fd>] ? i915_driver_irq_handler+0x21d/0x490 [i915] [<c02e872c>] ? fuse_copy_do+0x3c/0x70 [<c02ea78b>] fuse_notify+0x7b/0xc0 [<c02e8a7d>] ? fuse_copy_one+0x3d/0x50 [<c02ea8cc>] fuse_dev_do_write+0xfc/0x320 [...] This is not reproducible at will, but happens several times a day. The fuse_notify_inval_entr is always near the top of the call stack.
I have learned that the following is useful for debugging "scheduling while atomic" bugs. The respective files are attached: $ sudo sh -c "echo 1 > /sys/kernel/debug/tracing/options/latency-format" $ sudo sh -c "echo 1 > /sys/kernel/debug/tracing/tracing_enabled" $ sudo sh -c "echo 1 > /sys/kernel/debug/tracing/tracing_on" $ sudo sh -c "echo function > /sys/kernel/debug/tracing/current_tracer" (reproduced bug) $ bzip2 -c /sys/kernel/debug/tracing/trace > trace.bz2 $ dmesg | bzip2 > dmesg.bz2
Created attachment 42852 [details] dmesg output after reproducing bug
Created attachment 42862 [details] contents of /sys/kernel/debug/tracing/trace after reproducing bug
Bug seems to exist in 2.6.35, but not in 2.6.37-rc2.