Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752312AbdLFWCm (ORCPT ); Wed, 6 Dec 2017 17:02:42 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:58290 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752018AbdLFWCl (ORCPT ); Wed, 6 Dec 2017 17:02:41 -0500 Date: Wed, 6 Dec 2017 17:02:40 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: SF Markus Elfring cc: linux-usb@vger.kernel.org, Joe Perches , Daniel Drake , Dmitry Fleytman , Eugene Korenevsky , Geert Uytterhoeven , Greg Kroah-Hartman , =?UTF-8?B?R8O8bnRlciBSw7Zjaw==?= , Johan Hovold , Mathias Nyman , Peter Chen , LKML , 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 Content-Length: 943 Lines: 26 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. That's why we have a secondary error message. Alan Stern