linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled
Date: Tue, 24 Oct 2017 10:54:44 +0100	[thread overview]
Message-ID: <20171024095443.GC20805@n2100.armlinux.org.uk> (raw)
In-Reply-To: <CAKv+Gu_XBDaOnOQSz12ZWnTaa1gjHO5zH0Gk3TpPo8+-F_wAxg@mail.gmail.com>

On Tue, Oct 24, 2017 at 10:44:00AM +0100, Ard Biesheuvel wrote:
> On 24 October 2017 at 10:38, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > Do you have any preference - I'd prefer one that I can merge along with
> > these changes?  One way forward would be to temporarily add the /DISCARD/
> > for the ksym sections, which can then be removed once your sort() removal
> > gets added to the EFI trees.
> >
> 
> Well, I can respin that patch to only discard the ksymtab/kcrctab
> sections (and drop the alignment of piggydata), but I'd prefer to make
> it permanent if you don't mind. I still intend to remove the sort()
> call, given that ARM doesn't need it, but it seems more future proof
> to me to always discard those sections, and if we end up incorporating
> more core kernel code into the EFI stub, we won't need to revisit this
> (although I am not aware of any reasons why we would be doing that in
> the near future)

I don't think it's future-proof.  The decompressor is a particularly
special environment due to its runtime relocation support, where we
(eg) don't really support initialised pointers in the .data section.
Stuffing code from other parts of the kernel into the decompressor
isn't going to work reliably, and I'd much rather discourage the
practice.

Hence, there's really no reason to keep that discard, and I'd much
rather have the build fail if the sections re-appear as a pointer
towards something not being correct.

A solution to this would be to link the decompressor ELF with -r
and wrap that up in a mini-linker, but I suspect that will need
quite a re-write because of the self-relocation that the image
does if it detects overlap between itself and the destination for
the decompressed kernel image.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

  reply	other threads:[~2017-10-24  9:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18  5:01 [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled Jeffy Chen
2017-10-18  6:19 ` Chris Zhong
2017-10-22 11:01 ` Ard Biesheuvel
2017-10-22 12:47   ` Russell King - ARM Linux
2017-10-22 13:01     ` Ard Biesheuvel
2017-10-23  3:26       ` jeffy
2017-10-23  8:50         ` Russell King - ARM Linux
2017-10-23 10:24           ` jeffy
2017-10-23 10:50             ` Russell King - ARM Linux
2017-10-23 11:45               ` Russell King - ARM Linux
2017-10-24  8:09                 ` Ard Biesheuvel
2017-10-24  9:09                   ` Russell King - ARM Linux
2017-10-24  9:13                     ` Ard Biesheuvel
2017-10-24  9:22                       ` Russell King - ARM Linux
2017-10-24  9:26                         ` Ard Biesheuvel
2017-10-24  9:30                           ` Ard Biesheuvel
2017-10-24  9:38                             ` Russell King - ARM Linux
2017-10-24  9:44                               ` Ard Biesheuvel
2017-10-24  9:54                                 ` Russell King - ARM Linux [this message]
2017-10-24 10:03                                   ` Ard Biesheuvel
2017-10-24  9:16                   ` jeffy

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=20171024095443.GC20805@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).