| Message ID | 20230302211759.30135-11-nick.alcock@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | MODULE_LICENSE removals, sixth tranche | expand |
On Thu, Mar 02, 2023 at 09:17:52PM +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@oracle.com> > Suggested-by: Luis Chamberlain <mcgrof@kernel.org> > Cc: Luis Chamberlain <mcgrof@kernel.org> > Cc: linux-modules@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Jiri Slaby <jirislaby@kernel.org> > --- > drivers/tty/n_null.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c > index f913b665af725..c24f75942c49d 100644 > --- a/drivers/tty/n_null.c > +++ b/drivers/tty/n_null.c > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void) > module_init(n_null_init); > module_exit(n_null_exit); > > -MODULE_LICENSE("GPL"); > MODULE_AUTHOR("Alan Cox"); > MODULE_ALIAS_LDISC(N_NULL); > MODULE_DESCRIPTION("Null ldisc driver"); > -- > 2.39.1.268.g9de2f9a303 > Nope, sorry, this is not good to do, please fix kbuild instead of forcing a tree-wide change like this. thanks, greg k-h
On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote: > On Thu, Mar 02, 2023 at 09:17:52PM +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@oracle.com> > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org> > > Cc: Luis Chamberlain <mcgrof@kernel.org> > > Cc: linux-modules@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: Jiri Slaby <jirislaby@kernel.org> > > --- > > drivers/tty/n_null.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c > > index f913b665af725..c24f75942c49d 100644 > > --- a/drivers/tty/n_null.c > > +++ b/drivers/tty/n_null.c > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void) > > module_init(n_null_init); > > module_exit(n_null_exit); > > > > -MODULE_LICENSE("GPL"); > > MODULE_AUTHOR("Alan Cox"); > > MODULE_ALIAS_LDISC(N_NULL); > > MODULE_DESCRIPTION("Null ldisc driver"); > > -- > > 2.39.1.268.g9de2f9a303 > > > > Nope, sorry, this is not good to do, please fix kbuild instead of > forcing a tree-wide change like this. Masahiro Yamada already NACK'd it such effort: https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com And his descriptiuon of the reasoning and logic is explained here: https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/ Let me summarize it though with a few quotes from him: "Having false-positives in modules.builtin should be OK" "In this sense, having always-builtin entries in module.builtin is OK." The reason Nick wants to do this work is that his future patches (which have been under review for years and I'm starting to chew on it and provide guidance on now) extend our ability to have more elaborate symbol to address mapping with more metdata, which does include information such as if something came from a module. So long term *I* certainly am interested in a deterministic way to determine if something could be a module. For a more elaborate attempt on my part to try to describe the problem and some side ideas I had if we wanted an alternative: https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/ I should also mention Christoph has also suggested we eventually move towards automatically generating the module license tag from the SPDX tag: https://lore.kernel.org/all/Y5BNCbFyvNA1Xp%2FX@infradead.org I agree with Christoph and I think we should get there. For now we want 1-1 mapping of real modules to the tag for both reasons of us not going to revert 8b41fc4454e and of later us wanting to do the full swoop automation of the module license tag. Although having modprobe not fail even if your module listed cannot be a module is non-fatal, the long term goal of cleaning this up is desirable anyway. If you have constructive ways to provide an alternative for this in kbuild, and help with the long term goals Nick has, patches or suggestions to are greatly welcomed. The simplest alternative I've come up with is the -DMODULE_POSSIBLE I mentioned in the thread above. But as I mentioned in that same thread the difficulty is in gathering the possible-obj-m without incurring a slow down on the build. Luis
On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote: > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Mar 02, 2023 at 09:17:52PM +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@oracle.com> > > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org> > > > Cc: Luis Chamberlain <mcgrof@kernel.org> > > > Cc: linux-modules@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org > > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > Cc: Jiri Slaby <jirislaby@kernel.org> > > > --- > > > drivers/tty/n_null.c | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c > > > index f913b665af725..c24f75942c49d 100644 > > > --- a/drivers/tty/n_null.c > > > +++ b/drivers/tty/n_null.c > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void) > > > module_init(n_null_init); > > > module_exit(n_null_exit); > > > > > > -MODULE_LICENSE("GPL"); > > > MODULE_AUTHOR("Alan Cox"); > > > MODULE_ALIAS_LDISC(N_NULL); > > > MODULE_DESCRIPTION("Null ldisc driver"); > > > -- > > > 2.39.1.268.g9de2f9a303 > > > > > > > Nope, sorry, this is not good to do, please fix kbuild instead of > > forcing a tree-wide change like this. > > Masahiro Yamada already NACK'd it such effort: > > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com > > And his descriptiuon of the reasoning and logic is explained here: > > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/ > > Let me summarize it though with a few quotes from him: > > "Having false-positives in modules.builtin should be OK" > "In this sense, having always-builtin entries in module.builtin is OK." None of that matters, sorry. Again, all I am saying is that you can not have some MODULE_() macros that are ok for code that is built in, and some that are not, for "reasons" that have to do how you all are treating the build system infrastructure as you are now putting arbritrary requirements for all driver authors (of which there are thousands) to know this. Just change the macros to work properly in both cases, I can't believe this is all that hard as obviously all of the other macros work both ways, right? That should not require any kbuild changes. > The reason Nick wants to do this work is that his future patches > (which have been under review for years and I'm starting to chew on > it and provide guidance on now) extend our ability to have more > elaborate symbol to address mapping with more metdata, which does > include information such as if something came from a module. So > long term *I* certainly am interested in a deterministic way to > determine if something could be a module. > > For a more elaborate attempt on my part to try to describe the problem > and some side ideas I had if we wanted an alternative: > > https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/ > > I should also mention Christoph has also suggested we eventually move > towards automatically generating the module license tag from the SPDX > tag: > > https://lore.kernel.org/all/Y5BNCbFyvNA1Xp%2FX@infradead.org That too would be wonderful, and I would love to see that, but it does not remove the base problem here that you are somehow forcing all driver authors to change their code for the build system changes which should not be affecting them at all at this point in time. If you all do trigger off of the SPDX tags, then the removal of all MODULE_LICENSE() instances would be great too, but I don't think you are there yet (and it also wouldn't require removal all at once as you could just stub out that macro to be nothing.) But this is not the real issue here... Maybe the solution is to stop triggering on MODULE_LICENSE() as something magic for the build, as obviously that is the root problem here. Or something else, I don't know, but what you all are doing here does not seem correct at all, sorry, and is only going to cause more long-term problems with maintenance and headaches for driver authors. thanks, greg k-h
On Fri, Mar 10, 2023 at 08:31:30AM +0100, Greg Kroah-Hartman wrote: > On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote: > > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Mar 02, 2023 at 09:17:52PM +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@oracle.com> > > > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org> > > > > Cc: Luis Chamberlain <mcgrof@kernel.org> > > > > Cc: linux-modules@vger.kernel.org > > > > Cc: linux-kernel@vger.kernel.org > > > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > Cc: Jiri Slaby <jirislaby@kernel.org> > > > > --- > > > > drivers/tty/n_null.c | 1 - > > > > 1 file changed, 1 deletion(-) > > > > > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c > > > > index f913b665af725..c24f75942c49d 100644 > > > > --- a/drivers/tty/n_null.c > > > > +++ b/drivers/tty/n_null.c > > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void) > > > > module_init(n_null_init); > > > > module_exit(n_null_exit); > > > > > > > > -MODULE_LICENSE("GPL"); > > > > MODULE_AUTHOR("Alan Cox"); > > > > MODULE_ALIAS_LDISC(N_NULL); > > > > MODULE_DESCRIPTION("Null ldisc driver"); > > > > -- > > > > 2.39.1.268.g9de2f9a303 > > > > > > > > > > Nope, sorry, this is not good to do, please fix kbuild instead of > > > forcing a tree-wide change like this. > > > > Masahiro Yamada already NACK'd it such effort: > > > > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com > > > > And his descriptiuon of the reasoning and logic is explained here: > > > > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/ > > > > Let me summarize it though with a few quotes from him: > > > > "Having false-positives in modules.builtin should be OK" > > "In this sense, having always-builtin entries in module.builtin is OK." > > None of that matters, sorry. > > Again, all I am saying is that you can not have some MODULE_() macros > that are ok for code that is built in, and some that are not, for > "reasons" that have to do how you all are treating the build system > infrastructure as you are now putting arbritrary requirements for all > driver authors (of which there are thousands) to know this. As noted once again, it is not putting hard requirement. Future tooling not yet added would just not benefit from distinguishing symbols for your modules. I'm happy to live with module authors not wanting to remove the module license tag from their modules if they can never actually be modules from not benefitting from the above tooling gains as its just cherry on top tooling gains. Solving this in way that does not impeed on current build system improvements is a challenge and I'm happy to punt that out to future work. > Just change the macros to work properly in both cases, I can't believe > this is all that hard as obviously all of the other macros work both > ways, right? That should not require any kbuild changes. Patches are welcomed. > > The reason Nick wants to do this work is that his future patches > > (which have been under review for years and I'm starting to chew on > > it and provide guidance on now) extend our ability to have more > > elaborate symbol to address mapping with more metdata, which does > > include information such as if something came from a module. So > > long term *I* certainly am interested in a deterministic way to > > determine if something could be a module. > > > > For a more elaborate attempt on my part to try to describe the problem > > and some side ideas I had if we wanted an alternative: > > > > https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/ > > > > I should also mention Christoph has also suggested we eventually move > > towards automatically generating the module license tag from the SPDX > > tag: > > > > https://lore.kernel.org/all/Y5BNCbFyvNA1Xp%2FX@infradead.org > > That too would be wonderful, and I would love to see that, but it does > not remove the base problem here that you are somehow forcing all driver > authors to change their code for the build system changes which should > not be affecting them at all at this point in time. By you, you mean Masahiro Yamada's patch. That is just collateral for tooling being built upon by Nick. And as Masahiro has pointed out more than once already, this is not a regression / fatal issue. > If you all do trigger off of the SPDX tags, then the removal of all > MODULE_LICENSE() instances would be great too, but I don't think you are > there yet (and it also wouldn't require removal all at once as you could > just stub out that macro to be nothing.) But this is not the real issue > here... That's future work. > Maybe the solution is to stop triggering on MODULE_LICENSE() as > something magic for the build, as obviously that is the root problem > here. Or something else, I don't know, but what you all are doing here > does not seem correct at all, sorry, and is only going to cause more > long-term problems with maintenance and headaches for driver authors. I already suggested what I think *could* be done as an alternative and the problem is not easy to resolve. Feel free to ignore the patches for your drivers which remove the module macros even if they are not modules. In lieu of alternative suggestions, that's what we have now, and it is much better than what Nick was suggesting before which Masahiro NACK'd. Most other module developers seem happy with the change, and this has also helped fix SPDX tags where there wasn't some too. So if you don't take the patches it is not the end of the world and Nick can move on with that effort for folks who do want to clarify this. Luis
On Fri, Mar 10, 2023 at 8:42 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > On Fri, Mar 10, 2023 at 08:31:30AM +0100, Greg Kroah-Hartman wrote: > > On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote: > > > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote: > > > > On Thu, Mar 02, 2023 at 09:17:52PM +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@oracle.com> > > > > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org> > > > > > Cc: Luis Chamberlain <mcgrof@kernel.org> > > > > > Cc: linux-modules@vger.kernel.org > > > > > Cc: linux-kernel@vger.kernel.org > > > > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> > > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > Cc: Jiri Slaby <jirislaby@kernel.org> > > > > > --- > > > > > drivers/tty/n_null.c | 1 - > > > > > 1 file changed, 1 deletion(-) > > > > > > > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c > > > > > index f913b665af725..c24f75942c49d 100644 > > > > > --- a/drivers/tty/n_null.c > > > > > +++ b/drivers/tty/n_null.c > > > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void) > > > > > module_init(n_null_init); > > > > > module_exit(n_null_exit); > > > > > > > > > > -MODULE_LICENSE("GPL"); > > > > > MODULE_AUTHOR("Alan Cox"); > > > > > MODULE_ALIAS_LDISC(N_NULL); > > > > > MODULE_DESCRIPTION("Null ldisc driver"); > > > > > -- > > > > > 2.39.1.268.g9de2f9a303 > > > > > > > > > > > > > Nope, sorry, this is not good to do, please fix kbuild instead of > > > > forcing a tree-wide change like this. > > > > > > Masahiro Yamada already NACK'd it such effort: > > > > > > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com > > > > > > And his descriptiuon of the reasoning and logic is explained here: > > > > > > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/ > > > > > > Let me summarize it though with a few quotes from him: > > > > > > "Having false-positives in modules.builtin should be OK" > > > "In this sense, having always-builtin entries in module.builtin is OK." > > > > None of that matters, sorry. > > > > Again, all I am saying is that you can not have some MODULE_() macros > > that are ok for code that is built in, and some that are not, for > > "reasons" that have to do how you all are treating the build system > > infrastructure as you are now putting arbritrary requirements for all > > driver authors (of which there are thousands) to know this. > > As noted once again, it is not putting hard requirement. Future tooling > not yet added would just not benefit from distinguishing symbols for > your modules. > > I'm happy to live with module authors not wanting to remove the module > license tag from their modules if they can never actually be modules > from not benefitting from the above tooling gains as its just cherry > on top tooling gains. Apparently lots of these patches have not arrived in linux-next without Acks (we're still discussing about this, right???). And some of the modified files have no SPDX-License-Identifier lines yet, so we are losing important licensing information: $ git grep -L SPDX-License-Identifier -- $(git show $(git log --oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in non-modules" | cut -d " " -f 1) | lsdiff --strip=1) drivers/bus/arm-cci.c drivers/bus/imx-weim.c drivers/bus/simple-pm-bus.c drivers/gpu/drm/drm_mipi_dsi.c drivers/irqchip/irq-mvebu-pic.c drivers/reset/reset-axs10x.c drivers/reset/reset-hsdk.c drivers/soc/sunxi/sunxi_sram.c drivers/video/fbdev/asiliantfb.c drivers/video/fbdev/gbefb.c drivers/video/fbdev/imsttfb.c drivers/xen/xenbus/xenbus_probe.c lib/glob.c Gr{oetje,eeting}s, Geert
On Fri, Mar 24, 2023 at 10:08 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > And some of the modified files have no SPDX-License-Identifier > lines yet, so we are losing important licensing information: > > $ git grep -L SPDX-License-Identifier -- $(git show $(git log > --oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in > non-modules" | cut -d " " -f 1) | lsdiff --strip=1) > drivers/bus/arm-cci.c > drivers/bus/imx-weim.c > drivers/bus/simple-pm-bus.c ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a false-positive, as I grepped against my current tree. > drivers/gpu/drm/drm_mipi_dsi.c > drivers/irqchip/irq-mvebu-pic.c > drivers/reset/reset-axs10x.c > drivers/reset/reset-hsdk.c > drivers/soc/sunxi/sunxi_sram.c > drivers/video/fbdev/asiliantfb.c > drivers/video/fbdev/gbefb.c > drivers/video/fbdev/imsttfb.c > drivers/xen/xenbus/xenbus_probe.c > lib/glob.c You want to use instead: git grep -L SPDX-License-Identifier linux-next/master -- $(git show $(git log --oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in non-modules" | cut -d " " -f 1) | lsdiff --strip=1) Gr{oetje,eeting}s, Geert
On Fri, Mar 24, 2023 at 10:08:17AM +0100, Geert Uytterhoeven wrote: > On Fri, Mar 10, 2023 at 8:42 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > On Fri, Mar 10, 2023 at 08:31:30AM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote: > > > > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote: > > > > > On Thu, Mar 02, 2023 at 09:17:52PM +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@oracle.com> > > > > > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org> > > > > > > Cc: Luis Chamberlain <mcgrof@kernel.org> > > > > > > Cc: linux-modules@vger.kernel.org > > > > > > Cc: linux-kernel@vger.kernel.org > > > > > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> > > > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > Cc: Jiri Slaby <jirislaby@kernel.org> > > > > > > --- > > > > > > drivers/tty/n_null.c | 1 - > > > > > > 1 file changed, 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c > > > > > > index f913b665af725..c24f75942c49d 100644 > > > > > > --- a/drivers/tty/n_null.c > > > > > > +++ b/drivers/tty/n_null.c > > > > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void) > > > > > > module_init(n_null_init); > > > > > > module_exit(n_null_exit); > > > > > > > > > > > > -MODULE_LICENSE("GPL"); > > > > > > MODULE_AUTHOR("Alan Cox"); > > > > > > MODULE_ALIAS_LDISC(N_NULL); > > > > > > MODULE_DESCRIPTION("Null ldisc driver"); > > > > > > -- > > > > > > 2.39.1.268.g9de2f9a303 > > > > > > > > > > > > > > > > Nope, sorry, this is not good to do, please fix kbuild instead of > > > > > forcing a tree-wide change like this. > > > > > > > > Masahiro Yamada already NACK'd it such effort: > > > > > > > > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com > > > > > > > > And his descriptiuon of the reasoning and logic is explained here: > > > > > > > > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/ > > > > > > > > Let me summarize it though with a few quotes from him: > > > > > > > > "Having false-positives in modules.builtin should be OK" > > > > "In this sense, having always-builtin entries in module.builtin is OK." > > > > > > None of that matters, sorry. > > > > > > Again, all I am saying is that you can not have some MODULE_() macros > > > that are ok for code that is built in, and some that are not, for > > > "reasons" that have to do how you all are treating the build system > > > infrastructure as you are now putting arbritrary requirements for all > > > driver authors (of which there are thousands) to know this. > > > > As noted once again, it is not putting hard requirement. Future tooling > > not yet added would just not benefit from distinguishing symbols for > > your modules. > > > > I'm happy to live with module authors not wanting to remove the module > > license tag from their modules if they can never actually be modules > > from not benefitting from the above tooling gains as its just cherry > > on top tooling gains. > > Apparently lots of these patches have not arrived in linux-next > without Acks (we're still discussing about this, right???). > > And some of the modified files have no SPDX-License-Identifier > lines yet, so we are losing important licensing information: > > $ git grep -L SPDX-License-Identifier -- $(git show $(git log > --oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in > non-modules" | cut -d " " -f 1) | lsdiff --strip=1) > drivers/bus/arm-cci.c > drivers/bus/imx-weim.c > drivers/bus/simple-pm-bus.c > drivers/gpu/drm/drm_mipi_dsi.c > drivers/irqchip/irq-mvebu-pic.c > drivers/reset/reset-axs10x.c > drivers/reset/reset-hsdk.c > drivers/soc/sunxi/sunxi_sram.c > drivers/video/fbdev/asiliantfb.c > drivers/video/fbdev/gbefb.c > drivers/video/fbdev/imsttfb.c > drivers/xen/xenbus/xenbus_probe.c > lib/glob.c Ick, that's not ok at all. Again, I strongly feel that removing MODULE_LICENSE() lines from files that just don't happen to be built as a module is not ok as no other MODULE_*() macro has this arbitrary restriction. thanks, greg k-h
Hi Greg, On Fri, Mar 24, 2023 at 10:14 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Fri, Mar 24, 2023 at 10:08:17AM +0100, Geert Uytterhoeven wrote: > > On Fri, Mar 10, 2023 at 8:42 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > On Fri, Mar 10, 2023 at 08:31:30AM +0100, Greg Kroah-Hartman wrote: > > > > On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote: > > > > > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote: > > > > > > On Thu, Mar 02, 2023 at 09:17:52PM +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@oracle.com> > > > > > > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org> > > > > > > > Cc: Luis Chamberlain <mcgrof@kernel.org> > > > > > > > Cc: linux-modules@vger.kernel.org > > > > > > > Cc: linux-kernel@vger.kernel.org > > > > > > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> > > > > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > Cc: Jiri Slaby <jirislaby@kernel.org> > > > > > > > --- > > > > > > > drivers/tty/n_null.c | 1 - > > > > > > > 1 file changed, 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c > > > > > > > index f913b665af725..c24f75942c49d 100644 > > > > > > > --- a/drivers/tty/n_null.c > > > > > > > +++ b/drivers/tty/n_null.c > > > > > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void) > > > > > > > module_init(n_null_init); > > > > > > > module_exit(n_null_exit); > > > > > > > > > > > > > > -MODULE_LICENSE("GPL"); > > > > > > > MODULE_AUTHOR("Alan Cox"); > > > > > > > MODULE_ALIAS_LDISC(N_NULL); > > > > > > > MODULE_DESCRIPTION("Null ldisc driver"); > > > > > > > -- > > > > > > > 2.39.1.268.g9de2f9a303 > > > > > > > > > > > > > > > > > > > Nope, sorry, this is not good to do, please fix kbuild instead of > > > > > > forcing a tree-wide change like this. > > > > > > > > > > Masahiro Yamada already NACK'd it such effort: > > > > > > > > > > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com > > > > > > > > > > And his descriptiuon of the reasoning and logic is explained here: > > > > > > > > > > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/ > > > > > > > > > > Let me summarize it though with a few quotes from him: > > > > > > > > > > "Having false-positives in modules.builtin should be OK" > > > > > "In this sense, having always-builtin entries in module.builtin is OK." > > > > > > > > None of that matters, sorry. > > > > > > > > Again, all I am saying is that you can not have some MODULE_() macros > > > > that are ok for code that is built in, and some that are not, for > > > > "reasons" that have to do how you all are treating the build system > > > > infrastructure as you are now putting arbritrary requirements for all > > > > driver authors (of which there are thousands) to know this. > > > > > > As noted once again, it is not putting hard requirement. Future tooling > > > not yet added would just not benefit from distinguishing symbols for > > > your modules. > > > > > > I'm happy to live with module authors not wanting to remove the module > > > license tag from their modules if they can never actually be modules > > > from not benefitting from the above tooling gains as its just cherry > > > on top tooling gains. > > > > Apparently lots of these patches have not arrived in linux-next > > without Acks (we're still discussing about this, right???). > > > > And some of the modified files have no SPDX-License-Identifier > > lines yet, so we are losing important licensing information: > > > > $ git grep -L SPDX-License-Identifier -- $(git show $(git log > > --oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in > > non-modules" | cut -d " " -f 1) | lsdiff --strip=1) > > drivers/bus/arm-cci.c > > drivers/bus/imx-weim.c > > drivers/bus/simple-pm-bus.c > > drivers/gpu/drm/drm_mipi_dsi.c > > drivers/irqchip/irq-mvebu-pic.c > > drivers/reset/reset-axs10x.c > > drivers/reset/reset-hsdk.c > > drivers/soc/sunxi/sunxi_sram.c > > drivers/video/fbdev/asiliantfb.c > > drivers/video/fbdev/gbefb.c > > drivers/video/fbdev/imsttfb.c > > drivers/xen/xenbus/xenbus_probe.c > > lib/glob.c > > Ick, that's not ok at all. > > Again, I strongly feel that removing MODULE_LICENSE() lines from files > that just don't happen to be built as a module is not ok as no other > MODULE_*() macro has this arbitrary restriction. I (still) agree with that, and I saw similar comments from others as well. Unfortunately these comments are spread across tens of threads :-( Gr{oetje,eeting}s, Geert
On 24 Mar 2023, Geert Uytterhoeven uttered the following: > I (still) agree with that, and I saw similar comments from others as well. > Unfortunately these comments are spread across tens of threads :-( Ugh. Should I do this sort of thing in one big commit next time? That would fix that problem, but at the cost of others. Lumping seems to me to be troublesome because it makes it harder to accept/reject different bits, but would it be *as* troublesome as this much splitting?
On Fri, Mar 24, 2023 at 02:16:03PM +0000, Nick Alcock wrote: > On 24 Mar 2023, Geert Uytterhoeven uttered the following: > > I (still) agree with that, and I saw similar comments from others as well. > > Unfortunately these comments are spread across tens of threads :-( > > Ugh. Should I do this sort of thing in one big commit next time? That > would fix that problem, but at the cost of others. Lumping seems to me > to be troublesome because it makes it harder to accept/reject different > bits, but would it be *as* troublesome as this much splitting? The problem is, some of us disagree that this should be done at all, so reverting all of the individual parts is going to be hard now. Please put back the license bits that you removed, as it is not a good idea to remove that if the file does not have a SPDX entry at the very least. thanks, greg k-h
On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote: > On Fri, Mar 24, 2023 at 02:16:03PM +0000, Nick Alcock wrote: > > On 24 Mar 2023, Geert Uytterhoeven uttered the following: > > > I (still) agree with that, and I saw similar comments from others as well. > > > Unfortunately these comments are spread across tens of threads :-( > > > > Ugh. Should I do this sort of thing in one big commit next time? That > > would fix that problem, but at the cost of others. Lumping seems to me > > to be troublesome because it makes it harder to accept/reject different > > bits, but would it be *as* troublesome as this much splitting? > > The problem is, some of us disagree that this should be done at all, so > reverting all of the individual parts is going to be hard now. > > Please put back the license bits that you removed, as it is not a good > idea to remove that if the file does not have a SPDX entry at the very > least. Nick, I've just dropped your series. Please only re-submit only for files where the license is clear. The effort of clarifying licenses on files where one doesn't have an SPDX tag is welcomed but can take time and we'll need this anyway in the future to help later strive to see if we can automatically generate the MODULE_LICENSE() from the SPDX tags. Luis
On Fri, Mar 24, 2023 at 10:14:15AM +0100, Greg Kroah-Hartman wrote: > Again, I strongly feel that removing MODULE_LICENSE() lines from files > that just don't happen to be built as a module is not ok as no other > MODULE_*() macro has this arbitrary restriction. Yes. And it should probably have a use in the kernel by checking that nothing license-incompatible ever gets linked into mvlinux. At least until we can parse the SPDX tags directly and make use of that instead.
On 24 Mar 2023, Luis Chamberlain spake thusly: > On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote: >> Please put back the license bits that you removed, as it is not a good >> idea to remove that if the file does not have a SPDX entry at the very >> least. > > Nick, I've just dropped your series. Thanks, that's much easier than getting all those reverts in. (Presumably the bits taken by other people can all stay.) > Please only re-submit only for > files where the license is clear. The effort of clarifying licenses > on files where one doesn't have an SPDX tag is welcomed but can take > time and we'll need this anyway in the future to help later strive to > see if we can automatically generate the MODULE_LICENSE() from the > SPDX tags. For now, I have an alternative that might be acceptable. I did a bit of an audit and it's all a right mess (see below), with wild divergence even when SPDX is present, GPL versus -only or GPL-2.0+ apparently applied almost at random and some things being completely different (in some cases they were both committed simultaneously and were inconsistent from the moment the module was written). So many things are inconsistent that kallmodsyms would call a lot of things modules that really aren't: there is enough error that there probably be noticeable mistakes in quite a high percentage of kernels. But... for our purposes, we don't actually *mind* if non-modules list things like licenses inconsistently in two different places. Removing MODULE_LICENSE was a means, not an end. What we're actually interested in doing is removing .modinfo in things that can't possibly be modules, and since a .modinfo in a guaranteed-non-module is at best entirely useless I don't think anyone could reasonably be opposed to that end goal (though they might reasonably be unhappy about all the churn involved in getting there). They object to the removal of the visible MODULE_LICENSE() argument text string, not to the useless compile-time effect of a MODULE_LICENSE in a non-module. So how about, for the first three groups below (the groups where MODULE_LICENSE and SPDX are inconsistent, or where a SPDX simply doesn't exist), instead of removing the MODULE_LICENSE we replace it with an identical call to a new macro named perhaps NONMODULE_LICENSE(), which is defined in module.h as simply expanding to nothing, except possibly emitting a compile-time error if it's ever used in a module? This more clearly denotes what's going on, keeps the license string in the source file on a nearly identical line (for whatever purpose it serves), drops the spurious .modinfo that's causing trouble, and probably makes fewer people unhappy? (I'm probably missing something, but the only reason I can see for being unhappy with this change is if you think the actual text string MODULE_LICENSE has some sort of legal force that NONMODULE_LICENSE would not have. Speaking as a genuine non-lawyer, the only argument anyone could have for that would be customary use, I'd think; and in *that* case we can fix it without even changing the MODULE_LICENSE text string by introducing a #define at the top of each affected file which redefines MODULE_LICENSE() to nothing for that file. But that's ugly: I think I'd prefer NONMODULE_LICENSE().) ... does that seem more reasonable? Anyway, the audit of licenses in files touched by (the remainig files in) this series. Here are the instances that don't fit what seems to be the usual rule: arch/x86/crypto/blake2s-glue.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 OR MIT arch/x86/mm/debug_pagetables.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/bus/intel-ixp4xx-eb.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/bus/qcom-ebi2.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/clk/clk-bm1880.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0+ drivers/firmware/broadcom/bcm47xx_nvram.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-or-later drivers/firmware/imx/imx-scu.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0+ drivers/firmware/imx/scu-pd.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0+ drivers/irqchip/irq-mbigen.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/irqchip/irq-renesas-rzg2l.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 drivers/irqchip/irq-sl28cpld.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/pinctrl/mediatek/pinctrl-mt8188.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 drivers/pinctrl/mediatek/pinctrl-mt8365.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 drivers/pinctrl/renesas/pinctrl-rzv2m.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 drivers/power/reset/gpio-restart.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/power/reset/ltc2952-poweroff.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-or-later drivers/power/supply/wm97xx_battery.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/reset/reset-lantiq.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/reset/reset-microchip-sparx5.c: ML: MODULE_LICENSE("Dual MIT/GPL"); SPDX: GPL-2.0+ drivers/reset/reset-mpfs.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/soc/apple/apple-pmgr-pwrstate.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only OR MIT drivers/soc/tegra/cbb/tegra194-cbb.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 drivers/soc/tegra/cbb/tegra234-cbb.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 drivers/tty/n_null.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 drivers/video/fbdev/vesafb.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/xen/grant-dma-ops.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only fs/binfmt_elf.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only fs/nfs_common/nfs_ssc.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only kernel/dma/map_benchmark.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only kernel/events/hw_breakpoint_test.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 kernel/trace/rv/reactor_panic.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 kernel/trace/rv/reactor_printk.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 kernel/watch_queue.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0 lib/btree.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only lib/crypto/blake2s-generic.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 OR MIT lib/crypto/blake2s.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 OR MIT mm/zpool.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only Here's the subset of that that isn't just GPL-versus-v2 mismatches, all MIT-versus-GPL in different directions: arch/x86/crypto/blake2s-glue.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 OR MIT drivers/reset/reset-microchip-sparx5.c: ML: MODULE_LICENSE("Dual MIT/GPL"); SPDX: GPL-2.0+ drivers/soc/apple/apple-pmgr-pwrstate.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only OR MIT lib/crypto/blake2s-generic.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 OR MIT lib/crypto/blake2s.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 OR MIT Here are the ones that don't have SPDX at all: drivers/bus/arm-cci.c: ML: MODULE_LICENSE("GPL"); SPDX: drivers/bus/imx-weim.c: ML: MODULE_LICENSE("GPL"); SPDX: drivers/bus/simple-pm-bus.c: ML: MODULE_LICENSE("GPL v2"); SPDX: drivers/gpu/drm/drm_mipi_dsi.c: ML: MODULE_LICENSE("GPL and additional rights"); SPDX: drivers/reset/reset-axs10x.c: ML: MODULE_LICENSE("GPL v2"); SPDX: drivers/reset/reset-hsdk.c: ML: MODULE_LICENSE("GPL v2"); SPDX: drivers/video/console/vgacon.c: ML: MODULE_LICENSE("GPL"); SPDX: drivers/video/fbdev/asiliantfb.c: ML: MODULE_LICENSE("GPL"); SPDX: drivers/video/fbdev/gbefb.c: ML: MODULE_LICENSE("GPL"); SPDX: drivers/video/fbdev/imsttfb.c: ML: MODULE_LICENSE("GPL"); SPDX: drivers/xen/xenbus/xenbus_probe.c: ML: MODULE_LICENSE("GPL"); SPDX: lib/glob.c: ML: MODULE_LICENSE("Dual MIT/GPL"); SPDX: Here are all the others (verified largely by eye, so there might be a few errors) -- the majority, but only just: crypto/asymmetric_keys/asymmetric_type.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-or-later drivers/accessibility/braille/braille_console.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-or-later drivers/amba/tegra-ahb.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/android/binder.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/bus/arm-integrator-lm.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/bus/bt1-apb.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/bus/bt1-axi.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/bus/qcom-ssc-block-bus.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/clk/microchip/clk-mpfs.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/clk/renesas/renesas-cpg-mssr.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/clk/renesas/rzg2l-cpg.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/clocksource/em_sti.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/clocksource/sh_cmt.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/clocksource/sh_mtu2.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/clocksource/sh_tmu.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/clocksource/timer-stm32-lp.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/clocksource/timer-tegra186.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/clocksource/timer-ti-dm.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0+ drivers/dma-buf/heaps/cma_heap.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/dma-buf/heaps/system_heap.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/dma-buf/udmabuf.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/dma/ep93xx_dma.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-or-later drivers/dma/ipu/ipu_idmac.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/dma/mv_xor_v2.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-or-later drivers/dma/sh/shdma-base.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/dma/stm32-dmamux.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/dma/stm32-mdma.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/edac/altera_edac.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/hwspinlock/hwspinlock_core.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/interconnect/core.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/iommu/sun50i-iommu.c: ML: MODULE_LICENSE("Dual BSD/GPL"); SPDX: (GPL-2.0-only OR BSD-2-Clause) drivers/irqchip/irq-al-fic.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/irqchip/irq-ls-scfg-msi.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/irqchip/irq-mchp-eic.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/irqchip/irq-mvebu-pic.c: ML: MODULE_LICENSE("GPL v2"); SPDX: drivers/irqchip/irq-renesas-intc-irqpin.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/irqchip/irq-renesas-irqc.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/irqchip/irq-renesas-rza1.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/irqchip/irq-ti-sci-inta.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/irqchip/irq-ti-sci-intr.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/mailbox/rockchip-mailbox.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/mfd/altera-sysmgr.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/nvmem/core.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/perf/apple_m1_cpu_pmu.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/phy/intel/phy-intel-lgm-combo.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/pinctrl/actions/pinctrl-s500.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0+ drivers/pinctrl/actions/pinctrl-s700.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0+ drivers/pinctrl/actions/pinctrl-s900.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0+ drivers/pinctrl/bcm/pinctrl-ns.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/pinctrl/mediatek/pinctrl-mt8192.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/pinctrl/pinctrl-amd.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/pinctrl/renesas/pinctrl-rza1.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/pinctrl/renesas/pinctrl-rza2.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/pinctrl/renesas/pinctrl-rzg2l.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/pinctrl/renesas/pinctrl-rzn1.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/power/reset/as3722-poweroff.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/power/reset/gpio-poweroff.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/power/reset/keystone-reset.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/power/reset/mt6323-poweroff.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/power/reset/regulator-poweroff.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/power/reset/restart-poweroff.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/power/reset/tps65086-restart.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/power/supply/power_supply_core.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-only drivers/regulator/stm32-pwr.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 drivers/remoteproc/remoteproc_core.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/soc/fujitsu/a64fx-diag.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/tty/serial/imx_earlycon.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0+ drivers/tty/serial/rda-uart.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0+ drivers/video/fbdev/mmp/hw/mmp_ctrl.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-or-later drivers/video/fbdev/mmp/panel/tpo_tj032md01bw.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-or-later drivers/video/fbdev/wm8505fb.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only drivers/video/fbdev/wmt_ge_rops.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0-only fs/unicode/utf8-core.c: ML: MODULE_LICENSE("GPL v2"); SPDX: SPDX-License-Identifier: GPL-2.0 lib/pldmfw/pldmfw.c: ML: MODULE_LICENSE("GPL v2"); SPDX: GPL-2.0 lib/test_fprobe.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-or-later mm/zswap.c: ML: MODULE_LICENSE("GPL"); SPDX: GPL-2.0-or-later
On Mon, Mar 27, 2023 at 11:46:34AM +0100, Nick Alcock wrote: > On 24 Mar 2023, Luis Chamberlain spake thusly: > > > On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote: > >> Please put back the license bits that you removed, as it is not a good > >> idea to remove that if the file does not have a SPDX entry at the very > >> least. > > > > Nick, I've just dropped your series. > > Thanks, that's much easier than getting all those reverts in. > (Presumably the bits taken by other people can all stay.) > > > Please only re-submit only for > > files where the license is clear. The effort of clarifying licenses > > on files where one doesn't have an SPDX tag is welcomed but can take > > time and we'll need this anyway in the future to help later strive to > > see if we can automatically generate the MODULE_LICENSE() from the > > SPDX tags. > > For now, I have an alternative that might be acceptable. I did a bit of > an audit and it's all a right mess (see below), with wild divergence > even when SPDX is present, GPL versus -only or GPL-2.0+ apparently > applied almost at random and some things being completely different (in > some cases they were both committed simultaneously and were inconsistent > from the moment the module was written). So many things are inconsistent > that kallmodsyms would call a lot of things modules that really aren't: > there is enough error that there probably be noticeable mistakes in > quite a high percentage of kernels. As you have found out, there is a difference that matters in the SPDX lines vs the MODULE_LICENSE lines when it comes to GPL vs GPLv2+ stuff. The SPDX lines are correct for the code itself, while the MODULE_LICENSE lines are correct from a "this is the license of this binary" point of view. So don't get confused here, if you all can figure out a way to generate the MODULE_LICENSE() lines from SPDX, that would be great, but in my quick look I think it's going to be very difficult (think about how multiple files make up a single module binary...) good luck! > But... for our purposes, we don't actually *mind* if non-modules list > things like licenses inconsistently in two different places. Removing > MODULE_LICENSE was a means, not an end. What we're actually interested > in doing is removing .modinfo in things that can't possibly be modules, > and since a .modinfo in a guaranteed-non-module is at best entirely > useless I don't think anyone could reasonably be opposed to that end > goal (though they might reasonably be unhappy about all the churn > involved in getting there). They object to the removal of the visible > MODULE_LICENSE() argument text string, not to the useless compile-time > effect of a MODULE_LICENSE in a non-module. there are other things that create .modinfo lines, so I'm confused why you picked the license line to trigger all of this. > So how about, for the first three groups below (the groups where > MODULE_LICENSE and SPDX are inconsistent, or where a SPDX simply doesn't > exist), instead of removing the MODULE_LICENSE we replace it with an > identical call to a new macro named perhaps NONMODULE_LICENSE(), which > is defined in module.h as simply expanding to nothing, except possibly > emitting a compile-time error if it's ever used in a module? This more > clearly denotes what's going on, keeps the license string in the source > file on a nearly identical line (for whatever purpose it serves), drops > the spurious .modinfo that's causing trouble, and probably makes fewer > people unhappy? Again, no, why aren't you just stubbing out MODULE_LICENSE() in the build if it's not being built as a module like the other MODULE_*() macros are? Why is the license so special here yet the device list or module authors not? Don't treat this macro as somehow special where authors have to remember to not use it (or to use it), while the other MODULE_* macros do not have the issue? That's my main objection here. Don't get confused by the license stuff, that's secondary. thanks, greg k-h
On 27 Mar 2023, Greg Kroah-Hartman told this: > On Mon, Mar 27, 2023 at 11:46:34AM +0100, Nick Alcock wrote: >> On 24 Mar 2023, Luis Chamberlain spake thusly: >> > Please only re-submit only for >> > files where the license is clear. The effort of clarifying licenses >> > on files where one doesn't have an SPDX tag is welcomed but can take >> > time and we'll need this anyway in the future to help later strive to >> > see if we can automatically generate the MODULE_LICENSE() from the >> > SPDX tags. >> >> For now, I have an alternative that might be acceptable. I did a bit of >> an audit and it's all a right mess (see below), with wild divergence >> even when SPDX is present, GPL versus -only or GPL-2.0+ apparently >> applied almost at random and some things being completely different (in >> some cases they were both committed simultaneously and were inconsistent >> from the moment the module was written). So many things are inconsistent >> that kallmodsyms would call a lot of things modules that really aren't: >> there is enough error that there probably be noticeable mistakes in >> quite a high percentage of kernels. > > As you have found out, there is a difference that matters in the SPDX > lines vs the MODULE_LICENSE lines when it comes to GPL vs GPLv2+ stuff. > The SPDX lines are correct for the code itself, while the MODULE_LICENSE > lines are correct from a "this is the license of this binary" point of > view. Oh right! > So don't get confused here, if you all can figure out a way to generate > the MODULE_LICENSE() lines from SPDX, that would be great, but in my > quick look I think it's going to be very difficult (think about how > multiple files make up a single module binary...) In this specific case, 100% of the files I'm touching cannot be built as modules at all (they are covered purely by booleans in Kconfig, no tristate), so by this definition MODULE_LICENSE would seem to have no meaning for them? If so, I don't see why you're objecting to ripping out these meaningless lines. (I have already been told not to comment them out but instead to just delete them.) >> But... for our purposes, we don't actually *mind* if non-modules list >> things like licenses inconsistently in two different places. Removing >> MODULE_LICENSE was a means, not an end. What we're actually interested >> in doing is removing .modinfo in things that can't possibly be modules, >> and since a .modinfo in a guaranteed-non-module is at best entirely >> useless I don't think anyone could reasonably be opposed to that end >> goal (though they might reasonably be unhappy about all the churn >> involved in getting there). They object to the removal of the visible >> MODULE_LICENSE() argument text string, not to the useless compile-time >> effect of a MODULE_LICENSE in a non-module. > > there are other things that create .modinfo lines, so I'm confused why > you picked the license line to trigger all of this. I didn't. Yamada did. MODULE_LICENSE is the only thing that generates .modinfo *sections*, as of this commit: commit 8b41fc4454e36fbfdbb23f940d023d4dece2de29 Author: Masahiro Yamada <masahiroy@kernel.org> Date: Thu Dec 19 17:33:29 2019 +0900 kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf [...] This commit simplifies the implementation. Let's exploit the fact that every module has MODULE_LICENSE(). (modpost shows a warning if MODULE_LICENSE is missing. If so, 0-day bot would already have blocked such a module.) I added MODULE_FILE to <linux/module.h>. When the code is being compiled as builtin, it will be filled with the file path of the module, and collected into modules.builtin.info. Then, scripts/link-vmlinux.sh extracts the list of builtin modules out of it. This new approach fixes the false-positives above, but adds another type of false-positives; non-modular code may have MODULE_LICENSE() by mistake. This is not a big deal, it is just the code is always orphan. We can clean it up if we like. [...] It turns out that the presence of .modinfo is the *only* thing Yamada is willing to use as an indicator that something can be a module: he's vehemently refused any alternative, such as anything going back to the tristate statements in Kconfig (using a "gave me nightmares" level of vehemence, to be honest, and that is not a figure of speech). But as a result of this, if we want there to be any way to tell whether something can be a module, we now *have* to use .modinfo, which means we *have* to ensure that only things that can be a module can contain MODULE_LICENSEs. After the commit above, correct modules.builtin construction requires this property. (Before that commit, all that was necessary was Kconfig.) >> So how about, for the first three groups below (the groups where >> MODULE_LICENSE and SPDX are inconsistent, or where a SPDX simply doesn't >> exist), instead of removing the MODULE_LICENSE we replace it with an >> identical call to a new macro named perhaps NONMODULE_LICENSE(), which >> is defined in module.h as simply expanding to nothing, except possibly >> emitting a compile-time error if it's ever used in a module? This more >> clearly denotes what's going on, keeps the license string in the source >> file on a nearly identical line (for whatever purpose it serves), drops >> the spurious .modinfo that's causing trouble, and probably makes fewer >> people unhappy? > > Again, no, why aren't you just stubbing out MODULE_LICENSE() in the > build if it's not being built as a module like the other MODULE_*() > macros are? Why is the license so special here yet the device list or > module authors not? This isn't "being built as a module": this is "can *ever* be built as a module": i.e. "has a tristate line in Kconfig for at least one CONFIG_ variable governing the build for this object file". > Don't treat this macro as somehow special where authors have to remember > to not use it (or to use it), while the other MODULE_* macros do not > have the issue? The commit above should make things clearer, I hope? I think Yamada's idea was that MODULE_LICENSE is something that must be present if module loading is to work, so hanging other things that should be present in all modules off it seems reasonable too: this seems pretty reasonable to me as well, if directly driving via tristate statements is out. This directly affects things like modules.builtin which are now driven by .modinfo sections in vmlinux.o, dropped by the linker at final link time. I'm just trying to make that .modinfo sections not contain entries for things that are not tristate. Believe me, I'd much rather have done this *without* a 140-patch series, but this was the first approach that none of the module maintainers nacked. > That's my main objection here. Don't get confused by the license stuff, > that's secondary. Well, it seems to me that you're really objecting to the consequences of a years-old commit that I didn't write. Since the person who did write it seems to hate me for unclear reasons, I think you might have to ask him for his rationale yourself (all his few communications with me for the last several months have been various forms of insult, often for doing things that he asked me to do years earlier: the remainder were for doing things Luis asked me to do). If you could possibly get him to stop attacking me I'd be grateful too. I'm only trying to improve the kernel here. (I am aware that saying this is probably going to make Yamada explode -- again -- so I removed him from Cc: out of an excess of hope. Nonetheless it is true.) (Not everyone has been awful. Luis in particular has been extremely helpful even if I cursed at his requests sometimes. He even wrote a replacement for the patch Yamada initially objected to, without my even asking, and it was ever so much simpler than the thing I'd derived from the old scripts/Makefile.modbuiltin. But that patch does rely on modules.builtin being correct, hence needs all this MODULE_LICENSE stuff...)
On 27 Mar 2023, Nick Alcock uttered the following: > Well, it seems to me that you're really objecting to the consequences of > a years-old commit that I didn't write. Since the person who did write > it seems to hate me for unclear reasons, I should probably apologise: this was uncalled for. Stressful day and I typed without thinking (and then rephrased it repeatedly without thinking). So, sorry! Mea culpa etc. (I am *good* at putting both feet in it)
Nick, you *need* something we *want* but the form requires work. Removing the module license tag and all that other module boiler plate from modules which cannot possibly be modules is obviously welcomed. But there's a few issues, one of them is when we don't have SPDX license pegged on files. We *all* want SPDX files properly annotated on files. We *want* to automate the module license from the SPDX tag. It sounds hard but let's go for the long shot of striving to automate the module license from the SPDX tags. Let's break this down into a few steps that also benefit your goals: 1) Fix all all code which use the module license tag but cannot possibly be modules to ensure they all have proper SPDX tags. This is a welcomed effort. 2) Create an an association of existing module licenses from mod-objs object lists. 3) Verify these make sense with us. 4) With that list we can then infer a module license from things which *can* be modules. The trick is today we use the module license *for* that inference, however, look at the tristate, and see if you can add a POSSIBLE_MODULE as I noted and hinted before. That get's you a module license replacement. The final nail to all this is use that to replace all module licenses and have this done automatically. Luis
On Fri, Mar 24, 2023 at 11:06:59AM -0700, Luis Chamberlain wrote: > On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Mar 24, 2023 at 02:16:03PM +0000, Nick Alcock wrote: > > > On 24 Mar 2023, Geert Uytterhoeven uttered the following: > > > > I (still) agree with that, and I saw similar comments from others as well. > > > > Unfortunately these comments are spread across tens of threads :-( > > > > > > Ugh. Should I do this sort of thing in one big commit next time? That > > > would fix that problem, but at the cost of others. Lumping seems to me > > > to be troublesome because it makes it harder to accept/reject different > > > bits, but would it be *as* troublesome as this much splitting? > > > > The problem is, some of us disagree that this should be done at all, so > > reverting all of the individual parts is going to be hard now. > > > > Please put back the license bits that you removed, as it is not a good > > idea to remove that if the file does not have a SPDX entry at the very > > least. > > Nick, I've just dropped your series. Please only re-submit only for > files where the license is clear. The effort of clarifying licenses > on files where one doesn't have an SPDX tag is welcomed but can take > time and we'll need this anyway in the future to help later strive to > see if we can automatically generate the MODULE_LICENSE() from the > SPDX tags. I had not seen any effort to get a new series going for this so given I realize this is a royal pain in the ass to, and Nick has *already* done enough, I've done the sanity checks myself and dropped the patches from Nick which lacked SPDX annotations. One can verify if a patch you are modifying lacks SPDX annotations in a commit series with: ./scripts/spdxcheck.py -f $(git diff --name-only commid-id | xargs echo) And so I've dropped all the patches that did that from Nick's series and pushed to modules-next only the ones that did have an SPDX annotation. There were only 11 files which *did not* have SPDX annoations, these can be worked on with the community later to get SPDX annotations added: drivers/bus/arm-cci.c drivers/bus/imx-weim.c drivers/gpu/drm/drm_mipi_dsi.c drivers/irqchip/irq-mvebu-pic.c drivers/reset/reset-axs10x.c drivers/reset/reset-hsdk.c drivers/video/fbdev/asiliantfb.c drivers/video/fbdev/gbefb.c drivers/video/fbdev/imsttfb.c drivers/xen/xenbus/xenbus_probe.c lib/glob.c Luis
diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c index f913b665af725..c24f75942c49d 100644 --- a/drivers/tty/n_null.c +++ b/drivers/tty/n_null.c @@ -63,7 +63,6 @@ static void __exit n_null_exit(void) module_init(n_null_init); module_exit(n_null_exit); -MODULE_LICENSE("GPL"); MODULE_AUTHOR("Alan Cox"); MODULE_ALIAS_LDISC(N_NULL); MODULE_DESCRIPTION("Null ldisc driver");
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@oracle.com> Suggested-by: Luis Chamberlain <mcgrof@kernel.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> --- drivers/tty/n_null.c | 1 - 1 file changed, 1 deletion(-)