Re: [PATCH] usb: gadget: dummy_hcd: execute hrtimer callback in softirq context

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 27, 2024 at 02:02:00AM +0200, Andrey Konovalov wrote:
> On Mon, Jul 29, 2024 at 4:23 AM <andrey.konovalov@xxxxxxxxx> wrote:
> >
> > From: Andrey Konovalov <andreyknvl@xxxxxxxxx>
> >
> > Commit a7f3813e589f ("usb: gadget: dummy_hcd: Switch to hrtimer transfer
> > scheduler") switched dummy_hcd to use hrtimer and made the timer's
> > callback be executed in the hardirq context.
> >
> > With that change, __usb_hcd_giveback_urb now gets executed in the hardirq
> > context, which causes problems for KCOV and KMSAN.
> >
> > One problem is that KCOV now is unable to collect coverage from
> > the USB code that gets executed from the dummy_hcd's timer callback,
> > as KCOV cannot collect coverage in the hardirq context.
> >
> > Another problem is that the dummy_hcd hrtimer might get triggered in the
> > middle of a softirq with KCOV remote coverage collection enabled, and that
> > causes a WARNING in KCOV, as reported by syzbot. (I sent a separate patch
> > to shut down this WARNING, but that doesn't fix the other two issues.)
> >
> > Finally, KMSAN appears to ignore tracking memory copying operations
> > that happen in the hardirq context, which causes false positive
> > kernel-infoleaks, as reported by syzbot.
> >
> > Change the hrtimer in dummy_hcd to execute the callback in the softirq
> > context.
> >
> > Reported-by: syzbot+2388cdaeb6b10f0c13ac@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Closes: https://syzkaller.appspot.com/bug?extid=2388cdaeb6b10f0c13ac
> > Reported-by: syzbot+17ca2339e34a1d863aad@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Closes: https://syzkaller.appspot.com/bug?extid=17ca2339e34a1d863aad
> > Fixes: a7f3813e589f ("usb: gadget: dummy_hcd: Switch to hrtimer transfer scheduler")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Andrey Konovalov <andreyknvl@xxxxxxxxx>
> 
> Hi Greg,
> 
> Could you pick up either this or Marcello's patch
> (https://lkml.org/lkml/2024/6/26/969)? In case they got lost.

Both are lost now, (and please use lore.kernel.org, not lkml.org), can
you resend the one that you wish to see accepted?

thanks,

greg k-h




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux