Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751014AbdLGHkK (ORCPT ); Thu, 7 Dec 2017 02:40:10 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:43726 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750879AbdLGHkI (ORCPT ); Thu, 7 Dec 2017 02:40:08 -0500 X-Google-Smtp-Source: AGs4zMbFVB0XLp9dk2Po3ZCDxUFlAQZGSf4+cFBlqFzUzOvcjqNYtunU4Y3sTbvkHY29f+u4fBhB+Zrgf5GaHhaLgR8= MIME-Version: 1.0 In-Reply-To: References: From: Geert Uytterhoeven Date: Thu, 7 Dec 2017 08:40:07 +0100 X-Google-Sender-Auth: NlQ__0gHTdUKP2dcvFw3Lj2ESd8 Message-ID: Subject: Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer() To: Alan Stern 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" 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: 1567 Lines: 42 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... > That's why we have a secondary error message. ... and the secondary error message would still be useless. 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