Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 22 Mar 2017 14:11:12 -0700
From: Thomas Garnier <>
To: "H. Peter Anvin" <>
Cc: Andy Lutomirski <>, Ingo Molnar <>, 
	Martin Schwidefsky <>, Heiko Carstens <>, 
	David Howells <>, Arnd Bergmann <>, Al Viro <>, 
	Dave Hansen <>, René Nyffenegger <>, 
	Andrew Morton <>, Kees Cook <>, 
	"Paul E . McKenney" <>, Andy Lutomirski <>, 
	Ard Biesheuvel <>, Nicolas Pitre <>, 
	Petr Mladek <>, Sebastian Andrzej Siewior <>, 
	Sergey Senozhatsky <>, Helge Deller <>, 
	Rik van Riel <>, John Stultz <>, 
	Thomas Gleixner <>, Oleg Nesterov <>, 
	Stephen Smalley <>, Pavel Tikhomirov <>, 
	Frederic Weisbecker <>, Stanislav Kinsburskiy <>, 
	Ingo Molnar <>, Paolo Bonzini <>, 
	Dmitry Safonov <>, Borislav Petkov <>, 
	Josh Poimboeuf <>, Brian Gerst <>, Jan Beulich <>, 
	Christian Borntraeger <>, Fenghua Yu <>, 
	He Chen <>, Russell King <>, 
	Vladimir Murzin <>, Will Deacon <>, 
	Catalin Marinas <>, Mark Rutland <>, 
	James Morse <>, "David A . Long" <>, 
	Pratyush Anand <>, Laura Abbott <>, 
	Andre Przywara <>, Chris Metcalf <>, 
	linux-s390 <>, LKML <>, 
	Linux API <>, "the arch/x86 maintainers" <>, 
	"" <>, 
	Kernel Hardening <>
Subject: Re: [PATCH v3 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On Wed, Mar 22, 2017 at 1:49 PM, H. Peter Anvin <> wrote:
> On 03/22/17 13:41, Thomas Garnier wrote:
>>>> with the change below for additional feedback.
>>> Can you specify what that means?
>> If I set inline by default, the compiler chose not to inline it on
>> x86. If I force inline the size impact was actually bigger (without
>> the architecture specific code).
> That's utterly bizarre.  Something strange is going on there.  I suspect
> the right thing to do is to out-of-line the error case only, but even
> that seems strange.  It should be something like four instructions inline.

The compiler seemed to often inline other functions called by the
syscall handlers. I assume the growth was due to changes in code
optimization because the function is much larger at the end.

>>> On x86, where there is only one caller of this, it really seems like it
>>> ought to reduce the overhead to almost zero (since it most likely is
>>> hidden in the pipeline.)
>>> I would like to suggest defining it inline if
>>> care about an architecture which doesn't have it.
>> But if there is only one caller, does the compiler is not suppose to
>> inline the function based on options?
> If it is marked static in the same file, yes, but you have it in a
> different file from what I can tell.

If we do global optimization, it should. Having it as a static inline
make it easier on all types of builds.

>> The assembly will call it too, so I would need an inline and a
>> non-inline based on the caller.
> Where?  I don't see that anywhere, at least for x86.

After the latest changes on x86, yes. On arm/arm64, we call it with

>         -hpa


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.