> -----Original Message----- > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, July 21, 2021 9:53 AM > To: Zhang, Qiang <Qiang.Zhang@xxxxxxxxxxxxx> > Cc: stern@xxxxxxxxxxxxxxxxxxx; dvyukov@xxxxxxxxxx; paulmck@xxxxxxxxxx; > dpenkler@xxxxxxxxx; Kiener Guido 14DS1 <Guido.Kiener@xxxxxxxxxxxxxxxxx>; > linux-usb@xxxxxxxxxxxxxxx > Subject: *EXT* Re: [PATCH] USB: usbtmc: Fix RCU stall warning > > On Wed, Jul 21, 2021 at 07:30:39AM +0000, Zhang, Qiang wrote: > > > > > > ________________________________________ > > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > > Sent: Wednesday, 21 July 2021 15:08 > > To: Zhang, Qiang > > Cc: stern@xxxxxxxxxxxxxxxxxxx; dvyukov@xxxxxxxxxx; paulmck@xxxxxxxxxx; > > dpenkler@xxxxxxxxx; guido.kiener@xxxxxxxxxxxxxxxxx; > > linux-usb@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH] USB: usbtmc: Fix RCU stall warning > > > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > On Tue, Jun 29, 2021 at 11:32:36AM +0800, qiang.zhang@xxxxxxxxxxxxx wrote: > > > From: Zqiang <qiang.zhang@xxxxxxxxxxxxx> > > > > >I need a "full" name here, and in the signed-off-by line please. > > > > > > > > rcu: INFO: rcu_preempt self-detected stall on CPU > > > rcu: 1-...!: (2 ticks this GP) idle=d92/1/0x4000000000000000 > > > softirq=25390/25392 fqs=3 > > > (t=12164 jiffies g=31645 q=43226) > > > rcu: rcu_preempt kthread starved for 12162 jiffies! g31645 f0x0 > > > RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 > > > rcu: Unless rcu_preempt kthread gets sufficient CPU time, > > > OOM is now expected behavior. > > > rcu: RCU grace-period kthread stack dump: > > > task:rcu_preempt state:R running task > > > > > > In the case of system use dummy_hcd as usb controller, when the > > > usbtmc devices is disconnected, in usbtmc_interrupt(), if the urb > > > status is unknown, the urb will be resubmit, the urb may be insert > > > to dum_hcd->urbp_list again, this will cause the dummy_timer() not > > > to exit for a long time, beacause the dummy_timer() be called in > > > softirq and local_bh is disable, this not only causes the RCU > > > reading critical area to consume too much time but also makes the > > > tasks in the current CPU runq not run in time, and that triggered RCU stall. > > > > > > return directly when find the urb status is not zero to fix it. > > > > > > Reported-by: syzbot+e2eae5639e7203360018@xxxxxxxxxxxxxxxxxxxxxxxxx > > > Signed-off-by: Zqiang <qiang.zhang@xxxxxxxxxxxxx> > > > > >What commit does this fix? Does it need to go to stable kernels? > > > > I will add fix tags resend, need to go to stable kernel > > > > > > > >What about the usbtmc maintainers, what do they think about this? I'm ok with the fix. It will make the syzbot and dummy_hcd controller happy when using the usbtmc driver. Nevertheless there are many other usb kernel driver that resubmit the urb when the callback handler detects the urb status = -EPROTO. So I expect the issue will rehappen with other usb drivers again. In "normal" environments the urb status = -EPROTO will mostly happen when the cable is disconnected, but it does not freeze the kernel and shuts down the connection as usual. Up to now we have no customer feedback which is blaming this issue. I hope this helps. -Guido
