On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes <joe...@google.com> wrote: > Hi Steve, > > On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt <rost...@goodmis.org> wrote: [...] >>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void); >>> } while ((++it_func_ptr)->func); \ >>> } \ >>> \ >>> - if (rcuidle) \ >>> - srcu_read_unlock_notrace(&tracepoint_srcu, idx);\ >>> + srcu_read_unlock_notrace(ss, idx); \ >> >> Hmm, why do we have the two different srcu handles? > > Because if the memory operations happening on the normal SRCU handle > (during srcu_read_lock) is interrupted by NMI, then the other handle > (devoted to NMI) could be used instead and not bother the interrupted > handle. Does that makes sense? > > When I talked to Paul few months ago about SRCU from NMI context, he > mentioned the per-cpu memory operations during srcu_read_lock can be > NMI interrupted, that's why we added that warning.
So I looked more closely, __srcu_read_lock on 2 different handles may still be doing a this_cpu_inc on the same location.. (sp->sda->srcu_lock_count). :-( Paul any ideas on how to solve this? It does start to seem like a show stopper :-(
