Generic Linux architectural discussions
 help / color / mirror / Atom feed
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
>

  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