Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752825AbdLGVAG (ORCPT ); Thu, 7 Dec 2017 16:00:06 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:33800 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751022AbdLGVAE (ORCPT ); Thu, 7 Dec 2017 16:00:04 -0500 Date: Thu, 7 Dec 2017 23:51:56 +0300 From: Dan Carpenter To: Alan Stern Cc: Geert Uytterhoeven , SF Markus Elfring , USB list , Joe Perches , Daniel Drake , Dmitry Fleytman , Eugene Korenevsky , Greg Kroah-Hartman , =?iso-8859-1?Q?G=FCnter_R=F6ck?= , Johan Hovold , Mathias Nyman , Peter Chen , LKML , "kernel-janitors@vger.kernel.org" Subject: Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer() Message-ID: <20171207204953.5gsk26pk4b5xaizq@mwanda> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8738 signatures=668644 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=435 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712070307 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1660 Lines: 48 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