Re: [RFC PATCH 0/6] kprobes: remove global kprobe_lock

[Mathieu Desnoyers <compudj at krystal dot dyndns dot org>]

* Ananth N Mavinakayanahalli (amavin@redhat.com) wrote:
> 
> And then there is RCU. With RCU you can run handlers without *any*
> locking.
> 

Yes indeed, as the locking is implicit in the reader requirement to never call a
wakeup and to disable preemption, so the reader is guaranteed to have finished
when the writer receives the information about readiness to erase the actual
data structure, after having removed the pointer to it in the first place.

> >Someone, at OLS, suggested that it was like the brlock (for big reader 
> >lock).
> >The subtile enhancements of my implementation is the use of per_cpu 
> >variables to
> >hold the spinlocks, benefits :
> >  - No false sharing of the spinlocks.
> >  - Does no waste precious cpu cache space by aligning each spinlock on 
> >  cache
> >    line boundaries : it's implicit in the per_cpu variables.
> >
> >
> >What do you think about it ?
> 
> Well, I have a RCU based prototype which could potentially be the
> fastest of the lot. However, I saw some wierd issues on an 8-way x86 smp
> with a kprobe on "schedule" and "make -j8" of the linux kernel. rmmod on
> the kprobe module never returned. Still working on it. Needs more 
> polishing and testing :-)
> 

I had some problems with schedule instrumentation too. Just making sure : you
never call printk from schedule nor wakeup, don't you ? Because this is a
subtility of printk : they call the schedule, and cannot be put in its code,
otherwise causing a deadlock on the scheduler spinlock.

As the writer, in RCU, does wait for the reader to be scheduled to be informed
that it can coherently erase the data structure, I would suggest investigating
further the mecanism responsible to inform the writer of this schedule change :
if this mechanism calls a scheduler function that locks the scheduler lock, you
might be in a deadlock involving the scheduler lock.


> I've heard from most users that they don't care about the probe
> insertion/removal overheads, only that they are concerned with handler 
> execution times.
>

That's why a solution with fastest read, slow write, seems applicable.

> The goal is to finally have an RCU based mechanism for kprobes. The 
> rwlock patchset is the first step in that direction.
> 

In LTT experimental, RCU is my goal too, but I keep it for a later optimisation
phase.


Mathieu

OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68