Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1530134 > unrolled thread
| Started by | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| First post | 2016-11-25 12:40 +0100 |
| Last post | 2016-12-01 17:30 +0100 |
| Articles | 5 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols Michael Ellerman <mpe@ellerman.id.au> - 2016-11-25 12:40 +0100
Re: [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-11-25 14:00 +0100
Re: [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols Michael Ellerman <mpe@ellerman.id.au> - 2016-12-01 10:50 +0100
Re: [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-12-01 10:50 +0100
Re: [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-12-01 17:30 +0100
| From | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| Date | 2016-11-25 12:40 +0100 |
| Subject | Re: [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols |
| Message-ID | <sHn1g-8nO-15@gated-at.bofh.it> |
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh > index ec2d5c835170..2f510fbc87da 100755 > --- a/arch/powerpc/relocs_check.sh > +++ b/arch/powerpc/relocs_check.sh > @@ -43,7 +43,8 @@ R_PPC_ADDR16_HA > R_PPC_RELATIVE > R_PPC_NONE' | > grep -E -v '\<R_PPC64_ADDR64[[:space:]]+mach_' | > - grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' > + grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' | > + grep -E -v '\<R_PPC64_ADDR32[[:space:]]+\*ABS\*' I'm still getting: WARNING: 24 bad relocations c000000000d307c4 R_PPC64_ADDR32 __crc___arch_hweight16 c000000000d307c8 R_PPC64_ADDR32 __crc___arch_hweight32 c000000000d307cc R_PPC64_ADDR32 __crc___arch_hweight64 c000000000d307d0 R_PPC64_ADDR32 __crc___arch_hweight8 c000000000d30848 R_PPC64_ADDR32 __crc___bswapdi2 c000000000d30854 R_PPC64_ADDR32 __crc___clear_user c000000000d30868 R_PPC64_ADDR32 __crc___copy_tofrom_user c000000000d30d4c R_PPC64_ADDR32 __crc__mcount c000000000d31344 R_PPC64_ADDR32 __crc_copy_page c000000000d3141c R_PPC64_ADDR32 __crc_current_stack_pointer c000000000d31840 R_PPC64_ADDR32 __crc_empty_zero_page c000000000d31a7c R_PPC64_ADDR32 __crc_flush_dcache_range c000000000d31a84 R_PPC64_ADDR32 __crc_flush_icache_range c000000000d32608 R_PPC64_ADDR32 __crc_load_fp_state c000000000d32614 R_PPC64_ADDR32 __crc_load_vr_state c000000000d32828 R_PPC64_ADDR32 __crc_memchr c000000000d32830 R_PPC64_ADDR32 __crc_memcmp c000000000d32834 R_PPC64_ADDR32 __crc_memcpy c000000000d32840 R_PPC64_ADDR32 __crc_memmove c000000000d32888 R_PPC64_ADDR32 __crc_memset c000000000d33c9c R_PPC64_ADDR32 __crc_store_fp_state c000000000d33ca0 R_PPC64_ADDR32 __crc_store_vr_state c000000000d33cf0 R_PPC64_ADDR32 __crc_strncmp c000000000d33cf4 R_PPC64_ADDR32 __crc_strncpy If I just add those to the whitelist it builds, but then things aren't happy at boot: [ 7.607687] kvm: disagrees about version of symbol module_layout [ 7.846799] virtio: disagrees about version of symbol module_layout [ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout [ 22.012959] libcrc32c: disagrees about version of symbol module_layout cheers
[toc] | [next] | [standalone]
| From | Ard Biesheuvel <ard.biesheuvel@linaro.org> |
|---|---|
| Date | 2016-11-25 14:00 +0100 |
| Message-ID | <sHogG-FW-5@gated-at.bofh.it> |
| In reply to | #1530134 |
On 25 November 2016 at 11:29, Michael Ellerman <mpe@ellerman.id.au> wrote: > Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > >> diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh >> index ec2d5c835170..2f510fbc87da 100755 >> --- a/arch/powerpc/relocs_check.sh >> +++ b/arch/powerpc/relocs_check.sh >> @@ -43,7 +43,8 @@ R_PPC_ADDR16_HA >> R_PPC_RELATIVE >> R_PPC_NONE' | >> grep -E -v '\<R_PPC64_ADDR64[[:space:]]+mach_' | >> - grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' >> + grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' | >> + grep -E -v '\<R_PPC64_ADDR32[[:space:]]+\*ABS\*' > > I'm still getting: > > WARNING: 24 bad relocations > c000000000d307c4 R_PPC64_ADDR32 __crc___arch_hweight16 > c000000000d307c8 R_PPC64_ADDR32 __crc___arch_hweight32 > c000000000d307cc R_PPC64_ADDR32 __crc___arch_hweight64 > c000000000d307d0 R_PPC64_ADDR32 __crc___arch_hweight8 > c000000000d30848 R_PPC64_ADDR32 __crc___bswapdi2 > c000000000d30854 R_PPC64_ADDR32 __crc___clear_user > c000000000d30868 R_PPC64_ADDR32 __crc___copy_tofrom_user > c000000000d30d4c R_PPC64_ADDR32 __crc__mcount > c000000000d31344 R_PPC64_ADDR32 __crc_copy_page > c000000000d3141c R_PPC64_ADDR32 __crc_current_stack_pointer > c000000000d31840 R_PPC64_ADDR32 __crc_empty_zero_page > c000000000d31a7c R_PPC64_ADDR32 __crc_flush_dcache_range > c000000000d31a84 R_PPC64_ADDR32 __crc_flush_icache_range > c000000000d32608 R_PPC64_ADDR32 __crc_load_fp_state > c000000000d32614 R_PPC64_ADDR32 __crc_load_vr_state > c000000000d32828 R_PPC64_ADDR32 __crc_memchr > c000000000d32830 R_PPC64_ADDR32 __crc_memcmp > c000000000d32834 R_PPC64_ADDR32 __crc_memcpy > c000000000d32840 R_PPC64_ADDR32 __crc_memmove > c000000000d32888 R_PPC64_ADDR32 __crc_memset > c000000000d33c9c R_PPC64_ADDR32 __crc_store_fp_state > c000000000d33ca0 R_PPC64_ADDR32 __crc_store_vr_state > c000000000d33cf0 R_PPC64_ADDR32 __crc_strncmp > c000000000d33cf4 R_PPC64_ADDR32 __crc_strncpy > Ah right, my bad. The regex above should switch to ADDR32 as well for __crc_ symbols. > > If I just add those to the whitelist it builds, but then things aren't > happy at boot: > > > [ 7.607687] kvm: disagrees about version of symbol module_layout > [ 7.846799] virtio: disagrees about version of symbol module_layout > [ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout > [ 22.012959] libcrc32c: disagrees about version of symbol module_layout > Sigh. I suppose your modversions fixes are queued for v4.10? It's probably best to revisit this after the v4.10 merge window closes then, just to make sure I'm not aiming for a moving target. Thanks, Ard.
[toc] | [prev] | [next] | [standalone]
| From | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| Date | 2016-12-01 10:50 +0100 |
| Message-ID | <sJwa6-26V-17@gated-at.bofh.it> |
| In reply to | #1530195 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > On 25 November 2016 at 11:29, Michael Ellerman <mpe@ellerman.id.au> wrote: >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >> >> [ 7.607687] kvm: disagrees about version of symbol module_layout >> [ 7.846799] virtio: disagrees about version of symbol module_layout >> [ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout >> [ 22.012959] libcrc32c: disagrees about version of symbol module_layout >> > > Sigh. I suppose your modversions fixes are queued for v4.10? It's > probably best to revisit this after the v4.10 merge window closes > then, just to make sure I'm not aiming for a moving target. Actually they were merged into 4.9-rc7 ish. But I'm still seeing the same as above with this series rebased on top of that, and I'm a bit short on time to debug it ATM. So during the 4.10 cycle is probably the best we can hope for, sorry. cheers
[toc] | [prev] | [next] | [standalone]
| From | Ard Biesheuvel <ard.biesheuvel@linaro.org> |
|---|---|
| Date | 2016-12-01 10:50 +0100 |
| Message-ID | <sJwa6-26V-23@gated-at.bofh.it> |
| In reply to | #1533936 |
On 1 December 2016 at 09:39, Michael Ellerman <mpe@ellerman.id.au> wrote: > Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >> On 25 November 2016 at 11:29, Michael Ellerman <mpe@ellerman.id.au> wrote: >>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >>> >>> [ 7.607687] kvm: disagrees about version of symbol module_layout >>> [ 7.846799] virtio: disagrees about version of symbol module_layout >>> [ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout >>> [ 22.012959] libcrc32c: disagrees about version of symbol module_layout >>> >> >> Sigh. I suppose your modversions fixes are queued for v4.10? It's >> probably best to revisit this after the v4.10 merge window closes >> then, just to make sure I'm not aiming for a moving target. > > Actually they were merged into 4.9-rc7 ish. > > But I'm still seeing the same as above with this series rebased on top > of that, and I'm a bit short on time to debug it ATM. > > So during the 4.10 cycle is probably the best we can hope for, sorry. > Not a problem. The only question is whether 1/3 of this series fixes an actual bug or not, given that the CONFIG_RELOCATABLE workaround has been made ppc64 only. But for the remaining patches, I'm happy to respin after the v4.10 merge window closes, and get something queued for v4.11 -- Ard.
[toc] | [prev] | [next] | [standalone]
| From | Ard Biesheuvel <ard.biesheuvel@linaro.org> |
|---|---|
| Date | 2016-12-01 17:30 +0100 |
| Message-ID | <sJCpb-6q6-3@gated-at.bofh.it> |
| In reply to | #1533937 |
On 1 December 2016 at 09:45, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 1 December 2016 at 09:39, Michael Ellerman <mpe@ellerman.id.au> wrote: >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >>> On 25 November 2016 at 11:29, Michael Ellerman <mpe@ellerman.id.au> wrote: >>>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >>>> >>>> [ 7.607687] kvm: disagrees about version of symbol module_layout >>>> [ 7.846799] virtio: disagrees about version of symbol module_layout >>>> [ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout >>>> [ 22.012959] libcrc32c: disagrees about version of symbol module_layout >>>> >>> >>> Sigh. I suppose your modversions fixes are queued for v4.10? It's >>> probably best to revisit this after the v4.10 merge window closes >>> then, just to make sure I'm not aiming for a moving target. >> >> Actually they were merged into 4.9-rc7 ish. >> >> But I'm still seeing the same as above with this series rebased on top >> of that, and I'm a bit short on time to debug it ATM. >> >> So during the 4.10 cycle is probably the best we can hope for, sorry. >> > > Not a problem. The only question is whether 1/3 of this series fixes > an actual bug or not, given that the CONFIG_RELOCATABLE workaround has > been made ppc64 only. > > But for the remaining patches, I'm happy to respin after the v4.10 > merge window closes, and get something queued for v4.11 > Actually, given the uncertain fate of modversions in general, we may no longer have to bother by the time the v4.11 merge window opens ...
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web