From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754583AbdLGPMa (ORCPT ); Thu, 7 Dec 2017 10:12:30 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:54666 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753321AbdLGPM2 (ORCPT ); Thu, 7 Dec 2017 10:12:28 -0500 Date: Thu, 7 Dec 2017 10:12:27 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Geert Uytterhoeven cc: SF Markus Elfring , USB list , Joe Perches , Daniel Drake , Dmitry Fleytman , Eugene Korenevsky , Greg Kroah-Hartman , =?UTF-8?B?R8O8bnRlciBSw7Zjaw==?= , 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: 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, Geert Uytterhoeven wrote: > Hi Alan, > > On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern wrote: > > On Wed, 6 Dec 2017, SF Markus Elfring wrote: > >> >>> Does the existing memory allocation error message include the > >> >>> &udev->dev device name and driver name? If it doesn't, there will be > >> >>> no way for the user to tell that the error message is related to the > >> >>> device failure. > >> >> > >> >> No, but the effect is similar. > >> >> > >> >> OOM does a dump_stack() so this function's call tree is shown. > >> > > >> > A call stack doesn't tell you which device was being handled. > >> > >> Do you find a default Linux allocation failure report insufficient then? > >> > >> Would you like to to achieve that the requested information can be determined > >> from a backtrace? > > > > It is not practical to do this. The memory allocation routines do not > > for what purpose the memory is being allocated; hence when a failure > > occurs they cannot tell what device (or other part of the system) will > > be affected. > > If even allocation of 24 bytes fails, lots of other devices and other parts of > the system will start failing really soon... In fact, one wonders if the allocation routine's own error message and stack trace would actually appear anywhere... > > That's why we have a secondary error message. > > ... and the secondary error message would still be useless. Well, there is still a difference between GFP_ATOMIC and GFP_KERNEL allocations. Failure of the first doesn't necessarily imply failure of the second, so perhaps the system could recover. 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?) Ignore them on the grounds that the machine will hang or crash in the near future. (Is this guaranteed?) 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. And probably a few more that haven't occurred to me. No doubt there are examples of each at various places in the kernel. Nobody seems able to agree on a single course of action. Maybe not even Linus. If there was one agreed-upon policy, then we could definitively point to old code and say "That's wrong, and here is how it should be fixed." But currently this is not possible, and we end up with repetitive discussions like this one that aren't of general use. Alan Stern From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Stern Date: Thu, 07 Dec 2017 15:12:27 +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: Geert Uytterhoeven Cc: SF Markus Elfring , USB list , Joe Perches , Daniel Drake , Dmitry Fleytman , Eugene Korenevsky , Greg Kroah-Hartman , =?UTF-8?B?R8O8bnRlciBSw7Zjaw==?= , Johan Hovold , Mathias Nyman , Peter Chen , LKML , "kernel-janitors@vger.kernel.org" On Thu, 7 Dec 2017, Geert Uytterhoeven wrote: > Hi Alan, > > On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern wrote: > > On Wed, 6 Dec 2017, SF Markus Elfring wrote: > >> >>> Does the existing memory allocation error message include the > >> >>> &udev->dev device name and driver name? If it doesn't, there will be > >> >>> no way for the user to tell that the error message is related to the > >> >>> device failure. > >> >> > >> >> No, but the effect is similar. > >> >> > >> >> OOM does a dump_stack() so this function's call tree is shown. > >> > > >> > A call stack doesn't tell you which device was being handled. > >> > >> Do you find a default Linux allocation failure report insufficient then? > >> > >> Would you like to to achieve that the requested information can be determined > >> from a backtrace? > > > > It is not practical to do this. The memory allocation routines do not > > for what purpose the memory is being allocated; hence when a failure > > occurs they cannot tell what device (or other part of the system) will > > be affected. > > If even allocation of 24 bytes fails, lots of other devices and other parts of > the system will start failing really soon... In fact, one wonders if the allocation routine's own error message and stack trace would actually appear anywhere... > > That's why we have a secondary error message. > > ... and the secondary error message would still be useless. Well, there is still a difference between GFP_ATOMIC and GFP_KERNEL allocations. Failure of the first doesn't necessarily imply failure of the second, so perhaps the system could recover. 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?) Ignore them on the grounds that the machine will hang or crash in the near future. (Is this guaranteed?) 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. And probably a few more that haven't occurred to me. No doubt there are examples of each at various places in the kernel. Nobody seems able to agree on a single course of action. Maybe not even Linus. If there was one agreed-upon policy, then we could definitively point to old code and say "That's wrong, and here is how it should be fixed." But currently this is not possible, and we end up with repetitive discussions like this one that aren't of general use. Alan Stern 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 10:12:27 -0500 (EST) To: Geert Uytterhoeven Cc: SF Markus Elfring , USB list , Joe Perches , Daniel Drake , Dmitry Fleytman , Eugene Korenevsky , Greg Kroah-Hartman , =?UTF-8?B?R8O8bnRlciBSw7Zjaw==?= , Johan Hovold , Mathias Nyman , Peter Chen , LKML , "kernel-janitors@vger.kernel.org" List-ID: T24gVGh1LCA3IERlYyAyMDE3LCBHZWVydCBVeXR0ZXJob2V2ZW4gd3JvdGU6Cgo+IEhpIEFsYW4s Cj4gCj4gT24gV2VkLCBEZWMgNiwgMjAxNyBhdCAxMTowMiBQTSwgQWxhbiBTdGVybiA8c3Rlcm5A cm93bGFuZC5oYXJ2YXJkLmVkdT4gd3JvdGU6Cj4gPiBPbiBXZWQsIDYgRGVjIDIwMTcsIFNGIE1h cmt1cyBFbGZyaW5nIHdyb3RlOgo+ID4+ID4+PiBEb2VzIHRoZSBleGlzdGluZyBtZW1vcnkgYWxs b2NhdGlvbiBlcnJvciBtZXNzYWdlIGluY2x1ZGUgdGhlCj4gPj4gPj4+ICZ1ZGV2LT5kZXYgZGV2 aWNlIG5hbWUgYW5kIGRyaXZlciBuYW1lPyAgSWYgaXQgZG9lc24ndCwgdGhlcmUgd2lsbCBiZQo+ ID4+ID4+PiBubyB3YXkgZm9yIHRoZSB1c2VyIHRvIHRlbGwgdGhhdCB0aGUgZXJyb3IgbWVzc2Fn ZSBpcyByZWxhdGVkIHRvIHRoZQo+ID4+ID4+PiBkZXZpY2UgZmFpbHVyZS4KPiA+PiA+Pgo+ID4+ ID4+IE5vLCBidXQgdGhlIGVmZmVjdCBpcyBzaW1pbGFyLgo+ID4+ID4+Cj4gPj4gPj4gT09NIGRv ZXMgYSBkdW1wX3N0YWNrKCkgc28gdGhpcyBmdW5jdGlvbidzIGNhbGwgdHJlZSBpcyBzaG93bi4K PiA+PiA+Cj4gPj4gPiBBIGNhbGwgc3RhY2sgZG9lc24ndCB0ZWxsIHlvdSB3aGljaCBkZXZpY2Ug d2FzIGJlaW5nIGhhbmRsZWQuCj4gPj4KPiA+PiBEbyB5b3UgZmluZCBhIGRlZmF1bHQgTGludXgg YWxsb2NhdGlvbiBmYWlsdXJlIHJlcG9ydCBpbnN1ZmZpY2llbnQgdGhlbj8KPiA+Pgo+ID4+IFdv dWxkIHlvdSBsaWtlIHRvIHRvIGFjaGlldmUgdGhhdCB0aGUgcmVxdWVzdGVkIGluZm9ybWF0aW9u IGNhbiBiZSBkZXRlcm1pbmVkCj4gPj4gZnJvbSBhIGJhY2t0cmFjZT8KPiA+Cj4gPiBJdCBpcyBu b3QgcHJhY3RpY2FsIHRvIGRvIHRoaXMuICBUaGUgbWVtb3J5IGFsbG9jYXRpb24gcm91dGluZXMg ZG8gbm90Cj4gPiBmb3Igd2hhdCBwdXJwb3NlIHRoZSBtZW1vcnkgaXMgYmVpbmcgYWxsb2NhdGVk OyBoZW5jZSB3aGVuIGEgZmFpbHVyZQo+ID4gb2NjdXJzIHRoZXkgY2Fubm90IHRlbGwgd2hhdCBk ZXZpY2UgKG9yIG90aGVyIHBhcnQgb2YgdGhlIHN5c3RlbSkgd2lsbAo+ID4gYmUgYWZmZWN0ZWQu Cj4gCj4gSWYgZXZlbiBhbGxvY2F0aW9uIG9mIDI0IGJ5dGVzIGZhaWxzLCBsb3RzIG9mIG90aGVy IGRldmljZXMgYW5kIG90aGVyIHBhcnRzIG9mCj4gdGhlIHN5c3RlbSB3aWxsIHN0YXJ0IGZhaWxp bmcgcmVhbGx5IHNvb24uLi4KCkluIGZhY3QsIG9uZSB3b25kZXJzIGlmIHRoZSBhbGxvY2F0aW9u IHJvdXRpbmUncyBvd24gZXJyb3IgbWVzc2FnZSBhbmQKc3RhY2sgdHJhY2Ugd291bGQgYWN0dWFs bHkgYXBwZWFyIGFueXdoZXJlLi4uCgo+ID4gVGhhdCdzIHdoeSB3ZSBoYXZlIGEgc2Vjb25kYXJ5 IGVycm9yIG1lc3NhZ2UuCj4gCj4gLi4uIGFuZCB0aGUgc2Vjb25kYXJ5IGVycm9yIG1lc3NhZ2Ug d291bGQgc3RpbGwgYmUgdXNlbGVzcy4KCldlbGwsIHRoZXJlIGlzIHN0aWxsIGEgZGlmZmVyZW5j ZSBiZXR3ZWVuIEdGUF9BVE9NSUMgYW5kIEdGUF9LRVJORUwgCmFsbG9jYXRpb25zLiAgRmFpbHVy ZSBvZiB0aGUgZmlyc3QgZG9lc24ndCBuZWNlc3NhcmlseSBpbXBseSBmYWlsdXJlIG9mIAp0aGUg c2Vjb25kLCBzbyBwZXJoYXBzIHRoZSBzeXN0ZW0gY291bGQgcmVjb3Zlci4KClRoZSByZWFsIHBy b2JsZW0gaXMgdGhhdCB0aGUga2VybmVsIGRldmVsb3BtZW50IGNvbW11bml0eSBkb2Vzbid0IGhh dmUKYSBmaXhlZCBwb2xpY3kgb24gaG93IHRvIGhhbmRsZSBtZW1vcnkgYWxsb2NhdGlvbiBlcnJv cnMuICBUaGVyZSBhcmUKc2V2ZXJhbCBwb3NzaWJpbGl0aWVzOgoKCUlnbm9yZSB0aGVtIG9uIHRo ZSBncm91bmRzIHRoYXQgdGhleSB3aWxsIG5ldmVyIGhhcHBlbi4KCShSZWFsbHk/ICBBbmQgd2hh dCBpcyB0aGUgc2l6ZSBsaW1pdCBhYm92ZSB3aGljaCB0aGV5CgltaWdodCBoYXBwZW4/KQoKCUln bm9yZSB0aGVtIG9uIHRoZSBncm91bmRzIHRoYXQgdGhlIG1hY2hpbmUgd2lsbCBoYW5nIG9yCglj cmFzaCBpbiB0aGUgbmVhciBmdXR1cmUuICAoSXMgdGhpcyBndWFyYW50ZWVkPykKCglUcmVhdCB0 aGVtIGxpa2Ugb3RoZXIgZXJyb3JzOiB0cnkgdG8gcHJlc3MgZm9yd2FyZCAocGVyaGFwcwoJaW4g YSBkZWdyYWRlZCBtb2RlKS4KCglUcmVhdCB0aGVtIGxpa2Ugb3RoZXIgZXJyb3JzOiBsb2cgYW4g ZXJyb3IgbWVzc2FnZSBhbmQgdHJ5Cgl0byBwcmVzcyBmb3J3YXJkLgoKQW5kIHByb2JhYmx5IGEg ZmV3IG1vcmUgdGhhdCBoYXZlbid0IG9jY3VycmVkIHRvIG1lLiAgTm8gZG91YnQgdGhlcmUgCmFy ZSBleGFtcGxlcyBvZiBlYWNoIGF0IHZhcmlvdXMgcGxhY2VzIGluIHRoZSBrZXJuZWwuICBOb2Jv ZHkgc2VlbXMKYWJsZSB0byBhZ3JlZSBvbiBhIHNpbmdsZSBjb3Vyc2Ugb2YgYWN0aW9uLiAgTWF5 YmUgbm90IGV2ZW4gTGludXMuCgpJZiB0aGVyZSB3YXMgb25lIGFncmVlZC11cG9uIHBvbGljeSwg dGhlbiB3ZSBjb3VsZCBkZWZpbml0aXZlbHkgcG9pbnQgCnRvIG9sZCBjb2RlIGFuZCBzYXkgIlRo YXQncyB3cm9uZywgYW5kIGhlcmUgaXMgaG93IGl0IHNob3VsZCBiZSBmaXhlZC4iICAKQnV0IGN1 cnJlbnRseSB0aGlzIGlzIG5vdCBwb3NzaWJsZSwgYW5kIHdlIGVuZCB1cCB3aXRoIHJlcGV0aXRp dmUgCmRpc2N1c3Npb25zIGxpa2UgdGhpcyBvbmUgdGhhdCBhcmVuJ3Qgb2YgZ2VuZXJhbCB1c2Uu CgpBbGFuIFN0ZXJuCi0tLQpUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUg bGluZSAidW5zdWJzY3JpYmUgbGludXgtdXNiIiBpbgp0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8g bWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZwpNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8v dmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwK