Messages in this thread | | | Date | Thu, 1 Sep 2005 14:42:11 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH]kprobes fix bug when probed on task and isr functions |
| |
Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com> wrote: > > > > void __kprobes lock_kprobes(void) > > > { > > > + unsigned long flags = 0; > > > + > > > + local_irq_save(flags); > > > spin_lock(&kprobe_lock); > > > kprobe_cpu = smp_processor_id(); > > > + local_irq_restore(flags); > > > } > > > > what is this change trying to do? If a lock is taken from both process and > > irq contexts then local IRQs must be disabled for the entire period when the > > lock is held, not just for a little blip like this. If IRQ-context code is > > running this function then the code is deadlockable. > > In the kprobe exception handling we relay on kprobe_cpu = smp_processor_id() to determine > whether we are inside the kprobe or not. It was so happeing that when we > take the lock and before kprobe_cpu gets updated if an H/W interrupt happens > and if kprobe is enabled on ISR routine, then in the kprobe execption handler > for isr, we miss the indication that we are already in kprobes(since interrupt > happened before we get to update kprobe_cpu) and we were trying to > take the lock again and there by causing the deadlock. This deadlock is avoided > by disabling the ISR for a short period while we take the spin_lock() and update > the kprobe_cpu.
OK.
Are you sure that other CPUs can safely read kprobe_cpu without taking the lock? I don't see any memory barriers in there...
> > > > Now, probably there's deep magic happening here and I'm wrong. If so then > > please explain the code's magic via a comment patch so the question doesn't > > arise again, thanks. > > > > This whole serialization will go away when we introduce the scalability patch.
Yes, it does look rather unscalable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |