From mboxrd@z Thu Jan 1 00:00:00 1970 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Carpenter Date: Thu, 07 Dec 2017 20:51:56 +0000 Subject: Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer() Message-Id: <20171207204953.5gsk26pk4b5xaizq@mwanda> List-Id: References: <97b0eeb8-834e-61ca-01dd-afbbf18697db@users.sourceforge.net> In-Reply-To: <97b0eeb8-834e-61ca-01dd-afbbf18697db@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer() From: Dan Carpenter Message-Id: <20171207204953.5gsk26pk4b5xaizq@mwanda> Date: Thu, 7 Dec 2017 23:51:56 +0300 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" List-ID: T24gVGh1LCBEZWMgMDcsIDIwMTcgYXQgMTA6MTI6MjdBTSAtMDUwMCwgQWxhbiBTdGVybiB3cm90 ZToKPiBUaGUgcmVhbCBwcm9ibGVtIGlzIHRoYXQgdGhlIGtlcm5lbCBkZXZlbG9wbWVudCBjb21t dW5pdHkgZG9lc24ndCBoYXZlCj4gYSBmaXhlZCBwb2xpY3kgb24gaG93IHRvIGhhbmRsZSBtZW1v cnkgYWxsb2NhdGlvbiBlcnJvcnMuICBUaGVyZSBhcmUKPiBzZXZlcmFsIHBvc3NpYmlsaXRpZXM6 Cj4gCj4gCUlnbm9yZSB0aGVtIG9uIHRoZSBncm91bmRzIHRoYXQgdGhleSB3aWxsIG5ldmVyIGhh cHBlbi4KPiAJKFJlYWxseT8gIEFuZCB3aGF0IGlzIHRoZSBzaXplIGxpbWl0IGFib3ZlIHdoaWNo IHRoZXkKPiAJbWlnaHQgaGFwcGVuPykKPiAKCkl0J3MgcHJldHR5IHJhcmUgdG8gaWdub3JlIGFs bG9jYXRpb24gZmFpbHVyZXMgdGhlc2UgZGF5cy4gIEl0IGNhdXNlcwpzdGF0aWMgY2hlY2tlciB3 YXJuaW5ncy4KClNvbWV0aW1lcyBpdCdzIGFjY2VwdGVkIGZvciBwZW9wbGUgdG8gaWdub3JlIGVy cm9ycyBkdXJpbmcgYm9vdCBidXQKSSBoYXRlIHRoYXQgYmVjYXVzZSBob3cgYW0gSSBzdXBwb3Nl ZCB0byBmaWx0ZXIgb3V0IHRob3NlIHN0YXRpYyBjaGVja2VyCndhcm5pbmdzPyAgSXQncyBiZXR0 ZXIgdG8gcHJldGVuZCB0aGF0IHRoZSBrZXJuZWwgd2lsbCBzdGlsbCBib290CndpdGhvdXQgZXNz ZW50aWFsIGhhcmR3YXJlIGluc3RlYWQgb2Ygd2FzdGluZyBldmVyeW9uZSdzIHRpbWUgd2hvIGxv b2tzCmF0IGNoZWNrZXIgb3V0cHV0LgoKPiAJSWdub3JlIHRoZW0gb24gdGhlIGdyb3VuZHMgdGhh dCB0aGUgbWFjaGluZSB3aWxsIGhhbmcgb3IKPiAJY3Jhc2ggaW4gdGhlIG5lYXIgZnV0dXJlLiAg KElzIHRoaXMgZ3VhcmFudGVlZD8pCgpPbiBib290IHNvbWV0aW1lcyB5ZXMuCgo+IAo+IAlUcmVh dCB0aGVtIGxpa2Ugb3RoZXIgZXJyb3JzOiB0cnkgdG8gcHJlc3MgZm9yd2FyZCAocGVyaGFwcwo+ IAlpbiBhIGRlZ3JhZGVkIG1vZGUpLgo+IAo+IAlUcmVhdCB0aGVtIGxpa2Ugb3RoZXIgZXJyb3Jz OiBsb2cgYW4gZXJyb3IgbWVzc2FnZSBhbmQgdHJ5Cj4gCXRvIHByZXNzIGZvcndhcmQuCj4gCgpU aGUgc3RhbmRhcmQgaXMgdG8gdHJlYXQgdGhlbSBsaWtlIGVycm9ycyBhbmQgdHJ5IHByZXNzIGZv cndhcmQgaW4gYQpkZWdyYWRlZCBtb2RlIGJ1dCBkb24ndCBwcmludCBhIG1lc3NhZ2UuICBDaGVj a3BhdGNoLnBsIGNvbXBsYWlucyBpZiB5b3UKcHJpbnQgYSB3YXJuaW5nIGZvciBhbGxvY2F0aW9u IGZhaWx1cmVzLiAgQSBsb3Qgb2YgbG93IGxldmVsIGZ1bmN0aW9ucwpoYW5kbGUgdGhlaXIgb3du IG1lc3NhZ2VzIHByZXR0eSB3ZWxsIGJ1dCBlc3BlY2lhbGx5IGttYWxsb2MoKSBkb2VzLgoKSSBh bHNvIGhhdmUgYSBzcGVjaWFsIHN0YXRpYyBjaGVja2VyIHdhcm5pbmcgZm9yIHdoZW4gcGVvcGxl IGRvOgoKCWZvbyA9IGFsbG9jKCk7CglCVUdfT04oIWZvbyk7CgpQZW9wbGUgZG8gdGhhdCBvY2Nh c2lvbmFsbHkgYnV0IGZvcnR1bmF0ZWx5IGl0J3MgcHJldHR5IHJhcmUuICAxMCB5ZWFycwphZ28g dGhhdCdzIGhvdyBidHJmcyBkaWQgZXJyb3IgaGFuZGxpbmcsIGJ1dCBub3cgdGhlcmUgYXJlIG9u bHkgNCBvZgp0aGVzZSBzdGlsbCByZW1haW5pbmcgaW4gYnRyZnMuCgpyZWdhcmRzLApkYW4gY2Fy cGVudGVyCi0tLQpUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAi dW5zdWJzY3JpYmUgbGludXgtdXNiIiBpbgp0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jk b21vQHZnZXIua2VybmVsLm9yZwpNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5r ZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwK