Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

Alan Stern
2017-12-07T21:26:58Z

On Thu, 7 Dec 2017, Dan Carpenter wrote:

> On Thu, Dec 07, 2017 at 10:12:27AM -0500, Alan Stern wrote:
> > The real problem is that the kernel development community doesn't have
> > a fixed policy on how to handle memory allocation errors. There are
> > several possibilities:
> >
> > Ignore them on the grounds that they will never happen.
> > (Really? And what is the size limit above which they
> > might happen?)
> >
>
> It's pretty rare to ignore allocation failures these days. It causes
> static checker warnings.
>
> Sometimes it's accepted for people to ignore errors during boot but
> I hate that because how am I supposed to filter out those static checker
> warnings? It's better to pretend that the kernel will still boot
> without essential hardware instead of wasting everyone's time who looks
> at checker output.
>
> > Ignore them on the grounds that the machine will hang or
> > crash in the near future. (Is this guaranteed?)
>
> On boot sometimes yes.
>
> >
> > Treat them like other errors: try to press forward (perhaps
> > in a degraded mode).
> >
> > Treat them like other errors: log an error message and try
> > to press forward.
> >
>
> The standard is to treat them like errors and try press forward in a
> degraded mode but don't print a message. Checkpatch.pl complains if you
> print a warning for allocation failures. A lot of low level functions
> handle their own messages pretty well but especially kmalloc() does.

Which brings us back to my original objection. If an allocation
failure has localized effects, but the low-level warning is unable to
specify what will be affected, how is the user supposed to connect the
effect to the cause?

Alan Stern

>
> I also have a special static checker warning for when people do:
>
> foo = alloc();
> BUG_ON(!foo);
>
> People do that occasionally but fortunately it's pretty rare. 10 years
> ago that's how btrfs did error handling, but now there are only 4 of
> these still remaining in btrfs.
>
> regards,
> dan carpenter
>
>
>