Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752531AbdLFR1b (ORCPT ); Wed, 6 Dec 2017 12:27:31 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:39493 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752472AbdLFR1Z (ORCPT ); Wed, 6 Dec 2017 12:27:25 -0500 X-Google-Smtp-Source: AGs4zMYqhbmBj/hCaI82zK/+//oBJ+RWV/zfluNIdTWAMxO1OdBl8FOVuI72PPRNo0F7f4gi1zsPeX2qsJEq8WHOCtM= MIME-Version: 1.0 In-Reply-To: References: <659939f3-da51-0cfd-2eb2-8a726cb1a42f@users.sourceforge.net> From: Geert Uytterhoeven Date: Wed, 6 Dec 2017 18:27:23 +0100 X-Google-Sender-Auth: WreUZt07-kQXihAXV8qlCiv8eNA Message-ID: Subject: Re: [PATCH] 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 , 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: 1782 Lines: 49 Hi Alan, On Wed, Dec 6, 2017 at 5:45 PM, Alan Stern wrote: > On Wed, 6 Dec 2017, SF Markus Elfring wrote: > >> From: Markus Elfring >> Date: Wed, 6 Dec 2017 17:00:18 +0100 >> >> Omit an extra message for a memory allocation failure in this function. >> >> This issue was detected by using the Coccinelle software. >> >> Signed-off-by: Markus Elfring >> --- >> drivers/usb/core/hub.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c >> index 7ccdd3d4db84..9fbb908e9552 100644 >> --- a/drivers/usb/core/hub.c >> +++ b/drivers/usb/core/hub.c >> @@ -829,7 +829,6 @@ int usb_hub_clear_tt_buffer(struct urb *urb) >> */ >> clear = kmalloc(sizeof *clear, GFP_ATOMIC); >> if (clear == NULL) { >> - dev_err(&udev->dev, "can't save CLEAR_TT_BUFFER state\n"); >> /* FIXME recover somehow ... RESET_TT? */ >> return -ENOMEM; >> } > > 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. The system will come to a grinding halt anyway if it can't allocate 24 or 40 bytes. Which is BTW more or less the amount of memory saved by killing the useless (error) message. 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