search for: atomic_notifier_call_chain

kernel use callback linked in panic_notifier_list to notice others when panic happens. NORET_TYPE void panic(const char * fmt, ...){ ... atomic_notifier_call_chain(&panic_notifier_list, 0, buf); } When xen aware this, it will call xen_reboot(SHUTDOWN_crash) to send out an event with reason code - SHUTDOWN_crash. xen_panic_handler_init() is defined to register on panic_notifier_list but we only call it in xen_arch_setup which only be called by pvm, this pa...

kernel use callback linked in panic_notifier_list to notice others when panic happens. NORET_TYPE void panic(const char * fmt, ...){ ... atomic_notifier_call_chain(&panic_notifier_list, 0, buf); } When xen aware this, it will call xen_reboot(SHUTDOWN_crash) to send out an event with reason code - SHUTDOWN_crash. xen_panic_handler_init() is defined to register on panic_notifier_list but we only call it in xen_arch_setup which only be called by pvm, this pa...

kernel use callback linked in panic_notifier_list to notice others when panic happens. NORET_TYPE void panic(const char * fmt, ...){ ... atomic_notifier_call_chain(&panic_notifier_list, 0, buf); } When xen aware this, it will call xen_reboot(SHUTDOWN_crash) to send out an event with reason code - SHUTDOWN_crash. xen_panic_handler_init() is defined to register on panic_notifier_list but we only call it in xen_arch_setup which only be called by pvm, this pa...

...13388] [ 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...

...13388] [ 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...

...fa75>] ? do_softirq+0x65/0xa0 [<ffffffff8107a6c5>] ? irq_exit+0x85/0x90 [<ffffffff8151b165>] ? do_IRQ+0x75/0xf0 [<ffffffff8100b9d3>] ? ret_from_intr+0x0/0x11 <EOI> [<ffffffff81016627>] ? mwait_idle+0x77/0xd0 [<ffffffff815176fa>] ? atomic_notifier_call_chain+0x1a/0x20 [<ffffffff81009fc6>] ? cpu_idle+0xb6/0x110 [<ffffffff814f6e3a>] ? rest_init+0x7a/0x80 [<ffffffff81c25f70>] ? start_kernel+0x405/0x411 [<ffffffff81c2533a>] ? x86_64_start_reservations+0x125/0x129 [<ffffffff81c25453>] ? x86_64_start_ker...

http://bugzilla.netfilter.org/show_bug.cgi?id=714 Summary: Kernel panics in same_src() Product: netfilter/iptables Version: linux-2.6.x Platform: x86_64 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: NAT AssignedTo: netfilter-buglog at lists.netfilter.org ReportedBy:

...nt_overflow+0x14/0x20 Feb 16 06:07:01 [<ffffffff8101e3fb>] ? x86_pmu_handle_irq+0x1eb/0x250 Feb 16 06:07:01 [<ffffffff81535ed9>] ? perf_event_nmi_handler+0x39/0xb0 Feb 16 06:07:01 [<ffffffff81537995>] ? notifier_call_chain+0x55/0x80 Feb 16 06:07:01 [<ffffffff815379fa>] ? atomic_notifier_call_chain+0x1a/0x20 Feb 16 06:07:01 [<ffffffff810a4ede>] ? notify_die+0x2e/0x30 Feb 16 06:07:01 [<ffffffff8153565b>] ? do_nmi+0x1bb/0x340 Feb 16 06:07:01 [<ffffffff81534f20>] ? nmi+0x20/0x30 Feb 16 06:07:01 [<ffffffff8153478e>] ? _spin_lock+0x1e/0x30 Feb 16 06:07:01 <<EOE&g...

