| Message ID | 20190927093603.9140-1-yamada.masahiro@socionext.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | module: various bug-fixes and clean-ups for module namespace | expand |
On Fri, Sep 27, 2019 at 06:35:56PM +0900, Masahiro Yamada wrote: > >I was hit by some problems caused by the module namespace feature >that was merged recently. At least, the breakage of >external module builds is a fatal one. I just took a look at the code >closer, and I noticed some more issues and improvements. > >I hope these patches are mostly OK. >The 4th patch might have room for argument since it is a trade-off >of "cleaner implermentation" vs "code size". > Thanks Masahiro for taking the time to improve the implementation of the symbol namespaces. These are all good points that you addressed! For [04/07], I can work on this if you do not mind. Cheers, Matthias > >Masahiro Yamada (7): > modpost: fix broken sym->namespace for external module builds > module: swap the order of symbol.namespace > module: rename __kstrtab_ns_* to __kstrtabns_* to avoid symbol > conflict > module: avoid code duplication in include/linux/export.h > kbuild: fix build error of 'make nsdeps' in clean tree > nsdeps: fix hashbang of scripts/nsdeps > nsdeps: make generated patches independent of locale > > Makefile | 2 +- > include/linux/export.h | 104 ++++++++++++++--------------------------- > kernel/module.c | 2 +- > scripts/mod/modpost.c | 20 ++++---- > scripts/nsdeps | 4 +- > 5 files changed, 47 insertions(+), 85 deletions(-) > >-- >2.17.1 >
Hi Matthias, On Fri, Sep 27, 2019 at 10:41 PM Matthias Maennich <maennich@google.com> wrote: > > On Fri, Sep 27, 2019 at 06:35:56PM +0900, Masahiro Yamada wrote: > > > >I was hit by some problems caused by the module namespace feature > >that was merged recently. At least, the breakage of > >external module builds is a fatal one. I just took a look at the code > >closer, and I noticed some more issues and improvements. > > > >I hope these patches are mostly OK. > >The 4th patch might have room for argument since it is a trade-off > >of "cleaner implermentation" vs "code size". > > > Thanks Masahiro for taking the time to improve the implementation of the > symbol namespaces. These are all good points that you addressed! > > For [04/07], I can work on this if you do not mind. Please feel free to. Thanks for your review.
+++ Matthias Maennich [27/09/19 14:41 +0100]: >On Fri, Sep 27, 2019 at 06:35:56PM +0900, Masahiro Yamada wrote: >> >>I was hit by some problems caused by the module namespace feature >>that was merged recently. At least, the breakage of >>external module builds is a fatal one. I just took a look at the code >>closer, and I noticed some more issues and improvements. >> >>I hope these patches are mostly OK. >>The 4th patch might have room for argument since it is a trade-off >>of "cleaner implermentation" vs "code size". >> >Thanks Masahiro for taking the time to improve the implementation of the >symbol namespaces. These are all good points that you addressed! Agreed, thanks Masahiro for fixing up all the rough edges! Your series of fixes look good to me, I will queue this up on modules-next this week with the exception of patch 4 - Matthias, you are planning to submit a patch that would supercede patch 04/07, right? Thanks! Jessica
On Wed, Oct 02, 2019 at 08:57:02PM +0200, Jessica Yu wrote: >+++ Matthias Maennich [27/09/19 14:41 +0100]: >>On Fri, Sep 27, 2019 at 06:35:56PM +0900, Masahiro Yamada wrote: >>> >>>I was hit by some problems caused by the module namespace feature >>>that was merged recently. At least, the breakage of >>>external module builds is a fatal one. I just took a look at the code >>>closer, and I noticed some more issues and improvements. >>> >>>I hope these patches are mostly OK. >>>The 4th patch might have room for argument since it is a trade-off >>>of "cleaner implermentation" vs "code size". >>> >>Thanks Masahiro for taking the time to improve the implementation of the >>symbol namespaces. These are all good points that you addressed! > >Agreed, thanks Masahiro for fixing up all the rough edges! Your series >of fixes look good to me, I will queue this up on modules-next this >week with the exception of patch 4 - Matthias, you are planning to >submit a patch that would supercede patch 04/07, right? I will most likely create a patch on top of 04/07 and will submit everything as a separate series. Cheers, Matthias
H Jessica, On Thu, Oct 3, 2019 at 3:57 AM Jessica Yu <jeyu@kernel.org> wrote: > > +++ Matthias Maennich [27/09/19 14:41 +0100]: > >On Fri, Sep 27, 2019 at 06:35:56PM +0900, Masahiro Yamada wrote: > >> > >>I was hit by some problems caused by the module namespace feature > >>that was merged recently. At least, the breakage of > >>external module builds is a fatal one. I just took a look at the code > >>closer, and I noticed some more issues and improvements. > >> > >>I hope these patches are mostly OK. > >>The 4th patch might have room for argument since it is a trade-off > >>of "cleaner implermentation" vs "code size". > >> > >Thanks Masahiro for taking the time to improve the implementation of the > >symbol namespaces. These are all good points that you addressed! > > Agreed, thanks Masahiro for fixing up all the rough edges! Your series > of fixes look good to me, I will queue this up on modules-next this > week Since these are bug fixes, please send them before v5.4. Thanks. > with the exception of patch 4 - Matthias, you are planning to > submit a patch that would supercede patch 04/07, right? > > Thanks! > > Jessica
Hi Jessica, On Thu, Oct 3, 2019 at 3:57 AM Jessica Yu <jeyu@kernel.org> wrote: > > +++ Matthias Maennich [27/09/19 14:41 +0100]: > >On Fri, Sep 27, 2019 at 06:35:56PM +0900, Masahiro Yamada wrote: > >> > >>I was hit by some problems caused by the module namespace feature > >>that was merged recently. At least, the breakage of > >>external module builds is a fatal one. I just took a look at the code > >>closer, and I noticed some more issues and improvements. > >> > >>I hope these patches are mostly OK. > >>The 4th patch might have room for argument since it is a trade-off > >>of "cleaner implermentation" vs "code size". > >> > >Thanks Masahiro for taking the time to improve the implementation of the > >symbol namespaces. These are all good points that you addressed! > > Agreed, thanks Masahiro for fixing up all the rough edges! Your series > of fixes look good to me, I will queue this up on modules-next this > week with the exception of patch 4 - Matthias, you are planning to > submit a patch that would supercede patch 04/07, right? > > Thanks! I missed to fix one issue in v1. sym_add_exported() misses to set s->namespace if the struct symbol is already created by read_dump() or sym_update_crc(). So, I just sent v2.
I was hit by some problems caused by the module namespace feature that was merged recently. At least, the breakage of external module builds is a fatal one. I just took a look at the code closer, and I noticed some more issues and improvements. I hope these patches are mostly OK. The 4th patch might have room for argument since it is a trade-off of "cleaner implermentation" vs "code size". Masahiro Yamada (7): modpost: fix broken sym->namespace for external module builds module: swap the order of symbol.namespace module: rename __kstrtab_ns_* to __kstrtabns_* to avoid symbol conflict module: avoid code duplication in include/linux/export.h kbuild: fix build error of 'make nsdeps' in clean tree nsdeps: fix hashbang of scripts/nsdeps nsdeps: make generated patches independent of locale Makefile | 2 +- include/linux/export.h | 104 ++++++++++++++--------------------------- kernel/module.c | 2 +- scripts/mod/modpost.c | 20 ++++---- scripts/nsdeps | 4 +- 5 files changed, 47 insertions(+), 85 deletions(-)