On 2016-10-12 22:26:01 [-0400], brian@xxxxxxxxxxxxxxxx wrote: > From: mbeauch <mbeauch@xxxxxxx> > > Changed the real-time patch code to detect recursive calls > to dev_queue_xmit and drop the packet when detected. > > >From Brian Silverman: > !RT is relying on rcu_read_lock_bh to disable preemption here, so it can > rely a given smp_processor_id() only being in the call stack once. > However, on RT, that's not true when one task preempts another one, > which results in false warnings and dropped packets. > > Without this, messages like > "Dead loop on virtual device vcan0, fix it urgently!" show up in dmesg > when multiple processes are sending on the same virtual device at the > same time and sendmsg calls return ENETDOWN at random. > > This also includes "543a589a00e8 net: xmit lock owner cleanup" from > v2.6.33.9-rt31 by mingo and tglx, which was just some cleanups to the > original patch which make porting to to current upstream easier. > > Signed-off-by: Mark Beauchemin <mark.beauchemin@xxxxxxxxxxxxxxx> > [ ported to latest upstream ] > Signed-off-by: Ingo Molnar <mingo@xxxxxxx> > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > [ ported to 4.8 and used struct task_struct instead of void ] > Signed-off-by: Brian Silverman <brian@xxxxxxxxxxxxxxxx> The signed-off-by chain suggest that Mark passed the patch to Ingo, Thomas and to Brian. I doubt that. I can't resolve the sha1 id mentioned here. Do you have a testcase for this? Speaking of vcan, then this is something that does not require real HW. Is this still broken as of v4.8-RT? I remember fixing something similar with bridge devices. I suggest to not use the second the argument of __netif_tx_lock() instead patching it away it a bunch of drivers. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html