On Fri, Jun 03, 2022 at 06:11:55PM +0200, Greg KH wrote: > On Fri, Jun 03, 2022 at 12:03:32PM -0400, Alan Stern wrote: > > On Fri, Jun 03, 2022 at 05:52:38PM +0200, Greg KH wrote: > > > On Fri, Jun 03, 2022 at 11:42:19AM -0400, Alan Stern wrote: > > > > So now what should happen when device_add() for an interface fails in > > > > usb_set_configuration()? > > > > > > But how can that really fail on a real system? > > > > > > Is this just due to error-injection stuff? If so, I'm really loath to > > > rework the world for something that can never happen in real life. > > > > > > Or is this a real syzbot-found-with-reproducer issue? > > > > Aren't there quite a few reasons why device_add() might fail? (Although > > most of them probably are memory allocation errors...) > > I was thinking of the dev_set_name() issue further back in the call > chain. As far as I know, the only reason for dev_set_name() to fail is -ENOMEM. That's not something the user can control directly. > > Basically, you have to make up your mind. If a function can fail, you > > should be prepared to handle the failure. If it can't fail, there's no > > point in even checking the return code. > > True, ok, we should unwind the mess. I'll try to look at it after the > merge window... > > But again, is this a "real and able to be triggered from userspace" > problem, or just fault-injection-induced? I don't think any of the failure paths here are controlled by the user. They all seem to involve something going wrong internally in the kernel (i.e., corruption or memory allocation failure for a small buffer). Once that happens, the game is pretty much over anyway. Is it worth handling this sort of thing, or should we ignore the possibility and allow it to escalate to the point where the user can potentially trigger a kernel panic? Another way of putting it is: How gracefully do you want the kernel to collapse when this sort of corruption happens? Alan Stern
