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 Content-Length: 2194 Lines: 50 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