From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752528AbdLGIpn (ORCPT ); Thu, 7 Dec 2017 03:45:43 -0500 Received: from mail-qt0-f194.google.com ([209.85.216.194]:46120 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbdLGIpj (ORCPT ); Thu, 7 Dec 2017 03:45:39 -0500 X-Google-Smtp-Source: AGs4zMYVtHznkLaPWAAW7B3HktpxPIxYayAETBgF2unvCPvcRgf3TGYlaglowgXxEkh8em2tP9p2RxwiN6ywaT9UKOk= MIME-Version: 1.0 In-Reply-To: <20171207083542.gohu4z3v4fp7gvsu@mwanda> References: <20171207083542.gohu4z3v4fp7gvsu@mwanda> From: Geert Uytterhoeven Date: Thu, 7 Dec 2017 09:45:38 +0100 X-Google-Sender-Auth: yV79PlHwOzoAJgLG07mfGhc7DDw Message-ID: Subject: Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer() To: Dan Carpenter Cc: Alan Stern , 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" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dan, On Thu, Dec 7, 2017 at 9:35 AM, Dan Carpenter wrote: > On Thu, Dec 07, 2017 at 08:40:07AM +0100, Geert Uytterhoeven wrote: >> 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... > > Small allocations never fail in the current kernel. A few comments (this is in response to a patch from Markus, so there have to be lots of questions and uncertainties ;-) 1. In the current kernel. What about the future? 2. If a small allocation cannot fail, what happens if the small memory slab is exhausted? A new page must be allocated, which will trigger an OOM, and some other part of the system will be killed and fail. 3. This driver uses GFP_ATOMIC, is that guaranteed to succeed? I think not. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Date: Thu, 07 Dec 2017 08:45:38 +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: Alan Stern , 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" Hi Dan, On Thu, Dec 7, 2017 at 9:35 AM, Dan Carpenter wrote: > On Thu, Dec 07, 2017 at 08:40:07AM +0100, Geert Uytterhoeven wrote: >> 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... > > Small allocations never fail in the current kernel. A few comments (this is in response to a patch from Markus, so there have to be lots of questions and uncertainties ;-) 1. In the current kernel. What about the future? 2. If a small allocation cannot fail, what happens if the small memory slab is exhausted? A new page must be allocated, which will trigger an OOM, and some other part of the system will be killed and fail. 3. This driver uses GFP_ATOMIC, is that guaranteed to succeed? I think not. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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: Geert Uytterhoeven Message-Id: Date: Thu, 7 Dec 2017 09:45:38 +0100 To: Dan Carpenter Cc: Alan Stern , 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: SGkgRGFuLAoKT24gVGh1LCBEZWMgNywgMjAxNyBhdCA5OjM1IEFNLCBEYW4gQ2FycGVudGVyIDxk YW4uY2FycGVudGVyQG9yYWNsZS5jb20+IHdyb3RlOgo+IE9uIFRodSwgRGVjIDA3LCAyMDE3IGF0 IDA4OjQwOjA3QU0gKzAxMDAsIEdlZXJ0IFV5dHRlcmhvZXZlbiB3cm90ZToKPj4gT24gV2VkLCBE ZWMgNiwgMjAxNyBhdCAxMTowMiBQTSwgQWxhbiBTdGVybiA8c3Rlcm5Acm93bGFuZC5oYXJ2YXJk LmVkdT4gd3JvdGU6Cj4+ID4gT24gV2VkLCA2IERlYyAyMDE3LCBTRiBNYXJrdXMgRWxmcmluZyB3 cm90ZToKPj4gPj4gPj4+IERvZXMgdGhlIGV4aXN0aW5nIG1lbW9yeSBhbGxvY2F0aW9uIGVycm9y IG1lc3NhZ2UgaW5jbHVkZSB0aGUKPj4gPj4gPj4+ICZ1ZGV2LT5kZXYgZGV2aWNlIG5hbWUgYW5k IGRyaXZlciBuYW1lPyAgSWYgaXQgZG9lc24ndCwgdGhlcmUgd2lsbCBiZQo+PiA+PiA+Pj4gbm8g d2F5IGZvciB0aGUgdXNlciB0byB0ZWxsIHRoYXQgdGhlIGVycm9yIG1lc3NhZ2UgaXMgcmVsYXRl ZCB0byB0aGUKPj4gPj4gPj4+IGRldmljZSBmYWlsdXJlLgo+PiA+PiA+Pgo+PiA+PiA+PiBObywg YnV0IHRoZSBlZmZlY3QgaXMgc2ltaWxhci4KPj4gPj4gPj4KPj4gPj4gPj4gT09NIGRvZXMgYSBk dW1wX3N0YWNrKCkgc28gdGhpcyBmdW5jdGlvbidzIGNhbGwgdHJlZSBpcyBzaG93bi4KPj4gPj4g Pgo+PiA+PiA+IEEgY2FsbCBzdGFjayBkb2Vzbid0IHRlbGwgeW91IHdoaWNoIGRldmljZSB3YXMg YmVpbmcgaGFuZGxlZC4KPj4gPj4KPj4gPj4gRG8geW91IGZpbmQgYSBkZWZhdWx0IExpbnV4IGFs bG9jYXRpb24gZmFpbHVyZSByZXBvcnQgaW5zdWZmaWNpZW50IHRoZW4/Cj4+ID4+Cj4+ID4+IFdv dWxkIHlvdSBsaWtlIHRvIHRvIGFjaGlldmUgdGhhdCB0aGUgcmVxdWVzdGVkIGluZm9ybWF0aW9u IGNhbiBiZSBkZXRlcm1pbmVkCj4+ID4+IGZyb20gYSBiYWNrdHJhY2U/Cj4+ID4KPj4gPiBJdCBp cyBub3QgcHJhY3RpY2FsIHRvIGRvIHRoaXMuICBUaGUgbWVtb3J5IGFsbG9jYXRpb24gcm91dGlu ZXMgZG8gbm90Cj4+ID4gZm9yIHdoYXQgcHVycG9zZSB0aGUgbWVtb3J5IGlzIGJlaW5nIGFsbG9j YXRlZDsgaGVuY2Ugd2hlbiBhIGZhaWx1cmUKPj4gPiBvY2N1cnMgdGhleSBjYW5ub3QgdGVsbCB3 aGF0IGRldmljZSAob3Igb3RoZXIgcGFydCBvZiB0aGUgc3lzdGVtKSB3aWxsCj4+ID4gYmUgYWZm ZWN0ZWQuCj4+Cj4+IElmIGV2ZW4gYWxsb2NhdGlvbiBvZiAyNCBieXRlcyBmYWlscywgbG90cyBv ZiBvdGhlciBkZXZpY2VzIGFuZCBvdGhlciBwYXJ0cyBvZgo+PiB0aGUgc3lzdGVtIHdpbGwgc3Rh cnQgZmFpbGluZyByZWFsbHkgc29vbi4uLgo+Cj4gU21hbGwgYWxsb2NhdGlvbnMgbmV2ZXIgZmFp bCBpbiB0aGUgY3VycmVudCBrZXJuZWwuCgpBIGZldyBjb21tZW50cyAodGhpcyBpcyBpbiByZXNw b25zZSB0byBhIHBhdGNoIGZyb20gTWFya3VzLCBzbyB0aGVyZSBoYXZlCnRvIGJlIGxvdHMgb2Yg cXVlc3Rpb25zIGFuZCB1bmNlcnRhaW50aWVzIDstKQoxLiBJbiB0aGUgY3VycmVudCBrZXJuZWwu IFdoYXQgYWJvdXQgdGhlIGZ1dHVyZT8KMi4gSWYgYSBzbWFsbCBhbGxvY2F0aW9uIGNhbm5vdCBm YWlsLCB3aGF0IGhhcHBlbnMgaWYgdGhlIHNtYWxsIG1lbW9yeSBzbGFiCiAgIGlzIGV4aGF1c3Rl ZD8gQSBuZXcgcGFnZSBtdXN0IGJlIGFsbG9jYXRlZCwgd2hpY2ggd2lsbCB0cmlnZ2VyIGFuIE9P TSwKICAgYW5kIHNvbWUgb3RoZXIgcGFydCBvZiB0aGUgc3lzdGVtIHdpbGwgYmUga2lsbGVkIGFu ZCBmYWlsLgozLiBUaGlzIGRyaXZlciB1c2VzIEdGUF9BVE9NSUMsIGlzIHRoYXQgZ3VhcmFudGVl ZCB0byBzdWNjZWVkPyBJIHRoaW5rIG5vdC4KCkdye29ldGplLGVldGluZ31zLAoKICAgICAgICAg ICAgICAgICAgICAgICAgR2VlcnQKLS0tCkdlZXJ0IFV5dHRlcmhvZXZlbiAtLSBUaGVyZSdzIGxv dHMgb2YgTGludXggYmV5b25kIGlhMzIgLS0gZ2VlcnRAbGludXgtbTY4ay5vcmcKCkluIHBlcnNv bmFsIGNvbnZlcnNhdGlvbnMgd2l0aCB0ZWNobmljYWwgcGVvcGxlLCBJIGNhbGwgbXlzZWxmIGEg aGFja2VyLiBCdXQKd2hlbiBJJ20gdGFsa2luZyB0byBqb3VybmFsaXN0cyBJIGp1c3Qgc2F5ICJw cm9ncmFtbWVyIiBvciBzb21ldGhpbmcgbGlrZSB0aGF0LgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIExpbnVzIFRvcnZhbGRzCi0tClRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBs aXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC11c2IiIGluCnRoZSBib2R5IG9m IGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnCk1vcmUgbWFqb3Jkb21vIGlu Zm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbAo=