search for: __atomic_notifier_call_chain

....513388] [ 2.513388] RCU used illegally from idle CPU! [ 2.513388] rcu_scheduler_active = 1, debug_locks = 1 [ 2.513511] RCU used illegally from extended quiescent state! [ 2.513572] 1 lock held by swapper/0/0: [ 2.513626] #0: (rcu_read_lock){......}, at: [<ffffffff810e9fe0>] __atomic_notifier_call_chain+0x0/0x140 [ 2.513815] [ 2.513815] stack backtrace: [ 2.513897] Pid: 0, comm: swapper/0 Not tainted 3.6.5 #1 [ 2.513954] Call Trace: [ 2.514005] <IRQ> [<ffffffff811259a2>] lockdep_rcu_suspicious+0xe2/0x130 [ 2.514107] [<ffffffff810ea10c>] __atomic_notifier_call...

....513388] [ 2.513388] RCU used illegally from idle CPU! [ 2.513388] rcu_scheduler_active = 1, debug_locks = 1 [ 2.513511] RCU used illegally from extended quiescent state! [ 2.513572] 1 lock held by swapper/0/0: [ 2.513626] #0: (rcu_read_lock){......}, at: [<ffffffff810e9fe0>] __atomic_notifier_call_chain+0x0/0x140 [ 2.513815] [ 2.513815] stack backtrace: [ 2.513897] Pid: 0, comm: swapper/0 Not tainted 3.6.5 #1 [ 2.513954] Call Trace: [ 2.514005] <IRQ> [<ffffffff811259a2>] lockdep_rcu_suspicious+0xe2/0x130 [ 2.514107] [<ffffffff810ea10c>] __atomic_notifier_call...

...fff810013aa>] ? xen_hypercall_sched_op+0xa/0x20 [<ffffffff8100a830>] ? xen_safe_halt+0x10/0x20 [<ffffffff8101ec84>] ? default_idle+0x24/0xc0 [<ffffffff8101e28f>] ? arch_cpu_idle+0xf/0x20 [<ffffffff810b2276>] ? cpuidle_idle_call+0xd6/0x1d0 [<ffffffff81091312>] ? __atomic_notifier_call_chain+0x12/0x20 [<ffffffff810b24a5>] ? cpu_idle_loop+0x135/0x1e0 [<ffffffff810b256b>] ? cpu_startup_entry+0x1b/0x70 [<ffffffff810b25b0>] ? cpu_startup_entry+0x60/0x70 [<ffffffff81667c57>] ? rest_init+0x77/0x80 [<ffffffff81d774c9>] ? start_kernel+0x441/0x448 [<ffffff...

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

...? native_safe_halt+0x6/0x10 [ 39.633076] [<ffffffff8112753c>] handle_irq_event_percpu+0x7c/0x240 [ 39.633076] [<ffffffff8112a789>] handle_percpu_irq+0x49/0x70 [ 39.633076] [<ffffffff813c171d>] __xen_evtchn_do_upcall+0x38d/0x3a0 [ 39.633076] [<ffffffff816971e6>] ? __atomic_notifier_call_chain+0x26/0x40 [ 39.633076] [<ffffffff813c176a>] xen_evtchn_do_upcall+0x2a/0x40 [ 39.633076] [<ffffffff8169ceed>] xen_hvm_callback_vector+0x6d/0x80 [ 39.633076] <EOI> [ 39.633076] [<ffffffff810ce118>] ? sched_clock_cpu+0xb8/0x110 [ 39.633076] [<ffffffff81085736...