linux-kernel - Re: [PATCH 14/24] kbuild, firmware: imx: 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZBjTLGhohFlbO4xr@bombadil.infradead.org>
Date:   Mon, 20 Mar 2023 14:42:04 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Nick Alcock <nick.alcock@...cle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>
Cc:     Shawn Guo <shawnguo@...nel.org>, linux-modules@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Hitomi Hasegawa <hasegawa-hitomi@...itsu.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 14/24] kbuild, firmware: imx: remove MODULE_LICENSE in
 non-modules

On Mon, Mar 20, 2023 at 10:36:15AM +0000, Nick Alcock wrote:
> On 14 Mar 2023, Shawn Guo verbalised:
> 
> > On Fri, Feb 17, 2023 at 02:10:49PM +0000, 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>
> >
> > Should I apply it as a fix for 6.3-rc with Cc stable tag, or can it be
> > a material for -next?

These are not stable critical patches.

> This is currently built against -next, but Luis has indicated an intent
> to pull the lot in via -rc3 (hence my scrambling to get the series
> polished up for him, tags attached etc now). So, er... yes? :)

Those patches which don't get this simply can't benefit from future
tooling enhancements which Nick is working on which will leverage
correct mapping.

So yes, my goal is to pull up straggler patches except where some
maintainer explicitly don't want them. For instance, I will not be
taking in the patches for trees that Greg KH maintains as he would
prefer an alternative, but yet hasn't recommended an alternative
strategy to help with Nick's work.

  Luis