All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Matt Fleming <matt@console-pimps.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>,
	Ulf Winkelvos <ulf@winkelvos.de>,
	Matt Fleming <matt.fleming@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	Seth Forshee <seth.forshee@canonical.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches
Date: Wed, 03 Sep 2014 14:47:32 -0700	[thread overview]
Message-ID: <54078C74.2060804@zytor.com> (raw)
In-Reply-To: <20140903175948.GH3001@console-pimps.org>

> 
> Any reason we can't reuse the existing GOT fixup code in the early x86
> boot code? We're not executing it before the EFI boot stub atm, which is
> the reason Maarten is hitting these difficulties.
> 
> Maarten, does the following help?
> 
> If not, Ard please go ahead with option #2 above. Overkill yes, but I've
> done the single __attribute__() hacks in other projects and someone
> (usually me) always eventually forgets to tag some instance.
> 

I think we really have two options: either fix up the GOT (which may be
a null operation, if the GOT is empty) or we add a compile-time check
that the GOT is empty, lest we will keep having these problems.

Since the GOT fixup loop is only a few instructions, it doesn't seem to
be all that problematic to just do it -- but make sure we don't end up
running it twice on any code path!

	-hpa


WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
To: Matt Fleming
	<matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>,
	Ard Biesheuvel
	<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Maarten Lankhorst
	<maarten.lankhorst-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Ulf Winkelvos <ulf-rS3t9PEbhQ0OIzVOb1FTxg@public.gmane.org>,
	Matt Fleming
	<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
	<x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Seth Forshee
	<seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
Subject: Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches
Date: Wed, 03 Sep 2014 14:47:32 -0700	[thread overview]
Message-ID: <54078C74.2060804@zytor.com> (raw)
In-Reply-To: <20140903175948.GH3001-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>

> 
> Any reason we can't reuse the existing GOT fixup code in the early x86
> boot code? We're not executing it before the EFI boot stub atm, which is
> the reason Maarten is hitting these difficulties.
> 
> Maarten, does the following help?
> 
> If not, Ard please go ahead with option #2 above. Overkill yes, but I've
> done the single __attribute__() hacks in other projects and someone
> (usually me) always eventually forgets to tag some instance.
> 

I think we really have two options: either fix up the GOT (which may be
a null operation, if the GOT is empty) or we add a compile-time check
that the GOT is empty, lest we will keep having these problems.

Since the GOT fixup loop is only a few instructions, it doesn't seem to
be all that problematic to just do it -- but make sure we don't end up
running it twice on any code path!

	-hpa

  parent reply	other threads:[~2014-09-03 21:47 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-02 15:25 [REGRESSION] "efi: efistub: Convert into static library" and preparation patches Maarten Lankhorst
2014-09-02 15:25 ` Maarten Lankhorst
2014-09-02 19:29 ` Matt Fleming
2014-09-03  6:06   ` Ard Biesheuvel
2014-09-03  8:27     ` Maarten Lankhorst
2014-09-03  8:27       ` Maarten Lankhorst
2014-09-03 12:18       ` Ard Biesheuvel
2014-09-03 12:18         ` Ard Biesheuvel
2014-09-03 15:30         ` Maarten Lankhorst
2014-09-03 15:37           ` Ard Biesheuvel
2014-09-03 15:37             ` Ard Biesheuvel
2014-09-03 17:59             ` Matt Fleming
2014-09-03 17:59               ` Matt Fleming
2014-09-03 19:57               ` Ard Biesheuvel
2014-09-03 19:57                 ` Ard Biesheuvel
2014-09-03 21:28                 ` H. Peter Anvin
2014-09-03 21:28                   ` H. Peter Anvin
2014-09-04 10:48                 ` Maarten Lankhorst
2014-09-04 10:48                   ` Maarten Lankhorst
2014-09-04 11:19                   ` Ard Biesheuvel
2014-09-04 11:19                     ` Ard Biesheuvel
2014-09-04 11:24                     ` Maarten Lankhorst
2014-09-04 11:24                       ` Maarten Lankhorst
2014-09-04 12:54                   ` Michael Brown
2014-09-04 12:54                     ` Michael Brown
2014-09-04 19:12                     ` Ard Biesheuvel
2014-09-04 19:12                       ` Ard Biesheuvel
2014-09-04 21:25                       ` Ard Biesheuvel
2014-09-04 21:37                         ` Matt Fleming
2014-09-04 21:37                           ` Matt Fleming
2014-09-05 20:27                           ` Matt Fleming
2014-09-05 20:27                             ` Matt Fleming
2014-09-08 12:55                             ` Ard Biesheuvel
2014-09-08 12:55                               ` Ard Biesheuvel
2014-09-08 13:01                               ` Maarten Lankhorst
2014-09-08 13:01                                 ` Maarten Lankhorst
2014-09-08 13:16                                 ` Matt Fleming
2014-09-22 18:44                             ` Josh Boyer
2014-09-22 21:07                               ` Matt Fleming
2014-09-22 21:24                                 ` Josh Boyer
2014-09-03 21:47               ` H. Peter Anvin [this message]
2014-09-03 21:47                 ` H. Peter Anvin
2014-09-04  6:47                 ` Ard Biesheuvel
2014-09-04  6:47                   ` Ard Biesheuvel
2014-09-04  7:40                   ` Matt Fleming
2014-09-04  7:50                     ` Maarten Lankhorst
2014-09-04  7:29                 ` Matt Fleming

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=54078C74.2060804@zytor.com \
    --to=hpa@zytor.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@canonical.com \
    --cc=matt.fleming@intel.com \
    --cc=matt@console-pimps.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=seth.forshee@canonical.com \
    --cc=ulf@winkelvos.de \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.