[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a823c472-7826-3fbd-0197-5246a2cd5368@users.sourceforge.net>
Date: Wed, 6 Dec 2017 22:33:26 +0100
From: SF Markus Elfring <elfring@...rs.sourceforge.net>
To: Alan Stern <stern@...land.harvard.edu>, linux-usb@...r.kernel.org
Cc: Joe Perches <joe@...ches.com>, Daniel Drake <drake@...lessm.com>,
Dmitry Fleytman <dmitry@...nix.com>,
Eugene Korenevsky <ekorenevsky@...il.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Günter Röck <linux@...ck-us.net>,
Johan Hovold <johan@...nel.org>,
Mathias Nyman <mathias.nyman@...ux.intel.com>,
Peter Chen <peter.chen@....com>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org
Subject: Re: USB: hub: Delete an error message for a failed memory allocation
in usb_hub_clear_tt_buffer()
>>> 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?
Regards,
Markus
Powered by blists - more mailing lists