On Sat, Nov 02, 2024 at 10:41:19PM -0400, Alan Stern wrote:
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@igalia.com/
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.
I've queued this up. And yes, giving us the IDs would be easier (which is what I ended up doing here).
Thanks!