Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1750993AbdLGIhW (ORCPT <rfc822;w@1wt.eu>);
        Thu, 7 Dec 2017 03:37:22 -0500
Received: from userp2120.oracle.com ([156.151.31.85]:57778 "EHLO
        userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750895AbdLGIhU (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 7 Dec 2017 03:37:20 -0500
Date: Thu, 7 Dec 2017 11:35:42 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
        SF Markus Elfring <elfring@users.sourceforge.net>,
        USB list <linux-usb@vger.kernel.org>, Joe Perches <joe@perches.com>,
        Daniel Drake <drake@endlessm.com>, Dmitry Fleytman <dmitry@daynix.com>,
        Eugene Korenevsky <ekorenevsky@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        =?iso-8859-1?Q?G=FCnter_R=F6ck?= <linux@roeck-us.net>,
        Johan Hovold <johan@kernel.org>,
        Mathias Nyman <mathias.nyman@linux.intel.com>,
        Peter Chen <peter.chen@nxp.com>, LKML <linux-kernel@vger.kernel.org>,
        "kernel-janitors@vger.kernel.org" <kernel-janitors@vger.kernel.org>
Subject: Re: USB: hub: Delete an error message for a failed memory allocation
 in usb_hub_clear_tt_buffer()
Message-ID: <20171207083542.gohu4z3v4fp7gvsu@mwanda>
References: <a823c472-7826-3fbd-0197-5246a2cd5368@users.sourceforge.net>
 <Pine.LNX.4.44L0.1712061700550.1507-100000@iolanthe.rowland.org>
 <CAMuHMdWAzqvh_=UEiYtCdFYvcwoRVLvO9rq8MqwCqjgSz-fm7g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMuHMdWAzqvh_=UEiYtCdFYvcwoRVLvO9rq8MqwCqjgSz-fm7g@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8737 signatures=668643
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0
 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
 adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000
 definitions=main-1712070131
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1316
Lines: 34

On Thu, Dec 07, 2017 at 08:40:07AM +0100, Geert Uytterhoeven wrote:
> Hi Alan,
> 
> On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern <stern@rowland.harvard.edu> 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.

regards,
dan carpenter