...2 backup kernel: [<ffffffff81506095>] ? do_IRQ+0x75/0xf0 Oct 18 03:10:52 backup kernel: [<ffffffff8100ba53>] ? ret_from_intr+0x0/0x11 Oct 18 03:10:52 backup kernel: <EOI> [<ffffffff81014877>] ? mwait_idle+0x77/0xd0 Oct 18 03:10:52 backup kernel: [<ffffffff8150392a>] ? atomic_notifier_call_chain+0x1a/0x20 Oct 18 03:10:52 backup kernel: [<ffffffff81009e06>] ? cpu_idle+0xb6/0x110 Oct 18 03:10:52 backup kernel: [<ffffffff814e48da>] ? rest_init+0x7a/0x80 Oct 18 03:10:52 backup kernel: [<ffffffff81c21f7b>] ? start_kernel+0x424/0x430 Oct 18 03:10:52 backup kernel: [<ffffffff...

NOTE: this is happening on Centos 6 x86_64, 2.6.32-504.3.3.el6.x86_64 not Centos 5 Dell PowerEdge 2970, Seagate SATA drive, non-raid. I have this server which has been dying randomly, with no logs. I had a tail -f over ssh for a week, when this just happened. Feb 8 00:10:21 thirteen-230 kernel: mptscsih: ioc0: attempting task abort! (sc=ffff880057a0a080) Feb 8 00:10:21 thirteen-230 kernel:

...ime/timekeeping.c @@ -198,6 +198,25 @@ static inline s64 timekeeping_get_ns_raw(struct timekeeper *tk) return nsec + get_arch_timeoffset(); } +ATOMIC_NOTIFIER_HEAD(clock_was_set_notifier_list); +EXPORT_SYMBOL_GPL(clock_was_set_notifier_list); + +static void timekeeping_clock_was_set(void) +{ + atomic_notifier_call_chain(&clock_was_set_notifier_list, 0, NULL); +} + +static void timekeeping_clock_was_set_task(unsigned long d) +{ + timekeeping_clock_was_set(); +} +DECLARE_TASKLET(clock_was_set_tasklet, timekeeping_clock_was_set_task, 0); + +static void timekeeping_clock_was_set_delayed(void) +{ + tasklet_schedule...

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

...sr(int irq, void *data) +{ + fsl_hv_queue_doorbell((uintptr_t) data); + + return IRQ_HANDLED; +} + +/* + * State change thread function + * + * The state change notification arrives in an interrupt, but we can't call + * blocking_notifier_call_chain() in an interrupt handler. We could call + * atomic_notifier_call_chain(), but that would require the clients' call-back + * function to run in interrupt context. Since we don't want to impose that + * restriction on the clients, we use a threaded IRQ to process the + * notification in kernel context. + */ +static irqreturn_t fsl_hv_state_change_thread(int irq...

...sr(int irq, void *data) +{ + fsl_hv_queue_doorbell((uintptr_t) data); + + return IRQ_HANDLED; +} + +/* + * State change thread function + * + * The state change notification arrives in an interrupt, but we can't call + * blocking_notifier_call_chain() in an interrupt handler. We could call + * atomic_notifier_call_chain(), but that would require the clients' call-back + * function to run in interrupt context. Since we don't want to impose that + * restriction on the clients, we use a threaded IRQ to process the + * notification in kernel context. + */ +static irqreturn_t fsl_hv_state_change_thread(int irq...

...sr(int irq, void *data) +{ + fsl_hv_queue_doorbell((uintptr_t) data); + + return IRQ_HANDLED; +} + +/* + * State change thread function + * + * The state change notification arrives in an interrupt, but we can't call + * blocking_notifier_call_chain() in an interrupt handler. We could call + * atomic_notifier_call_chain(), but that would require the clients' call-back + * function to run in interrupt context. Since we don't want to impose that + * restriction on the clients, we use a threaded IRQ to process the + * notification in kernel context. + */ +static irqreturn_t fsl_hv_state_change_thread(int irq...

...sr(int irq, void *data) +{ + fsl_hv_queue_doorbell((uintptr_t) data); + + return IRQ_HANDLED; +} + +/* + * State change thread function + * + * The state change notification arrives in an interrupt, but we can't call + * blocking_notifier_call_chain() in an interrupt handler. We could call + * atomic_notifier_call_chain(), but that would require the clients' call-back + * function to run in interrupt context. Since we don't want to impose that + * restriction on the clients, we use a threaded IRQ to process the + * notification in kernel context. + */ +static irqreturn_t fsl_hv_state_change_thread(int irq...

...ffff88000f005f58 0000000000000ac0 0000000088000cd8 [ 4.140042] 0000000000000000 0000000000000040 ffff88000f005ec8 ffffffff8102c039 [ 4.140042] Call Trace: [ 4.140042] <#DF> [ 4.140042] [<ffffffff8102c039>] show_regs+0x70/0x1d8 [ 4.140042] [<ffffffff810aa597>] ? atomic_notifier_call_chain+0xf/0x11 [ 4.140042] [<ffffffff8102cf01>] __die+0xaa/0xe9 [ 4.140042] [<ffffffff8102cf82>] die+0x42/0x5e [ 4.140042] [<ffffffff8102aadb>] do_double_fault+0x5f/0x61 [ 4.140042] [<ffffffff8185a39d>] double_fault+0x2d/0x40 [ 4.140042] <<EOE>> [...