On Tue, Feb 21, 2017 at 10:26 AM, David Miller <[email protected]> wrote: > From: Eric Dumazet <[email protected]> > 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 <[email protected]> >> Reported-by: kernel test robot <[email protected]> >> Cc: Ricardo Nabinger Sanchez <[email protected]> > > 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 <[email protected]> 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 ?
