On Tue, 25 Sep 2018, Andrey Konovalov wrote: > On Tue, Sep 25, 2018 at 5:15 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 25 Sep 2018, Vladis Dronov wrote: > > > >> > What reason is there for having two different fixes for the same bug? > >> > This one isn't going to get into any mainline trees that don't already > >> > have c9a4cb204e9e. > >> > >> I believe this is the right thing to do, so usb_find_alt_setting() > >> is not called with a known-bad argument. > >> > >> Honestly, I would change "if (!config)" in usb_find_alt_setting() to > >> "BUG_ON(!config)" so we know when its callers do smth wrong and go > > > > (You'll be lucky if Linus doesn't see that. He yells at anybody who > > suggests adding BUG_ON for anything that doesn't completely crash the > > kernel. The basic problem is that "BUG_ON" is not a good name: That > > routine doesn't really report bugs; instead it brings everything to a > > halt in situations where the kernel is unable to proceed. In practice > > this tends to make actual debugging more difficult.) > > What about adding a WARN_ON()? It doesn't crash the kernel and it will > be detected and reported by syzbot. Sure, we could do that. But would be the point? After c9a4cb204e9e, calling usb_find_alt_setting() with a NULL config is no more of a bug than calling kfree() with a NULL pointer. You wouldn't want to put a WARN_ON in kfree(), would you? Alan Stern
