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>
