On Fri, Nov 13, 2020 at 4:47 PM Marco Elver <el...@google.com> wrote: > > On Fri, 13 Nov 2020 at 14:42, Andrey Konovalov <andreyk...@google.com> wrote: > > On Fri, Nov 13, 2020 at 2:28 PM Sebastian Andrzej Siewior > > <bige...@linutronix.de> wrote: > > > > > > On 2020-11-13 13:51:19 [+0100], Andrey Konovalov wrote: > > > > Hi Sebastian, > > > > > > Hi Andrey, > > > > > > > Replaced with what and why? > > > > > > Linus requested in > > > > > > https://lkml.kernel.org/r/CAHk-=wht7kaeyr5xew2orj7m0hibvxz3t+2ie8vnhlqfdbn...@mail.gmail.com/ > > > > > > that drivers should not change their behaviour on context magic like > > > in_atomic(), in_interrupt() and so on. > > > The USB bits were posted in > > > https://lkml.kernel.org/r/20201019100629.419020...@linutronix.de > > Arguably this patch is *not* changing "driver behaviour", it's only > changing how and when KCOV collects coverage, which is not related to > how the driver behaves. > > > > and merged (which is probably the same time as this patch). > > > > > > I haven't look what this code should do or does but there are HCDs for > > > which this is never true like the UHCI/OHCI controller for instance. > > > > We could go back to adding softirq-specific kcov callbacks. Perhaps > > with a simpler implementation than what we had before to only cover > > this case. Something like kcov_remote_start_usb_softirq() and > > kcov_remote_stop_softirq() that do the softirq check internally. > > Is this a matter of simply banning such functions entirely without > understanding their use? Because that sounds wrong. But if it is, we > probably have to just add some static inline functions in > include/linux/kcov.h that simply does the check.
Yeah, this seems like a solution that will satisfy everyone. Will mail a new version shortly.
