Re: call_rcu from trace_preempt

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Jun 17, 2015 at 11:39:29AM -0700, Alexei Starovoitov wrote:
> On 6/17/15 2:05 AM, Daniel Wagner wrote:
> >>>Steven's suggestion deferring the work via irq_work results in the same
> >>>stack trace. (Now I get cold feets, without the nice heat from the CPU
> >>>busy looping...)
> >That one still not working. It also makes the system really really slow.
> >I guess I still do something completely wrong.
> 
> tried your irq_work patch. It indeed makes the whole system
> unresponsive. Ctrl-C of hwlathist no longer works and
> it runs out of memory in 20 sec or so of running hwlathist
> on idle system (without parallel hackbench).
> It looks that free_pending flag is racy, so I removed it,
> but it didn't help.
> 
> Also I've tried all sort of other things in rcu including
> add rcu_bpf similar to rcu_sched to make sure that recursive
> call into call_rcu will not be messing rcu_preempt or rcu_sched
> states and instead will be operating on rcu_bpf per-cpu states.
> In theory that should have worked flawlessly and it sort-of did.
> But multiple hackbench runs still managed to crash it.
> So far I think the temp workaround is to stick with array maps
> for probing such low level things like trace_preempt.
> Note that pre-allocation of all elements in hash map also won't
> help, since the problem here is some collision of call_rcu and
> rcu_process_callbacks. I'm pretty sure that kfree_rcu with
> rcu_is_watching patch is ready for this type of abuse.
> The rcu_process_callbacks() path - no yet. I'm still analyzing it.

How about if I just gave you a hook in __call_rcu() itself, just before
it returns, just after the local_irq_restore()?  You could maintain
recursion flags and test the environment, at some point handling any
memory that needed freeing.

The idea would be to use an atomic queue to accumulate the to-be-freed
data, then kfree_rcu() it in the hook if it was safe to do so.

I really don't trust the re-entrancy, especially not in the long term.

							Thanx, Paul