On Tue, Feb 21, 2017 at 10:26 AM, David Miller <da...@davemloft.net> wrote: > From: Eric Dumazet <eduma...@google.com> > Date: Tue, 21 Feb 2017 06:21:47 -0800 > >> This reverts commit e70ac171658679ecf6bea4bbd9e9325cd6079d2b. >> >> jtcp_rcv_established() is in fact called with hard irq being disabled. >> >> Initial bug report from Ricardo Nabinger Sanchez [1] still needs >> to be investigated, but does not look like a TCP bug. >> >> [1] https://www.spinics.net/lists/netdev/msg420960.html >> >> Signed-off-by: Eric Dumazet <eduma...@google.com> >> Reported-by: kernel test robot <xiaolong...@intel.com> >> Cc: Ricardo Nabinger Sanchez <rnsanc...@gmail.com> > > Applied. > > But your analysis was quite sound, we can now invoke TCP input path > from user context, therefore this jprobe needs to use BH locking. What > is the problem.
If hard irq are masked, then using spin_lock() should work without a lockdep splat. The problem here is some false positive, as if one trace_hardirqs_off() was missing. Peter originally fixed the issue back in this commit : commit 58dfe883d3bc3b4c08c53a7f39e2ca3ec84f089e Author: Peter Zijlstra <a.p.zijls...@chello.nl> Date: Thu Oct 11 22:25:25 2007 +0200 So really I have no idea what is happening, because the trace_hardirqs_off() is still in x86 setjmp_pre_handler() Maybe some FTRACE interaction ?
