linux-kernel - Re: [PATCH -next] drivers/base/node.c: make CACHE_ATTR define static DEVICE_ATTR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <017d9fae-328f-e93f-095e-bdfa0cc2f2ff@huawei.com>
Date:   Thu, 13 May 2021 21:22:44 +0800
From:   Gong Ruiqi <gongruiqi1@...wei.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Wang Weiyang <wangweiyang2@...wei.com>,
        <linux-kernel@...r.kernel.org>, <kernel-janitors@...r.kernel.org>
Subject: Re: [PATCH -next] drivers/base/node.c: make CACHE_ATTR define static
 DEVICE_ATTR_RO



On 2021/05/13 19:26, Greg Kroah-Hartman wrote:
> On Thu, May 13, 2021 at 07:07:16PM +0800, Ruiqi Gong wrote:
>> The Sparse tool reports as follows:
>>
>> drivers/base/node.c:239:1: warning:
>>   symbol 'dev_attr_line_size' was not declared. Should it be static?
>> drivers/base/node.c:240:1: warning:
>>   symbol 'dev_attr_indexing' was not declared. Should it be static?
>>
>> These symbols (and several others) are defined by DEVICE_ATTR_RO(name) in
>> CACHE_ATTR(name, fmt), and all of them are not used outside of node.c. So let's
>> mark DEVICE_ATTR_RO(name) static to solve these complains from Sparse.
> 
> Why not fix them all at once?  Why only one here?

Sorry for not making it clear enough. Actually the patch does fix them 
all. Those symbols reported by Sparse are generated when two of the 
following macros are expanded:

     CACHE_ATTR(size, "%llu")
     CACHE_ATTR(line_size, "%u")
     CACHE_ATTR(indexing, "%u")
     CACHE_ATTR(write_policy, "%u")

So one fix of the CACHE_ATTR's definition fixs them all.

> 
> thanks,
> 
> greg k-h
> .
> 

.