From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752082AbdJSKmk (ORCPT <rfc822;w@1wt.eu>);
        Thu, 19 Oct 2017 06:42:40 -0400
Received: from mout.web.de ([212.227.17.12]:61453 "EHLO mout.web.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751311AbdJSKmi (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 19 Oct 2017 06:42:38 -0400
Subject: Re: kernel/module: Delete an error message for a failed memory
 allocation in add_module_usage()
To: Jessica Yu <jeyu@kernel.org>, kernel-janitors@vger.kernel.org
Cc: Rusty Russell <rusty@rustcorp.com.au>,
        LKML <linux-kernel@vger.kernel.org>
References: <a47bc166-7592-2ff8-9b94-4d45e18b6004@users.sourceforge.net>
 <20171019092943.hbghcaifwkcdsgd3@redbean>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Message-ID: <b4f1f555-4e54-8258-cd0c-764c6b314fee@users.sourceforge.net>
Date: Thu, 19 Oct 2017 12:42:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171019092943.hbghcaifwkcdsgd3@redbean>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:ReM59Lkek/Ou754cTfiCVv3goAYBOdimm6mGP7n/1UWF5vtL5JV
 xIJcc614EE+rC6AooZuTAYXYDSP3Y5b6iHA/eCPrFr7s1l+P4hTFUqRiXaOkwYNJK1YFex5
 ME3Cjj40yV1FP18RARG7PjMiu6SXDMoBKg7U8otjT2YeUspyjCQ15s9XJ6MijKcZKb7tnb5
 2dwkRLPv7J0e8NRYTGgtQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:HXe34RpypXc=:XeW/i1gNXGFKlBLMF1Mwxq
 /m7g5Qz7QyOXYygoQk6cUYmjqXAxgkVB1JfNsRDggDPVS9MV0R+CrE08TIvSEpuMnIJUvIbNf
 Jc53FtifovjbxNauPKuWH///iwjZiKQFNxIGbOnioL6PxMttwfN7r5olDc9mBKJryH3JIu4+u
 j9Lua/zWkI7f0VlOEev4QD8mPwhqiHLZRn1jyIPpG1V+KUQodMI0T1surDlL24pXF5zXdSPRH
 bOG6MBOOMK57bpRFJyugk0aTd01BijypjKiyc34EEi/no3krss3WVJ3hsyl/f0iVl/dZJ6xiP
 OeOKKvYhBCBsHZECmw87nlJgE4R9AxpWEj9Uuj0T4SurdWhmw9h+BB71yKU8f5wVqgViTwH7g
 Fmp2iGs8LrScOy/ummPKtcstvnM4HjAKom7Oq0+wRqbeZJdtYp14bCP290kuBLlBgVXgkH2bL
 SbE8+wGApI5ewOst+TdrBmGoEuLzdWD/t/5USLVcCWU7mffK9zLh3EpUm7XgVVMVHVC2CZm9a
 2G24scCnzO535CjQUe1vWvFMvBtOymWGn+jQLt1cQMLyWDkMPbcLNOsZVsS7T4sOu2gn7z4mU
 yQ++m7x4+AoQAcxzIeVZKAkPEhz5h0ie6nUwLDO8fWoGQ4uoypFIZX1VJizclL/DBhRJqYXXg
 7yEYHo0uBO7kLFDuM4XEDXOaIS1gT7ZCAVCpie8tG83L6SgOmhqGW2Lz3uhc1lRNTqGdNePv0
 Iy7CuuMdUky8Ar3VsnTlVvEjCZcHj/HdiL3Ii3U4bm/Qj3P7giOdZvjvvsedrcfv4csZ5hGcg
 KChXQEaQVQbqbaw4yRJmMKjILr31nVMup8+crAAqPl4xBt3+3k=
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>> @@ -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.

How do you think about to clarify the circumstances any further?


> Although stack traces are generated on alloc failures,

Do you ever want to switch them off for special use cases?


> the extra print also tells us which module we were trying to load
> at the time the memory allocation failed.

Can a default allocation failure report provide the same information already?

Regards,
Markus