Re: [GIT PULL] kbuild changes for v4.9-rc1

From: Nicholas Piggin
Date: Thu Oct 27 2016 - 10:35:53 EST


On Thu, 27 Oct 2016 16:14:28 +0300
Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:

> Nicholas Piggin <npiggin@xxxxxxxxx> writes:
>
> > On Thu, 27 Oct 2016 11:10:03 +0300
> > Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
> >
> >> (Adding Thorsten because of a serious regression and Steven because he
> >> tried to fix something in the same commit)
> >>
> >> Nicholas Piggin <npiggin@xxxxxxxxx> writes:
> >>
> >> > On Wed, 19 Oct 2016 16:38:14 +0200
> >> > Michal Marek <mmarek@xxxxxxxx> wrote:
> >> >
> >> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):
> >> >> > We should probably just bring all these arch patches through the
> >> >> > kbuild tree.
> >> >> >
> >> >> > I'm sorry for the breakage: I didn't realize it broke the build with
> >> >> > some configs, otherwise I would have given Michal a heads up before
> >> >> > his pull request, and worked to get this stuff in first.
> >> >>
> >> >> It breaks with some binutils versions only (and only with
> >> >> CONFIG_MODVERSIONS=y, of course).
> >> >
> >> > Yeah this seems to be the issue, it apparently slipped past all the
> >> > automated builds. It seems like the existing CRC warnings in the tree
> >> > only trigger in rare circumstances too, so something could be a bit
> >> > fragile there.
> >>
> >> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
> >> load (log below). After investigating for some time I found this thread
> >> and apparently this is not still fixed, at least not in Linus' tree.
> >>
> >> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
> >> available (please correct me if I'm wrong) we should just revert that
> >> commit until it's properly fixed.
> >
> > With these two patches together, does it work for you?
> >
> > http://marc.info/?l=linux-arch&m=147653546809512&w=2
> > http://marc.info/?l=linux-kernel&m=147669851906489&w=2
> >
> > It would be helpful if you could test and let us know, because there seems
> > to be a very tiny number of configs and toolchains that causes
> > problems.
>
> With these two patches (on top of ath-201610251249 from ath.git, in
> practice 4.9-rc2 + latest wireless patches) module loading works again.
> If you want you can add my Tested-by:
>
> Tested-by: Kalle Valo <kvalo@xxxxxxxxxxxxxx>

Great, thanks for testing it.

> Can we get these patches to Linus' tree soon? It's annoying to revert
> 784d5699eddc5 everytime I update my tree.

Yes I think it's about ready to merge. Michal is returning from vacation
next week so we should get some progress soon.

> >> Also note that there's a related fix from Steven:
> >>
> >> [PATCH] x86: Fix export for mcount and __fentry__
> >> https://marc.info/?l=linux-kernel&m=147733572502413
> >>
> >> For compiling the kernel I'm using Ubuntu 12.04:
> >>
> >> ii binutils 2.22-6ubuntu1.4 GNU assembler, linker and binary utilities
> >> ii gcc 4:4.6.3-1ubuntu5 GNU C compiler
> >>
> >> The kernel is running on a separate machine with Ubuntu 14.04.
> >>
> >> [ 110.703414] bluetooth: disagrees about version of symbol __get_user_2
> >> [ 110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
> >> [ 110.703429] bluetooth: disagrees about version of symbol __put_user_2
> >> [ 110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
> >> [ 110.703579] bluetooth: disagrees about version of symbol __put_user_4
> >> [ 110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
> >> [ 110.703669] bluetooth: disagrees about version of symbol __put_user_1
> >> [ 110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
> >> [ 110.703688] bluetooth: disagrees about version of symbol mcount
> >> [ 110.703689] bluetooth: Unknown symbol mcount (err -22)
> >>
> >
> > I haven't seen that one before. Did you definitely make and install new
> > modules?
>
> I'm pretty sure modules are correctly installed as I have used the same
> procedure for years: on my workstation I do 'make bindeb-pkg', copy the
> .deb to the test laptop and install the deb there. Also once I revert
> 784d5699eddc5 it starts immeadiately working.
>

Sure, I was just checking because I've seen several types of failure but
not this one before. Thanks for reporting and testing.

Thanks,
Nick