On Sat, Nov 02, 2024 at 11:13:49PM -0300, Guilherme G. Piccoli wrote: > Hi folks, here is a series with some fixes for dummy_hcd. First of all, > the reasoning behind it. > > Syzkaller report [0] shows a hung task on uevent_show, and despite it was > fixed with a patch on drivers/base (a race between drivers shutdown and > uevent_show), another issue remains: a problem with Realtek emulated wifi > device [1]. While working the fix ([1]), we noticed that if it is > applied to recent kernels, all fine. But in v6.1.y and v6.6.y for example, > it didn't solve entirely the issue, and after some debugging, it was > narrowed to dummy_hcd transfer rates being waaay slower in such stable > versions. > > The reason of such slowness is well-described in the first 2 patches of > this backport, but the thing is that these patches introduced subtle issues > as well, fixed in the other 2 patches. Hence, I decided to backport all of > them for the 2 latest LTS kernels. > > Maybe this is not a good idea - I don't see a strong con, but who's > better to judge the benefits vs the risks than the patch authors, > reviewers, and the USB maintainer?! So, I've CCed Alan, Andrey, Greg and > Marcello here, and I thank you all in advance for reviews on this. And > my apologies for bothering you with the emails, I hope this is a simple > "OK, makes sense" or "Nah, doesn't worth it" situation =) > > Cheers, > > > Guilherme > > > [0] https://syzkaller.appspot.com/bug?extid=edd9fe0d3a65b14588d5 > [1] https://lore.kernel.org/r/20241101193412.1390391-1-gpiccoli@xxxxxxxxxx/ > > > Alan Stern (1): > USB: gadget: dummy-hcd: Fix "task hung" problem > > Andrey Konovalov (1): > usb: gadget: dummy_hcd: execute hrtimer callback in softirq context > > Marcello Sylvester Bauer (2): > usb: gadget: dummy_hcd: Switch to hrtimer transfer scheduler > usb: gadget: dummy_hcd: Set transfer interval to 1 microframe > > drivers/usb/gadget/udc/dummy_hcd.c | 57 ++++++++++++++++++++---------- > 1 file changed, 38 insertions(+), 19 deletions(-) I'm not aware of any reasons not to backport these commits to the stable kernels, if they fix a real problem for you. However, it probably wasn't necessary to post the patches explicitly. (Not unless they required some modifications for the backports.) I should think all you really needed to do was ask the appropriate maintainers to queue those commits for the stable kernels you listed. Alan Stern
