All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Michal Marek <mmarek@suse.cz>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andi Kleen <andi@firstfloor.org>,
	live-patching@vger.kernel.org, X86 ML <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v5 02/10] x86: Compile-time asm code validation
Date: Wed, 10 Jun 2015 17:17:16 -0500	[thread overview]
Message-ID: <20150610221716.GF1125@treble.redhat.com> (raw)
In-Reply-To: <20150610185845.GA1125@treble.redhat.com>

On Wed, Jun 10, 2015 at 01:58:45PM -0500, Josh Poimboeuf wrote:
> On Wed, Jun 10, 2015 at 11:15:19AM -0700, Andy Lutomirski wrote:
> > On Wed, Jun 10, 2015 at 10:53 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > > On Wed, Jun 10, 2015 at 10:21:36AM -0700, Andy Lutomirski wrote:
> > >> GCC can generate those, and the ia32_ptregs_common label is an example
> > >> of such a thing.
> > >>
> > >> I'd rather have the script understand tail calls and possibly require
> > >> that ia32_ptregs_common have a dummy frame pointer save in front
> > >> before the label if needed.
> > >
> > > Why do you prefer tail calls there?  See patch 3 for how I handled that
> > > for ia32_ptregs_common (I duplicated the code with macros).
> > >
> > > I think adding support for tail calls in the tooling would be tricky.
> > > So I'm just trying to figure out if there's a good reason to keep them.
> > 
> > To save code size by deduplicating common tails.  The code currently
> > does that, and it would be nice to avoid bloating the code to keep the
> > validator happy.
> 
> Well, I wonder whether it's really worth sacrificing code readability
> and consistency, and maybe some improved i-cache locality, to save a few
> hundred bytes of code size.

I should also mention that my proposed ia32_ptregs_common patch, which
duplicated the needed code, was more optimized for performance than code
size.

But if you're more worried about code size, we could turn
ia32_ptregs_common into a proper callable function, and then replace

   jmp ia32_ptregs_common

with:

   call ia32_ptregs_common
   ret

So it becomes a regular call instead of a tail call.  It only adds a few
instructions and the function is self-contained.  Would that be good
enough?

-- 
Josh

  reply	other threads:[~2015-06-10 22:17 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-10 12:06 [PATCH v5 00/10] x86/asm: Compile-time asm code validation Josh Poimboeuf
2015-06-10 12:06 ` [PATCH v5 01/10] x86/asm: Add FP_SAVE/RESTORE frame pointer macros Josh Poimboeuf
2015-06-10 18:17   ` Pavel Machek
2015-06-10 18:24     ` Josh Poimboeuf
2015-06-11  4:22     ` Jiri Kosina
2015-06-11  6:46       ` Pavel Machek
2015-06-11 12:06         ` Jiri Kosina
2015-06-11 14:18         ` Josh Poimboeuf
2015-06-10 12:06 ` [PATCH v5 02/10] x86: Compile-time asm code validation Josh Poimboeuf
2015-06-10 17:21   ` Andy Lutomirski
2015-06-10 17:53     ` Josh Poimboeuf
2015-06-10 18:15       ` Andy Lutomirski
2015-06-10 18:58         ` Josh Poimboeuf
2015-06-10 22:17           ` Josh Poimboeuf [this message]
2015-06-11  6:08             ` Ingo Molnar
2015-06-11 14:01               ` Josh Poimboeuf
2015-06-11  6:10           ` Ingo Molnar
2015-06-11 14:10             ` Josh Poimboeuf
2015-06-12 11:18               ` Pedro Alves
2015-06-12 14:10                 ` Josh Poimboeuf
2015-06-12 16:00                   ` Pedro Alves
2015-06-12 16:41                     ` Josh Poimboeuf
2015-06-10 18:16     ` Vojtech Pavlik
2015-06-10 18:18       ` Andy Lutomirski
2015-06-10 12:06 ` [PATCH v5 03/10] x86/asm/entry: Fix asmvalidate warnings for entry_64_compat.S Josh Poimboeuf
2015-06-10 12:06 ` [PATCH v5 04/10] x86/asm/crypto: Fix asmvalidate warnings for aesni-intel_asm.S Josh Poimboeuf
2015-06-10 12:06 ` [PATCH v5 05/10] x86/asm/crypto: Fix asmvalidate warnings for ghash-clmulni-intel_asm.S Josh Poimboeuf
     [not found] ` <cover.1433937132.git.jpoimboe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-10 12:06   ` [PATCH v5 06/10] x86/asm/efi: Fix asmvalidate warnings for efi_stub_64.S Josh Poimboeuf
2015-06-10 12:06     ` Josh Poimboeuf
     [not found]     ` <3e1d9ce523b3174a49b4317cd8b1b85dfd0c319a.1433937132.git.jpoimboe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-11 13:14       ` Matt Fleming
2015-06-11 13:14         ` Matt Fleming
2015-06-12 19:24         ` Borislav Petkov
2015-06-10 12:06 ` [PATCH v5 07/10] x86/asm/acpi: Fix asmvalidate warnings for wakeup_64.S Josh Poimboeuf
2015-06-10 13:19   ` Pavel Machek
2015-06-10 14:08     ` Josh Poimboeuf
2015-06-11 12:36       ` Pavel Machek
2015-06-10 13:21   ` Pavel Machek
2015-06-10 14:13     ` Josh Poimboeuf
2015-06-11  6:13       ` Ingo Molnar
2015-06-10 12:06 ` [PATCH v5 08/10] x86/asm/head: Fix asmvalidate warnings for head_64.S Josh Poimboeuf
2015-06-10 12:06 ` [PATCH v5 09/10] x86/asm/lib: Fix asmvalidate warnings for lib functions Josh Poimboeuf
2015-06-10 12:06 ` [PATCH v5 10/10] x86/asm/lib: Fix asmvalidate warnings for rwsem.S Josh Poimboeuf
2015-06-10 12:16 ` [PATCH v5 00/10] x86/asm: Compile-time asm code validation Josh Poimboeuf
2015-06-10 13:08 ` Andi Kleen
2015-06-10 13:52   ` Josh Poimboeuf
2015-06-10 14:11     ` Andi Kleen
2015-06-10 14:32       ` Josh Poimboeuf
2015-06-10 15:04         ` Andi Kleen
2015-06-10 15:31           ` Josh Poimboeuf
2015-06-10 16:50             ` Josh Poimboeuf
2015-06-10 18:41               ` Andi Kleen
2015-06-10 19:43                 ` Josh Poimboeuf
2015-06-10 18:40             ` Andi Kleen
2015-06-10 19:36               ` Josh Poimboeuf
2015-06-10 19:38                 ` Andy Lutomirski
2015-06-10 19:51                   ` Josh Poimboeuf
2015-06-10 13:42 ` Pavel Machek
2015-06-10 14:20   ` Josh Poimboeuf
2015-06-10 18:24 ` Andy Lutomirski
2015-06-10 20:26   ` Josh Poimboeuf

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=20150610221716.GF1125@treble.redhat.com \
    --to=jpoimboe@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=mmarek@suse.cz \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --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.