From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752478AbdJSKbA (ORCPT ); Thu, 19 Oct 2017 06:31:00 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:50229 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751426AbdJSKa6 (ORCPT ); Thu, 19 Oct 2017 06:30:58 -0400 Date: Thu, 19 Oct 2017 13:30:34 +0300 From: Dan Carpenter To: Jessica Yu Cc: SF Markus Elfring , kernel-janitors@vger.kernel.org, Rusty Russell , LKML Subject: Re: kernel/module: Delete an error message for a failed memory allocation in add_module_usage() Message-ID: <20171019103034.kw6lthwq22vafqjx@mwanda> References: <20171019092943.hbghcaifwkcdsgd3@redbean> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171019092943.hbghcaifwkcdsgd3@redbean> User-Agent: NeoMutt/20170113 (1.7.2) X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 19, 2017 at 11:29:43AM +0200, Jessica Yu wrote: > +++ SF Markus Elfring [06/10/17 17:12 +0200]: > > From: Markus Elfring > > Date: Fri, 6 Oct 2017 16:27:26 +0200 > > > > 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 > > --- > > kernel/module.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/kernel/module.c b/kernel/module.c > > index de66ec825992..07ef44767245 100644 > > --- a/kernel/module.c > > +++ b/kernel/module.c > > @@ -837,10 +837,8 @@ static int add_module_usage(struct module *a, struct module *b) > > > > pr_debug("Allocating new usage for %s.\n", a->name); > > use = kmalloc(sizeof(*use), GFP_ATOMIC); > > - if (!use) { > > - pr_warn("%s: out of memory loading\n", a->name); > > + if (!use) > > return -ENOMEM; > > - } > > IMO this is removing useful information. Although stack traces are > generated on alloc failures, the extra print also tells us which > module we were trying to load at the time the memory allocation > failed. This is a small allocation so it can't fail in current kernels. I can't imagine a situation where this could fail and it wasn't dead easy to debug. Most modules are loaded at boot so it's not likely to fail, but if it did, it would be easy to reproduce. If it's not loaded at boot it's probably really easy to tell which module we're loading. regards, dan carpenter