Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752691AbdLHHnk (ORCPT ); Fri, 8 Dec 2017 02:43:40 -0500 Received: from mail-qt0-f196.google.com ([209.85.216.196]:32869 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752010AbdLHHnj (ORCPT ); Fri, 8 Dec 2017 02:43:39 -0500 X-Google-Smtp-Source: AGs4zMZDezOuavDs7I/ThdFiokFW//CUNHoTJU9R6xrK0ZT5oh0L6pe8vazj2q/goGZBLjDdxFhS+Y6b7yJn2jio7C4= MIME-Version: 1.0 In-Reply-To: References: <20171207204953.5gsk26pk4b5xaizq@mwanda> From: Geert Uytterhoeven Date: Fri, 8 Dec 2017 08:43:37 +0100 X-Google-Sender-Auth: 0GK4bTigwp9wJD4rq8Xspa71TZA 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: Dan Carpenter , 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: 1648 Lines: 43 Hi Alan, On Thu, Dec 7, 2017 at 10:26 PM, Alan Stern wrote: > On Thu, 7 Dec 2017, Dan Carpenter wrote: >> The standard is to treat them like errors and try press forward in a >> degraded mode but don't print a message. Checkpatch.pl complains if you >> print a warning for allocation failures. A lot of low level functions >> handle their own messages pretty well but especially kmalloc() does. > > Which brings us back to my original objection. If an allocation > failure has localized effects, but the low-level warning is unable to > specify what will be affected, how is the user supposed to connect the > effect to the cause? The backtrace would include usb_hub_clear_tt_buffer, so the user will know USB is affected. Note that the cause of the memory exhaustion is usually not the caller. Unless it requests a real big block of memory, in which case that will be mentioned in the backtrace, too. In this particular case, the driver uses GFP_ATOMIC, so allocation failures aren't that rare, and I think the driver should be prepared for that, and try to recover gracefully. The comment /* FIXME recover somehow ... RESET_TT? */ makes me think it isn't. As this is a pretty small allocation, perhaps it can be done beforehand, without GFP_ATOMIC? 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