From: Jessica Yu <jeyu@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
arnd@arndb.de, rusty@rustcorp.com.au, mpe@ellerman.id.au,
viro@zeniv.linux.org.uk, linux-arm-kernel@lists.infradead.org,
linux@armlinux.org.uk, linux-arch@vger.kernel.org
Subject: Re: modversions: redefine kcrctab entries as 32-bit values
Date: Thu, 2 Feb 2017 22:54:41 -0500 [thread overview]
Message-ID: <20170203035441.GA2964@packer-debian-8-amd64.digitalocean.com> (raw)
In-Reply-To: <1485274600-21976-1-git-send-email-ard.biesheuvel@linaro.org>
+++ Ard Biesheuvel [24/01/17 16:16 +0000]:
>This v4 is a followup to [0] 'modversions: redefine kcrctab entries as
>relative CRC pointers', but since relative CRC pointers do not work in
>modules, and are actually only needed by powerpc with CONFIG_RELOCATABLE=y,
>I have made it a Kconfig selectable feature instead.
>
>Patch #1 introduces the MODULE_REL_CRCS Kconfig symbol, and adds the kbuild
>handling of it, i.e., modpost, genksyms and kallsyms.
>
>Patch #2 switches all architectures to 32-bit CRC entries in kcrctab, where
>all architectures except powerpc with CONFIG_RELOCATABLE=y use absolute ELF
>symbol references as before.
>
>v4: make relative CRCs kconfig selectable
> use absolute CRC symbols in modules regardless of kconfig selection
> split into two patches
This asymmetry threw me off a bit, especially the Kconfig naming (only
vmlinux crcs get the relative offsets, and only on powerpc atm, but all
modules keep the absolute syms, but it is called MODULE_REL_CRCS...),
if we keep this asymmetric crc treatment, it would be really nice to
note this discrepancy this somewhere, perhaps in the Kconfig, to keep
our heads from spinning :-)
I'm still catching up on the previous discussion threads, but can you
explain a bit more why you switched away from full blown relative crcs
from your last patchset [1]? I had lightly tested your v3 on ppc64le
previously, and relative offsets with modules seemed to worked very
well. I'm probably missing something very obvious.
[1] http://marc.info/?l=linux-arch&m=148493613415294&w=2
>v3: emit CRCs into .rodata rather than .rodata.modver, given that the latter
> will be emitted with read-write permissions, making the CRCs end up in a
> writable module segment.
>
> fold the modpost fix to ensure that the section address is only substracted
> from the symbol address when the ELF object in question is fully linked
> (i.e., ET_DYN or ET_EXEC, and not ET_REL)
>
>v2: update modpost as well, so that genksyms no longer has to emit symbols
> for both the actual CRC value and the reference to where it is stored
> in the image
>
>[0] http://marc.info/?l=linux-arch&m=148493613415294&w=2
>
>Ard Biesheuvel (2):
> kbuild: modversions: add infrastructure for emitting relative CRCs
> modversions: treat symbol CRCs as 32 bit quantities
>
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/module.h | 4 --
> arch/powerpc/kernel/module_64.c | 8 ----
> include/asm-generic/export.h | 11 ++---
> include/linux/export.h | 14 ++++++
> include/linux/module.h | 14 +++---
> init/Kconfig | 4 ++
> kernel/module.c | 45 ++++++++++----------
> scripts/Makefile.build | 2 +
> scripts/genksyms/genksyms.c | 19 ++++++---
> scripts/kallsyms.c | 12 ++++++
> scripts/mod/modpost.c | 10 +++++
> 12 files changed, 93 insertions(+), 51 deletions(-)
>
>--
>2.7.4
>
next prev parent reply other threads:[~2017-02-03 3:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-24 16:16 [PATCH v4 0/2] modversions: redefine kcrctab entries as 32-bit values Ard Biesheuvel
2017-01-24 16:16 ` [PATCH v4 1/2] kbuild: modversions: add infrastructure for emitting relative CRCs Ard Biesheuvel
2017-01-24 16:16 ` Ard Biesheuvel
2017-01-24 16:16 ` [PATCH v4 2/2] modversions: treat symbol CRCs as 32 bit quantities Ard Biesheuvel
2017-01-27 16:13 ` [PATCH v4 0/2] modversions: redefine kcrctab entries as 32-bit values Ard Biesheuvel
2017-01-27 16:13 ` Ard Biesheuvel
2017-02-03 3:54 ` Jessica Yu [this message]
2017-02-03 5:09 ` Jessica Yu
2017-02-03 8:31 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170203035441.GA2964@packer-debian-8-amd64.digitalocean.com \
--to=jeyu@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox