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

[Dan Carpenter <dan.carpenter@oracle.com>]

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.

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
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html