Re: unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
On Tuesday, December 6, 2016 8:39:53 AM CET Linus Torvalds wrote: > On Tue, Dec 6, 2016 at 5:44 AM, Adam Borowskiwrote: > > On Tue, Dec 06, 2016 at 08:31:01AM -0500, Jan Stancek wrote: > >> Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols > >> to zero") > >> I'm running into issue with kernel built with CONFIG_MODVERSIONS=y > >> and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le). > >> > >> Modules fail to load, for example: > >> > >> [3.163646] Found checksum 0 vs module 4829A47E > >> [3.163787] dm_mod: disagrees about version of symbol memcpy > >> [3.163862] dm_mod: Unknown symbol memcpy (err -22) > >> > >> Bisect led me to 8ab2ae655b, reverting it allows boot to > >> progress as before. > > > > powerpc happens to be the only arch that actually followed the plan and > > implemented asm-prototypes.h (not including Debian which applied my patch to > > do so on x86, that patch is not in mainline). > > > > Could you try reverting commits that add exports to that file? > > Let's not do this. Let's just assume that "checksum=0" matches anything. > > Because it's too late to play games with this any more, and it's too > damn fragile. > > In fact, I think I'll just revert Arnd's patch, and just rely on > commit faaae2a58143 ("Re-enable CONFIG_MODVERSIONS in a slightly > weaker form") for 4.9. > > Because Arnd's patch did explain what was going on, but it also broke > alpha, due to ".set" apparently meaning something else than "set > value" there. So I like Arnd's patch even if it gets reverted, just > because of the "explain things" part. > > Or would people prefer just an explicit "zero in the crc tables means > that it never got filled in correctly, so let's match it"? > > Arnd, comments? I'm not overly attached to my patch, and I intentionally marked it RFC as I had done very little testing on it and I'm not surprised it causes problems. Reverting it for v4.9 seems best if that gets us a working kernel with modversions again on all architectures. In the long run, I'd still hope to to resolve those issues: - without my patch, Nick's patch d8c1eb86e952 ("kbuild: modpost warn if export version crc is missing") in linux-next produces warnings for most architectures with CONFIG_MODVERSIONS=y and binutils-2.27+, and that means we don't get a clean allmodconfig build any more. - I have been sick the past few days and haven't had a chance to investigate exactly what happens that prevents the modules from getting loaded. I assume the problem that Jan sees is the same that Ben Hutchings already reported on Saturday. This might be just another trivial fix, or something more fundamental, but finding this out would be helpful in case we want to bring it back. - If we decide to keep the warning about broken toolchains in the long run and not also make sure that all symbols have a nonzero crc, then we should ask Alan Modra to revert the linker change. Arnd
Re: unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
On Tuesday, December 6, 2016 8:39:53 AM CET Linus Torvalds wrote: > On Tue, Dec 6, 2016 at 5:44 AM, Adam Borowski wrote: > > On Tue, Dec 06, 2016 at 08:31:01AM -0500, Jan Stancek wrote: > >> Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols > >> to zero") > >> I'm running into issue with kernel built with CONFIG_MODVERSIONS=y > >> and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le). > >> > >> Modules fail to load, for example: > >> > >> [3.163646] Found checksum 0 vs module 4829A47E > >> [3.163787] dm_mod: disagrees about version of symbol memcpy > >> [3.163862] dm_mod: Unknown symbol memcpy (err -22) > >> > >> Bisect led me to 8ab2ae655b, reverting it allows boot to > >> progress as before. > > > > powerpc happens to be the only arch that actually followed the plan and > > implemented asm-prototypes.h (not including Debian which applied my patch to > > do so on x86, that patch is not in mainline). > > > > Could you try reverting commits that add exports to that file? > > Let's not do this. Let's just assume that "checksum=0" matches anything. > > Because it's too late to play games with this any more, and it's too > damn fragile. > > In fact, I think I'll just revert Arnd's patch, and just rely on > commit faaae2a58143 ("Re-enable CONFIG_MODVERSIONS in a slightly > weaker form") for 4.9. > > Because Arnd's patch did explain what was going on, but it also broke > alpha, due to ".set" apparently meaning something else than "set > value" there. So I like Arnd's patch even if it gets reverted, just > because of the "explain things" part. > > Or would people prefer just an explicit "zero in the crc tables means > that it never got filled in correctly, so let's match it"? > > Arnd, comments? I'm not overly attached to my patch, and I intentionally marked it RFC as I had done very little testing on it and I'm not surprised it causes problems. Reverting it for v4.9 seems best if that gets us a working kernel with modversions again on all architectures. In the long run, I'd still hope to to resolve those issues: - without my patch, Nick's patch d8c1eb86e952 ("kbuild: modpost warn if export version crc is missing") in linux-next produces warnings for most architectures with CONFIG_MODVERSIONS=y and binutils-2.27+, and that means we don't get a clean allmodconfig build any more. - I have been sick the past few days and haven't had a chance to investigate exactly what happens that prevents the modules from getting loaded. I assume the problem that Jan sees is the same that Ben Hutchings already reported on Saturday. This might be just another trivial fix, or something more fundamental, but finding this out would be helpful in case we want to bring it back. - If we decide to keep the warning about broken toolchains in the long run and not also make sure that all symbols have a nonzero crc, then we should ask Alan Modra to revert the linker change. Arnd
Re: unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
Hi all, just for the record. I was also not able to boot my system. In x86_64 architecture it however worked, only in i686 I had to revert 8ab2ae6 and apply Adam's patch to make it work: https://patchwork.kernel.org/patch/9408985 greez, Philip
Re: unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
Hi all, just for the record. I was also not able to boot my system. In x86_64 architecture it however worked, only in i686 I had to revert 8ab2ae6 and apply Adam's patch to make it work: https://patchwork.kernel.org/patch/9408985 greez, Philip
Re: unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
On Tue, Dec 6, 2016 at 5:44 AM, Adam Borowskiwrote: > On Tue, Dec 06, 2016 at 08:31:01AM -0500, Jan Stancek wrote: >> Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols to >> zero") >> I'm running into issue with kernel built with CONFIG_MODVERSIONS=y >> and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le). >> >> Modules fail to load, for example: >> >> [3.163646] Found checksum 0 vs module 4829A47E >> [3.163787] dm_mod: disagrees about version of symbol memcpy >> [3.163862] dm_mod: Unknown symbol memcpy (err -22) >> >> Bisect led me to 8ab2ae655b, reverting it allows boot to >> progress as before. > > powerpc happens to be the only arch that actually followed the plan and > implemented asm-prototypes.h (not including Debian which applied my patch to > do so on x86, that patch is not in mainline). > > Could you try reverting commits that add exports to that file? Let's not do this. Let's just assume that "checksum=0" matches anything. Because it's too late to play games with this any more, and it's too damn fragile. In fact, I think I'll just revert Arnd's patch, and just rely on commit faaae2a58143 ("Re-enable CONFIG_MODVERSIONS in a slightly weaker form") for 4.9. Because Arnd's patch did explain what was going on, but it also broke alpha, due to ".set" apparently meaning something else than "set value" there. So I like Arnd's patch even if it gets reverted, just because of the "explain things" part. Or would people prefer just an explicit "zero in the crc tables means that it never got filled in correctly, so let's match it"? Arnd, comments? Linus
Re: unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
On Tue, Dec 6, 2016 at 5:44 AM, Adam Borowski wrote: > On Tue, Dec 06, 2016 at 08:31:01AM -0500, Jan Stancek wrote: >> Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols to >> zero") >> I'm running into issue with kernel built with CONFIG_MODVERSIONS=y >> and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le). >> >> Modules fail to load, for example: >> >> [3.163646] Found checksum 0 vs module 4829A47E >> [3.163787] dm_mod: disagrees about version of symbol memcpy >> [3.163862] dm_mod: Unknown symbol memcpy (err -22) >> >> Bisect led me to 8ab2ae655b, reverting it allows boot to >> progress as before. > > powerpc happens to be the only arch that actually followed the plan and > implemented asm-prototypes.h (not including Debian which applied my patch to > do so on x86, that patch is not in mainline). > > Could you try reverting commits that add exports to that file? Let's not do this. Let's just assume that "checksum=0" matches anything. Because it's too late to play games with this any more, and it's too damn fragile. In fact, I think I'll just revert Arnd's patch, and just rely on commit faaae2a58143 ("Re-enable CONFIG_MODVERSIONS in a slightly weaker form") for 4.9. Because Arnd's patch did explain what was going on, but it also broke alpha, due to ".set" apparently meaning something else than "set value" there. So I like Arnd's patch even if it gets reverted, just because of the "explain things" part. Or would people prefer just an explicit "zero in the crc tables means that it never got filled in correctly, so let's match it"? Arnd, comments? Linus
Re: unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
On Tue, Dec 06, 2016 at 08:31:01AM -0500, Jan Stancek wrote: > Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols to > zero") > I'm running into issue with kernel built with CONFIG_MODVERSIONS=y > and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le). > > Modules fail to load, for example: > > [3.163646] Found checksum 0 vs module 4829A47E > [3.163787] dm_mod: disagrees about version of symbol memcpy > [3.163862] dm_mod: Unknown symbol memcpy (err -22) > > Bisect led me to 8ab2ae655b, reverting it allows boot to > progress as before. powerpc happens to be the only arch that actually followed the plan and implemented asm-prototypes.h (not including Debian which applied my patch to do so on x86, that patch is not in mainline). Could you try reverting commits that add exports to that file? -- u-boot problems can be solved with the help of your old SCSI manuals, the parts that deal with goat termination. You need a black-handled knife, and an appropriate set of candles (number and color matters). Or was it a silver-handled knife? Crap, need to look that up.
Re: unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
On Tue, Dec 06, 2016 at 08:31:01AM -0500, Jan Stancek wrote: > Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols to > zero") > I'm running into issue with kernel built with CONFIG_MODVERSIONS=y > and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le). > > Modules fail to load, for example: > > [3.163646] Found checksum 0 vs module 4829A47E > [3.163787] dm_mod: disagrees about version of symbol memcpy > [3.163862] dm_mod: Unknown symbol memcpy (err -22) > > Bisect led me to 8ab2ae655b, reverting it allows boot to > progress as before. powerpc happens to be the only arch that actually followed the plan and implemented asm-prototypes.h (not including Debian which applied my patch to do so on x86, that patch is not in mainline). Could you try reverting commits that add exports to that file? -- u-boot problems can be solved with the help of your old SCSI manuals, the parts that deal with goat termination. You need a black-handled knife, and an appropriate set of candles (number and color matters). Or was it a silver-handled knife? Crap, need to look that up.
unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
Hi, Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols to zero") I'm running into issue with kernel built with CONFIG_MODVERSIONS=y and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le). Modules fail to load, for example: [3.163646] Found checksum 0 vs module 4829A47E [3.163787] dm_mod: disagrees about version of symbol memcpy [3.163862] dm_mod: Unknown symbol memcpy (err -22) Bisect led me to 8ab2ae655b, reverting it allows boot to progress as before. Regards, Jan
unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b
Hi, Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols to zero") I'm running into issue with kernel built with CONFIG_MODVERSIONS=y and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le). Modules fail to load, for example: [3.163646] Found checksum 0 vs module 4829A47E [3.163787] dm_mod: disagrees about version of symbol memcpy [3.163862] dm_mod: Unknown symbol memcpy (err -22) Bisect led me to 8ab2ae655b, reverting it allows boot to progress as before. Regards, Jan