Hi Peter, On Tue, 25 Aug 2020 14:09:11 +0200 pet...@infradead.org wrote:
> > @@ -1934,50 +1884,28 @@ unsigned long __weak arch_deref_entry_point(void > *entry) > static int pre_handler_kretprobe(struct kprobe *p, struct pt_regs *regs) > { > struct kretprobe *rp = container_of(p, struct kretprobe, kp); > - unsigned long hash, flags = 0; > struct kretprobe_instance *ri; > + struct llist_node *llist; > > - /* > - * To avoid deadlocks, prohibit return probing in NMI contexts, > - * just skip the probe and increase the (inexact) 'nmissed' > - * statistical counter, so that the user is informed that > - * something happened: > - */ > - if (unlikely(in_nmi())) { > + llist = llist_del_first(&rp->free_instances); > + if (!llist) { > rp->nmissed++; > return 0; > } Would we need a lock around llist_del_first(&rp->free_instance) here? linux/llist.h said, * Cases where locking is not needed: * If there are multiple producers and multiple consumers, llist_add can be * used in producers and llist_del_all can be used in consumers simultaneously * without locking. Also a single consumer can use llist_del_first while ^^^^^^^^^^^^^^^^^^^^^^^ * multiple producers simultaneously use llist_add, without any locking. * * Cases where locking is needed: * If we have multiple consumers with llist_del_first used in one consumer, and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * llist_del_first or llist_del_all used in other consumers, then a lock is * needed. pre_handler_kretprobe() can be invoked simultaneously on the different CPUs if those are calling the same probed function. Thank you, -- Masami Hiramatsu <mhira...@kernel.org>