From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752524AbdLGV06 (ORCPT ); Thu, 7 Dec 2017 16:26:58 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:43760 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752325AbdLGV0t (ORCPT ); Thu, 7 Dec 2017 16:26:49 -0500 Date: Thu, 7 Dec 2017 16:26:48 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Dan Carpenter 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() In-Reply-To: <20171207204953.5gsk26pk4b5xaizq@mwanda> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Stern Date: Thu, 07 Dec 2017 21:26:48 +0000 Subject: Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer() Message-Id: 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: Dan Carpenter 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, 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 > > > 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: Alan Stern Message-Id: Date: Thu, 7 Dec 2017 16:26:48 -0500 (EST) To: Dan Carpenter 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: T24gVGh1LCA3IERlYyAyMDE3LCBEYW4gQ2FycGVudGVyIHdyb3RlOgoKPiBPbiBUaHUsIERlYyAw NywgMjAxNyBhdCAxMDoxMjoyN0FNIC0wNTAwLCBBbGFuIFN0ZXJuIHdyb3RlOgo+ID4gVGhlIHJl YWwgcHJvYmxlbSBpcyB0aGF0IHRoZSBrZXJuZWwgZGV2ZWxvcG1lbnQgY29tbXVuaXR5IGRvZXNu J3QgaGF2ZQo+ID4gYSBmaXhlZCBwb2xpY3kgb24gaG93IHRvIGhhbmRsZSBtZW1vcnkgYWxsb2Nh dGlvbiBlcnJvcnMuICBUaGVyZSBhcmUKPiA+IHNldmVyYWwgcG9zc2liaWxpdGllczoKPiA+IAo+ ID4gCUlnbm9yZSB0aGVtIG9uIHRoZSBncm91bmRzIHRoYXQgdGhleSB3aWxsIG5ldmVyIGhhcHBl bi4KPiA+IAkoUmVhbGx5PyAgQW5kIHdoYXQgaXMgdGhlIHNpemUgbGltaXQgYWJvdmUgd2hpY2gg dGhleQo+ID4gCW1pZ2h0IGhhcHBlbj8pCj4gPiAKPiAKPiBJdCdzIHByZXR0eSByYXJlIHRvIGln bm9yZSBhbGxvY2F0aW9uIGZhaWx1cmVzIHRoZXNlIGRheXMuICBJdCBjYXVzZXMKPiBzdGF0aWMg Y2hlY2tlciB3YXJuaW5ncy4KPiAKPiBTb21ldGltZXMgaXQncyBhY2NlcHRlZCBmb3IgcGVvcGxl IHRvIGlnbm9yZSBlcnJvcnMgZHVyaW5nIGJvb3QgYnV0Cj4gSSBoYXRlIHRoYXQgYmVjYXVzZSBo b3cgYW0gSSBzdXBwb3NlZCB0byBmaWx0ZXIgb3V0IHRob3NlIHN0YXRpYyBjaGVja2VyCj4gd2Fy bmluZ3M/ICBJdCdzIGJldHRlciB0byBwcmV0ZW5kIHRoYXQgdGhlIGtlcm5lbCB3aWxsIHN0aWxs IGJvb3QKPiB3aXRob3V0IGVzc2VudGlhbCBoYXJkd2FyZSBpbnN0ZWFkIG9mIHdhc3RpbmcgZXZl cnlvbmUncyB0aW1lIHdobyBsb29rcwo+IGF0IGNoZWNrZXIgb3V0cHV0Lgo+IAo+ID4gCUlnbm9y ZSB0aGVtIG9uIHRoZSBncm91bmRzIHRoYXQgdGhlIG1hY2hpbmUgd2lsbCBoYW5nIG9yCj4gPiAJ Y3Jhc2ggaW4gdGhlIG5lYXIgZnV0dXJlLiAgKElzIHRoaXMgZ3VhcmFudGVlZD8pCj4gCj4gT24g Ym9vdCBzb21ldGltZXMgeWVzLgo+IAo+ID4gCj4gPiAJVHJlYXQgdGhlbSBsaWtlIG90aGVyIGVy cm9yczogdHJ5IHRvIHByZXNzIGZvcndhcmQgKHBlcmhhcHMKPiA+IAlpbiBhIGRlZ3JhZGVkIG1v ZGUpLgo+ID4gCj4gPiAJVHJlYXQgdGhlbSBsaWtlIG90aGVyIGVycm9yczogbG9nIGFuIGVycm9y IG1lc3NhZ2UgYW5kIHRyeQo+ID4gCXRvIHByZXNzIGZvcndhcmQuCj4gPiAKPiAKPiBUaGUgc3Rh bmRhcmQgaXMgdG8gdHJlYXQgdGhlbSBsaWtlIGVycm9ycyBhbmQgdHJ5IHByZXNzIGZvcndhcmQg aW4gYQo+IGRlZ3JhZGVkIG1vZGUgYnV0IGRvbid0IHByaW50IGEgbWVzc2FnZS4gIENoZWNrcGF0 Y2gucGwgY29tcGxhaW5zIGlmIHlvdQo+IHByaW50IGEgd2FybmluZyBmb3IgYWxsb2NhdGlvbiBm YWlsdXJlcy4gIEEgbG90IG9mIGxvdyBsZXZlbCBmdW5jdGlvbnMKPiBoYW5kbGUgdGhlaXIgb3du IG1lc3NhZ2VzIHByZXR0eSB3ZWxsIGJ1dCBlc3BlY2lhbGx5IGttYWxsb2MoKSBkb2VzLgoKV2hp Y2ggYnJpbmdzIHVzIGJhY2sgdG8gbXkgb3JpZ2luYWwgb2JqZWN0aW9uLiAgSWYgYW4gYWxsb2Nh dGlvbiAKZmFpbHVyZSBoYXMgbG9jYWxpemVkIGVmZmVjdHMsIGJ1dCB0aGUgbG93LWxldmVsIHdh cm5pbmcgaXMgdW5hYmxlIHRvIApzcGVjaWZ5IHdoYXQgd2lsbCBiZSBhZmZlY3RlZCwgaG93IGlz IHRoZSB1c2VyIHN1cHBvc2VkIHRvIGNvbm5lY3QgdGhlIAplZmZlY3QgdG8gdGhlIGNhdXNlPwoK QWxhbiBTdGVybgoKPiAKPiBJIGFsc28gaGF2ZSBhIHNwZWNpYWwgc3RhdGljIGNoZWNrZXIgd2Fy bmluZyBmb3Igd2hlbiBwZW9wbGUgZG86Cj4gCj4gCWZvbyA9IGFsbG9jKCk7Cj4gCUJVR19PTigh Zm9vKTsKPiAKPiBQZW9wbGUgZG8gdGhhdCBvY2Nhc2lvbmFsbHkgYnV0IGZvcnR1bmF0ZWx5IGl0 J3MgcHJldHR5IHJhcmUuICAxMCB5ZWFycwo+IGFnbyB0aGF0J3MgaG93IGJ0cmZzIGRpZCBlcnJv ciBoYW5kbGluZywgYnV0IG5vdyB0aGVyZSBhcmUgb25seSA0IG9mCj4gdGhlc2Ugc3RpbGwgcmVt YWluaW5nIGluIGJ0cmZzLgo+IAo+IHJlZ2FyZHMsCj4gZGFuIGNhcnBlbnRlcgo+IAo+IAo+Ci0t LQpUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3Jp YmUgbGludXgtdXNiIiBpbgp0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIu a2VybmVsLm9yZwpNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3Jn L21ham9yZG9tby1pbmZvLmh0bWwK