linux-kernel - Re: [PATCH 10/27] leds: remove MODULE

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] [day] [month] [year] [list]

Date:   Mon, 20 Mar 2023 10:40:24 +0000
From:   Nick Alcock <nick.alcock@...cle.com>
To:     Lee Jones <lee@...nel.org>
Cc:     mcgrof@...nel.org, linux-modules@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Hitomi Hasegawa <hasegawa-hitomi@...itsu.com>,
        Pavel Machek <pavel@....cz>, linux-leds@...r.kernel.org
Subject: Re: [PATCH 10/27] leds: remove MODULE_LICENSE in non-modules

On 3 Mar 2023, Lee Jones uttered the following:

> On Fri, 24 Feb 2023, Nick Alcock wrote:
>
>> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
>> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
>> are used to identify modules. As a consequence, uses of the macro
>> in non-modules will cause modprobe to misidentify their containing
>> object file as a module when it is not (false positives), and modprobe
>> might succeed rather than failing with a suitable error message.
>> 
>> So remove it in the files in this commit, none of which can be built as
>> modules.
>> 
>> Signed-off-by: Nick Alcock <nick.alcock@...cle.com>
>> Suggested-by: Luis Chamberlain <mcgrof@...nel.org>
>> Cc: Luis Chamberlain <mcgrof@...nel.org>
>> Cc: linux-modules@...r.kernel.org
>> Cc: linux-kernel@...r.kernel.org
>> Cc: Hitomi Hasegawa <hasegawa-hitomi@...itsu.com>
>> Cc: Pavel Machek <pavel@....cz>
>> Cc: Lee Jones <lee@...nel.org>
>> Cc: linux-leds@...r.kernel.org
>> ---
>>  drivers/leds/leds-asic3.c | 1 -
>>  1 file changed, 1 deletion(-)
>
> Mention the driver in the subject line please.

Sorry, the prefix-generation is all automated: we use whatever prefix is
most commonly used by all affected drivers in the subsystem and shared
by all of them. In this case, that was simply 'leds', apparently because
almost all things affecting this driver were treewide.

... which probably explains why the driver was removed in January and is
gone in -next, so I guess this one will go away shortly regardless.