Re: [PATCH v2 0/4] Static calls

2018-12-05 Thread Josh Poimboeuf
On Tue, Dec 04, 2018 at 03:41:01PM -0800, Andy Lutomirski wrote: > > > > On Dec 4, 2018, at 3:08 PM, Steven Rostedt wrote: > > > > > > Where did this end up BTW? > > > > I know that there's controversy about the > > CONFIG_HAVE_STATIC_CALL_OPTIMIZED option, but I don't think the > >

Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion

2018-12-01 Thread Josh Poimboeuf
On Sat, Dec 01, 2018 at 06:52:45AM +, Nadav Amit wrote: > > On Nov 29, 2018, at 7:19 AM, Josh Poimboeuf wrote: > > > > On Wed, Nov 28, 2018 at 10:06:52PM -0800, Andy Lutomirski wrote: > >> On Wed, Nov 28, 2018 at 7:24 PM Andy Lutomirski > >> wrote: >

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-30 Thread Josh Poimboeuf
On Fri, Nov 30, 2018 at 11:16:34PM +0100, Rasmus Villemoes wrote: > On 29/11/2018 20.22, Josh Poimboeuf wrote: > > On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote: > >>> and honestly, the way "static_call()" works now, can you guarantee > >>&

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-30 Thread Josh Poimboeuf
On Fri, Nov 30, 2018 at 12:18:33PM -0800, Andy Lutomirski wrote: > On Fri, Nov 30, 2018 at 11:51 AM Linus Torvalds > wrote: > > > > On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote: > > > > > > AFAICT, all the other proposed options seem to have majo

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-30 Thread Josh Poimboeuf
On Fri, Nov 30, 2018 at 08:42:26AM -0800, Andy Lutomirski wrote: > On Thu, Nov 29, 2018 at 12:24 PM Josh Poimboeuf wrote: > > > > > Alternatively, we could actually emulate call instructions like this: > > > > > > void __noreturn jump_to

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-30 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 03:04:20PM -0800, Linus Torvalds wrote: > On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf wrote: > > > > On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote: > > > > > > I propose a different solution: > > > &g

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 02:25:33PM -0800, Andy Lutomirski wrote: > On Thu, Nov 29, 2018 at 2:22 PM Peter Zijlstra wrote: > > > > On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote: > > > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote: > >

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 02:24:52PM -0600, Josh Poimboeuf wrote: > On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote: > > On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds > > wrote: > > > > > > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds > >

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote: > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote: > > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote: > > > > (like pointing IP at a stub that retpolines to the target by readi

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote: > On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds > wrote: > > > > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds > > wrote: > > > > > > In contrast, if the call was wrapped in an inline asm, we'd *know* the > > > compiler

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 10:58:40AM -0800, Linus Torvalds wrote: > On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote: > > > > Note, we do have a bit of control at what is getting called. The patch > > set requires that the callers are wrapped in macros. We should not > > allow just any random

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote: > > and honestly, the way "static_call()" works now, can you guarantee > > that the call-site doesn't end up doing that, and calling the > > trampoline function for two different static calls from one indirect > > call? > > > > See

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 06:15:39PM +0100, Peter Zijlstra wrote: > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote: > > > If you make it conditional on CPL, do it for 32-bit as well, add > > comments, > > > and convince yourself that there isn’t a better solution > > (like

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote: > > > On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote: > > > > On Thu, 29 Nov 2018 12:20:00 -0500 > > Steven Rostedt wrote: > > > > > >> r8 = return address > >> r9 = function to call > >> > > > > Bad example, r8 and r9 are

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote: > > > > On Nov 29, 2018, at 8:49 AM, Peter Zijlstra wrote: > > > > On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote: > >>> can't we 'fix' that again? The alternative is mov

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 03:38:53PM +0100, Peter Zijlstra wrote: > On Thu, Nov 29, 2018 at 05:37:39AM -0800, Andy Lutomirski wrote: > > > > > > > On Nov 29, 2018, at 1:42 AM, Peter Zijlstra wrote: > > > > > > On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote: > > > > >

Re: [PATCH v2] x86/tools/relocs: fix big section header tables

2018-11-29 Thread Josh Poimboeuf
m. > Same with the string table index which is located in sh_link instead of > e_shstrndx. > > This case is easily reproducible with KCFLAGS="-ffunction-sections", > bzImage build fails with "String table index out of bounds" error. > > Signed-off-by: Artem Savkov Reviewed-by: Josh Poimboeuf -- Josh

Re: [PATCH] x86/tools/relocs: fix big section header tables

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 04:22:00PM +0100, Artem Savkov wrote: > On Thu, Nov 29, 2018 at 08:23:12AM -0600, Josh Poimboeuf wrote: > > On Thu, Nov 29, 2018 at 02:51:33PM +0100, Artem Savkov wrote: > > > In case when the number of entries in the section header table is larger &

Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion

2018-11-29 Thread Josh Poimboeuf
t;> > > >>> On Wed, Nov 28, 2018 at 4:38 PM Josh Poimboeuf > > >>> wrote: > > >>> On Wed, Nov 28, 2018 at 07:34:52PM +, Nadav Amit wrote: > > >>>>> On Nov 28, 2018, at 8:08 AM, Josh Poimboeuf > > >>>>

Re: [PATCH] x86/tools/relocs: fix big section header tables

2018-11-29 Thread Josh Poimboeuf
ther variables. > +static unsigned long shnum; > +static unsigned int shstrndx; Otherwise the patch looks good to me. Reviewed-by: Josh Poimboeuf -- Josh

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Josh Poimboeuf
On Thu, Nov 29, 2018 at 10:42:10AM +0100, Peter Zijlstra wrote: > On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote: > > > >> +static void static_call_bp_handler(struct pt_regs *regs, void *_data) > > >> +{ > > >> +struct static_call_bp_data *data = _data; > > >> + > > >> +

Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion

2018-11-28 Thread Josh Poimboeuf
On Wed, Nov 28, 2018 at 07:24:08PM -0800, Andy Lutomirski wrote: > To be clear, that wasn’t a NAK. It was merely a “this is alarming.” > > Hey Josh - you could potentially do the same hack to generate the > static call tables. Take that, objtool. Ha, after witnessing Nadav's glorious hack, I

Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion

2018-11-28 Thread Josh Poimboeuf
On Wed, Nov 28, 2018 at 07:34:52PM +, Nadav Amit wrote: > > On Nov 28, 2018, at 8:08 AM, Josh Poimboeuf wrote: > > > > On Wed, Oct 17, 2018 at 05:54:15PM -0700, Nadav Amit wrote: > >> This RFC introduces indirect call promotion in runtime, which for the &g

Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion

2018-11-28 Thread Josh Poimboeuf
On Wed, Oct 17, 2018 at 05:54:15PM -0700, Nadav Amit wrote: > This RFC introduces indirect call promotion in runtime, which for the > matter of simplification (and branding) will be called here "relpolines" > (relative call + trampoline). Relpolines are mainly intended as a way > of reducing

Re: [PATCH v2 0/4] Static calls

2018-11-26 Thread Josh Poimboeuf
On Mon, Nov 26, 2018 at 03:54:05PM -0500, Steven Rostedt wrote: > In summary, we had this: > > No RETPOLINES: > 1.4503 +- 0.0148 seconds time elapsed ( +- 1.02% ) > > baseline RETPOLINES: > 1.5120 +- 0.0133 seconds time elapsed ( +- 0.88% ) > > Added direct calls for

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Josh Poimboeuf
On Mon, Nov 26, 2018 at 09:08:01PM +0100, Peter Zijlstra wrote: > On Mon, Nov 26, 2018 at 11:56:24AM -0600, Josh Poimboeuf wrote: > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c > > index d3869295b88d..8fd6c8556750 100644 > > --- a/arch/x86

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Josh Poimboeuf
On Mon, Nov 26, 2018 at 10:28:08AM -0800, Andy Lutomirski wrote: > On Mon, Nov 26, 2018 at 9:10 AM Josh Poimboeuf wrote: > > > > On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote: > > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote: >

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Josh Poimboeuf
On Mon, Nov 26, 2018 at 11:10:36AM -0600, Josh Poimboeuf wrote: > On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote: > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote: > > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Josh Poimboeuf
On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote: > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote: > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c > > index 8026d176f25c..d3869295b88d 100644 > > --- a/arch/x86

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Josh Poimboeuf
On Mon, Nov 26, 2018 at 05:39:23PM +0100, Peter Zijlstra wrote: > On Mon, Nov 26, 2018 at 05:11:05PM +0100, Ard Biesheuvel wrote: > > On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra wrote: > > > > > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimb

Re: [PATCH v2 0/4] Static calls

2018-11-26 Thread Josh Poimboeuf
On Mon, Nov 26, 2018 at 07:54:56AM -0600, Josh Poimboeuf wrote: > v2: > - fix STATIC_CALL_TRAMP() macro by using __PASTE() [Ard] > - rename optimized/unoptimized -> inline/out-of-line [Ard] > - tweak arch interfaces for PLT and add key->tramp field [Ard] > - rename 'poiso

[PATCH v2 3/4] x86/static_call: Add out-of-line static call implementation

2018-11-26 Thread Josh Poimboeuf
-by: Josh Poimboeuf --- arch/x86/Kconfig | 1 + arch/x86/include/asm/static_call.h | 28 arch/x86/kernel/Makefile | 1 + arch/x86/kernel/static_call.c | 54 ++ include/linux/static_call.h| 2 +- 5 files changed, 85

[PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Josh Poimboeuf
those call sites in the .static_call_sites section. During boot (and module init), the call sites are patched to call directly into the destination function. The temporary trampoline is then no longer used. Signed-off-by: Josh Poimboeuf --- arch/x86/Kconfig | 5

[PATCH v2 2/4] static_call: Add static call infrastructure

2018-11-26 Thread Josh Poimboeuf
rampolines (CONFIG_HAVE_STATIC_CALL_OUTLINE) 3) basic function pointers For more details, see the comments in include/linux/static_call.h. Signed-off-by: Josh Poimboeuf --- arch/Kconfig | 10 + include/asm-generic/vmlinux.lds.h | 11 + include/linux/module.h| 10 + include/linux/sta

[PATCH v2 0/4] Static calls

2018-11-26 Thread Josh Poimboeuf
rts: 1) CONFIG_HAVE_STATIC_CALL_INLINE: patched call sites - requires objtool and a small amount of arch code 2) CONFIG_HAVE_STATIC_CALL_OUTLINE: patched trampolines - requires a small amount of arch code 3) If no arch support, fall back to regular function pointers Josh Poi

[PATCH v2 1/4] compiler.h: Make __ADDRESSABLE() symbol truly unique

2018-11-26 Thread Josh Poimboeuf
by using __UNIQUE_ID instead of __LINE__. Signed-off-by: Josh Poimboeuf --- include/linux/compiler.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 06396c1cf127..4bb73fd918b5 100644 --- a/include/linux/compiler.h +++ b

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread Josh Poimboeuf
On Thu, Nov 22, 2018 at 12:13:41PM +0100, Ingo Molnar wrote: > Note to self: watch out for patches that change altinstructions and don't > make premature vmlinux size impact assumptions. :-) I noticed a similar problem with ORC data. As it turns out, size's "text" calculation also includes

Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment

2018-11-22 Thread Josh Poimboeuf
On Thu, Nov 22, 2018 at 12:08:54AM +0100, Borislav Petkov wrote: > On Wed, Nov 21, 2018 at 05:04:50PM -0600, Josh Poimboeuf wrote: > > Why not just 'user'? Like SPECTRE_V2_USER_*. > > Sure, a bit better except that it doesn't explain what it does, I'd say. But it does descr

Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment

2018-11-21 Thread Josh Poimboeuf
On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: > On Wed, 21 Nov 2018, Linus Torvalds wrote: > > > On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds > > wrote: > > > > > > Ugh. Now you're using the broken quilt thing that makes a mush of emails > > > for me. > > > > Reading the

Re: Cleaning up numbering for new x86 syscalls?

2018-11-20 Thread Josh Poimboeuf
On Tue, Nov 20, 2018 at 07:23:09AM -0800, Andy Lutomirski wrote: > On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote: > > > > * Andy Lutomirski: > > > > > 5. Adjust the scripts so that we only have to wire up new syscalls > > > once. They'll have a nr above 1024, and they'll have the same nr

[PATCH 1/2] objtool: Fix double-free in .cold detection error path

2018-11-20 Thread Josh Poimboeuf
ng cleanup to elf_close(). Fixes: 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions") Signed-off-by: Artem Savkov Signed-off-by: Josh Poimboeuf --- tools/objtool/elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.

[PATCH 0/2] objtool: Fixes in .cold detection logic

2018-11-20 Thread Josh Poimboeuf
A couple of objtool fixes from Artem Savkov. Fix a double-free in an error path, and a seg fault seen with -ffunction-sections. Artem Savkov (2): objtool: Fix double-free in .cold detection error path objtool: Fix seg fault in .cold detection with -ffunction-sections tools/objtool/elf.c |

[PATCH 2/2] objtool: Fix seg fault in .cold detection with -ffunction-sections

2018-11-20 Thread Josh Poimboeuf
h string instead of modifying it in place. Fixes: 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions") Signed-off-by: Artem Savkov Signed-off-by: Josh Poimboeuf --- tools/objtool/elf.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/tools/objtool/e

Re: [PATCH v4 0/2] objtool: read_symbols() fixes

2018-11-20 Thread Josh Poimboeuf
On Tue, Nov 20, 2018 at 09:05:46AM +0100, Artem Savkov wrote: > The series started with 'parent symbol search' patch, but I found another > issue > in read_symbols() while testing the failure-path. > > Artem Savkov (2): > objtool: fix failed cold symbol doublefree > objtool: fix .cold

Re: [PATCH v3 2/2] objtool: fix .cold functions parent symbols search

2018-11-19 Thread Josh Poimboeuf
On Mon, Nov 12, 2018 at 01:55:19PM +0100, Artem Savkov wrote: > Because find_symbol_by_name() traverses the same lists as read_symbols() > changing sym->name in place without copying it affects the result of > find_symbol_by_name() and, in case when ".cold" function precedes it's > parent in

Re: [PATCH v3 1/2] objtool: fix failed cold symbol doublefree

2018-11-19 Thread Josh Poimboeuf
On Mon, Nov 12, 2018 at 01:55:18PM +0100, Artem Savkov wrote: > If read_symbols() fails during second list traversal (the one dealing > with ".cold" subfunctions) it frees the symbol, but never deletes it > from the list/hash_table resulting in symbol being freed again in > elf_close(). > >

Re: [PATCH RFC 0/3] Static calls

2018-11-12 Thread Josh Poimboeuf
On Mon, Nov 12, 2018 at 12:03:34PM -0500, Steven Rostedt wrote: > On Sun, 11 Nov 2018 23:30:55 -0600 > Josh Poimboeuf wrote: > > > > How much of that slowdown is reversed? > > > > In theory, it should reverse all of the slowdown, and actually may even &g

Re: [PATCH RFC 0/3] Static calls

2018-11-12 Thread Josh Poimboeuf
On Mon, Nov 12, 2018 at 10:39:52AM +0100, Ard Biesheuvel wrote: > On Mon, 12 Nov 2018 at 06:31, Josh Poimboeuf wrote: > > > > On Mon, Nov 12, 2018 at 06:02:41AM +0100, Ingo Molnar wrote: > > > > > > * Josh Poimboeuf wrote: > > > > > > > On Fr

Re: [RFC PATCH 00/12] locking/lockdep: Add a new class of terminal locks

2018-11-12 Thread Josh Poimboeuf
On Mon, Nov 12, 2018 at 07:30:50AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Mon, Nov 12, 2018 at 06:10:33AM +0100, Ingo Molnar wrote: > > > > > > * Waiman Long wrote: > > > > > > > On 11/10/2018 09:10 AM, Peter Z

Re: [RFC PATCH 00/12] locking/lockdep: Add a new class of terminal locks

2018-11-11 Thread Josh Poimboeuf
On Mon, Nov 12, 2018 at 06:10:33AM +0100, Ingo Molnar wrote: > > * Waiman Long wrote: > > > On 11/10/2018 09:10 AM, Peter Zijlstra wrote: > > > On Fri, Nov 09, 2018 at 09:04:12AM +0100, Ingo Molnar wrote: > > >> BTW., if you are interested in more radical approaches to optimize > > >> lockdep,

Re: [PATCH RFC 0/3] Static calls

2018-11-11 Thread Josh Poimboeuf
On Mon, Nov 12, 2018 at 06:02:41AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Fri, Nov 09, 2018 at 08:28:11AM +0100, Ingo Molnar wrote: > > > > - I'm not sure about the objtool approach. Objtool is (currently) > > > >

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-11 Thread Josh Poimboeuf
On Mon, Nov 12, 2018 at 05:39:38AM +0100, Ard Biesheuvel wrote: > On 12 November 2018 at 04:07, Josh Poimboeuf wrote: > > On Sat, Nov 10, 2018 at 08:09:17AM -0500, Steven Rostedt wrote: > >> On Sat, 10 Nov 2018 12:58:08 +0100 > >> Ard Biesheuvel wrote: >

Re: [PATCH v2] objtool: fix .cold. functions parent symbols search

2018-11-11 Thread Josh Poimboeuf
On Sat, Nov 10, 2018 at 01:18:36PM +0100, Artem Savkov wrote: > On Fri, Nov 09, 2018 at 11:23:09AM -0600, Josh Poimboeuf wrote: > > On Wed, Nov 07, 2018 at 10:45:15PM +0100, Artem Savkov wrote: > > > Because find_symbol_by_name() traverses the same lists as read_symbols() > &

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-11 Thread Josh Poimboeuf
On Sat, Nov 10, 2018 at 08:09:17AM -0500, Steven Rostedt wrote: > On Sat, 10 Nov 2018 12:58:08 +0100 > Ard Biesheuvel wrote: > > > > > The complaint is on: > > > > > > DEFINE_STATIC_CALL(__tp_func_##name, __tracepoint_iter_##name); > > > > > > And the previous definition is on: > > > >

Re: [PATCH RFC 0/3] Static calls

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 02:59:18PM -0500, Steven Rostedt wrote: > On Fri, 9 Nov 2018 13:44:09 -0600 > Josh Poimboeuf wrote: > > > On Fri, Nov 09, 2018 at 02:37:03PM -0500, Steven Rostedt wrote: > > > On Fri, 9 Nov 2018 11:05:51 -0800 > > > Andy Lutomirski wrote:

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 02:57:46PM -0500, Steven Rostedt wrote: > On Fri, 9 Nov 2018 13:35:05 -0600 > Josh Poimboeuf wrote: > > > > > > +#define DECLARE_STATIC_CALL(key, func) > > > > \ > > >

Re: [PATCH RFC 0/3] Static calls

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 02:37:03PM -0500, Steven Rostedt wrote: > On Fri, 9 Nov 2018 11:05:51 -0800 > Andy Lutomirski wrote: > > > > Not sure what Andy was talking about, but I'm currently implementing > > > tracepoints to use this, as tracepoints use indirect calls, and are a > > > prime

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 01:33:37PM -0500, Steven Rostedt wrote: > > +config HAVE_STATIC_CALL_OPTIMIZED > > + bool > > + > > +config HAVE_STATIC_CALL_UNOPTIMIZED > > + bool > > + > > Let's also have > > config HAVE_STATIC_CALL > def_bool Y > depends on HAVE_STATIC_CALL_OPTIMIZED

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 06:53:21PM +0100, Ard Biesheuvel wrote: > > It's a bit fiddly since inline and out-of-line both use > > arch_static_call_transform(), but what I need to do is basically: > > > > - for out-of-line, the trampoline needs to be patched into a > > movn/movk/movk/br sequence if

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 06:33:03PM +0100, Ard Biesheuvel wrote: > On 9 November 2018 at 18:31, Josh Poimboeuf wrote: > > On Fri, Nov 09, 2018 at 06:25:24PM +0100, Ard Biesheuvel wrote: > >> On 9 November 2018 at 16:14, Ard Biesheuvel > >> wrote: > >>

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 11:31:06AM -0600, Josh Poimboeuf wrote: > On Fri, Nov 09, 2018 at 06:25:24PM +0100, Ard Biesheuvel wrote: > > On 9 November 2018 at 16:14, Ard Biesheuvel > > wrote: > > > On 9 November 2018 at 16:10, Josh Poimboeuf wrote: > > >> On F

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 06:25:24PM +0100, Ard Biesheuvel wrote: > On 9 November 2018 at 16:14, Ard Biesheuvel wrote: > > On 9 November 2018 at 16:10, Josh Poimboeuf wrote: > >> On Fri, Nov 09, 2018 at 02:39:17PM +0100, Ard Biesheuvel wrote: > >>> > + for

Re: [PATCH v2] objtool: fix .cold. functions parent symbols search

2018-11-09 Thread Josh Poimboeuf
On Wed, Nov 07, 2018 at 10:45:15PM +0100, Artem Savkov wrote: > Because find_symbol_by_name() traverses the same lists as read_symbols() > changing sym->name in place without copying it affects the result of > find_symbol_by_name() and, in case when ".cold" function precedes it's > parent in

Re: [PATCH RFC 0/3] Static calls

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 09:21:39AM -0600, Josh Poimboeuf wrote: > On Fri, Nov 09, 2018 at 07:16:17AM -0800, Andy Lutomirski wrote: > > On Thu, Nov 8, 2018 at 11:28 PM Ingo Molnar wrote: > > > > > > > > > All other usecases are bonus, but it would certainly

Re: [PATCH RFC 0/3] Static calls

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 07:16:17AM -0800, Andy Lutomirski wrote: > On Thu, Nov 8, 2018 at 11:28 PM Ingo Molnar wrote: > > > > > > All other usecases are bonus, but it would certainly be interesting to > > investigate the impact of using these APIs for tracing: that too is a > > feature enabled

Re: [PATCH RFC 0/3] Static calls

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 02:50:27PM +0100, Ard Biesheuvel wrote: > On 9 November 2018 at 08:28, Ingo Molnar wrote: > > > > * Josh Poimboeuf wrote: > > > >> These patches are related to two similar patch sets from Ard and Steve: > >> > >> - >

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 02:39:17PM +0100, Ard Biesheuvel wrote: > > + for (site = start; site < stop; site++) { > > + struct static_call_key *key = static_call_key(site); > > + unsigned long addr = static_call_addr(site); > > + > > + if

Re: [RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 10:51:16AM +0100, Ard Biesheuvel wrote: > Hi Josh, > > Thanks a lot for looking into this. > > On 8 November 2018 at 22:15, Josh Poimboeuf wrote: > > Add a static call infrastructure. Static calls use code patching to > > hard-code function

Re: [PATCH RFC 0/3] Static calls

2018-11-09 Thread Josh Poimboeuf
On Fri, Nov 09, 2018 at 08:28:11AM +0100, Ingo Molnar wrote: > > - I'm not sure about the objtool approach. Objtool is (currently) > > x86-64 only, which means we have to use the "unoptimized" version > > everywhere else. I may experiment with a GCC plugin instead. > > I'd prefer the

Re: [PATCH RFC 0/3] Static calls

2018-11-08 Thread Josh Poimboeuf
On Thu, Nov 08, 2018 at 03:15:50PM -0600, Josh Poimboeuf wrote: > - Does this feature have much value without retpolines? If not, should > we make it depend on retpolines somehow? I forgot Andy mentioned that we might be able to use this to clean up paravirt patching, in which case it

[PATCH RFC 0/3] Static calls

2018-11-08 Thread Josh Poimboeuf
trampoline. 3) Generic implementation This is the default implementation if the architecture hasn't implemented CONFIG_HAVE_STATIC_CALL_[UN]OPTIMIZED. In this case, a basic function pointer is used. Josh Poimboeuf (3): static_call: Add static call infrastructure x86/static_cal

[RFC PATCH 1/3] static_call: Add static call infrastructure

2018-11-08 Thread Josh Poimboeuf
TIMIZED) 2) unoptimized: patched trampolines (CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED) 3) basic function pointers For more details, see the comments in include/linux/static_call.h. Signed-off-by: Josh Poimboeuf --- arch/Kconfig | 6 + include/asm-generic/vmlinux.lds.h | 11 ++ inc

[RFC PATCH 2/3] x86/static_call: Add x86 unoptimized static call implementation

2018-11-08 Thread Josh Poimboeuf
Add the x86 unoptimized static call implementation. For each key, it creates a permanent trampoline which is the destination for all static calls for the given key. The trampoline has a direct jump which gets patched by static_call_update() when the destination changes. Signed-off-by: Josh

[RFC PATCH 3/3] x86/static_call: Add optimized static call implementation for 64-bit

2018-11-08 Thread Josh Poimboeuf
those call sites in the .static_call_sites section. During boot (and module init), the call sites are patched to call directly into the destination function. The temporary trampoline is then no longer used. Signed-off-by: Josh Poimboeuf --- arch/x86/Kconfig | 5

Re: [PATCH] objtool: fix .cold. functions parent symbols search

2018-11-07 Thread Josh Poimboeuf
On Wed, Nov 07, 2018 at 07:42:46PM +0100, Artem Savkov wrote: > On Wed, Nov 07, 2018 at 11:08:56AM -0600, Josh Poimboeuf wrote: > > On Wed, Nov 07, 2018 at 03:05:59PM +0100, Artem Savkov wrote: > > > The way it is currently done it is possible for read_symbols() to find the

Re: [PATCH] objtool: fix .cold. functions parent symbols search

2018-11-07 Thread Josh Poimboeuf
On Wed, Nov 07, 2018 at 03:05:59PM +0100, Artem Savkov wrote: > The way it is currently done it is possible for read_symbols() to find the > same symbol as parent for ".cold" functions. I seem to remember having this discussion for kpatch-build, but I forget the details. Can you explain how this

Re: [PATCH resend] scripts/faddr2line: fix location of start_kernel in comment

2018-11-02 Thread Josh Poimboeuf
On Thu, Nov 01, 2018 at 04:42:52PM -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Fix a source file reference location to the correct path name. > > Signed-off-by: Randy Dunlap > Cc: Josh Poimboeuf Acked-by: Josh Poimboeuf -- Josh

[tip:core/urgent] objtool: Support GCC 9 cold subfunction naming scheme

2018-11-01 Thread tip-bot for Josh Poimboeuf
Commit-ID: bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6 Gitweb: https://git.kernel.org/tip/bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6 Author: Josh Poimboeuf AuthorDate: Wed, 31 Oct 2018 21:57:30 -0500 Committer: Thomas Gleixner CommitDate: Thu, 1 Nov 2018 09:55:38 +0100 objtool: Support GCC

[PATCH] objtool: Support GCC 9 cold subfunction naming scheme

2018-10-31 Thread Josh Poimboeuf
Signed-off-by: Josh Poimboeuf --- tools/objtool/elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index f7082de1ee82..6dbb9fae0f9d 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -301,7 +301,7 @@ static int read_symbols(

Re: [PATCH v4 3/3] arm64: reliable stacktraces

2018-10-29 Thread Josh Poimboeuf
wind_frame.c and __save_stack_trace_reliable() in arch/x86/kernel/stacktrace.c. > On Fri, Oct 26, 2018 at 10:37:04AM -0500, Josh Poimboeuf wrote: > > On Fri, Oct 26, 2018 at 04:21:57PM +0200, Torsten Duwe wrote: > > > Enhance the stack unwinder so that it reports whether it had to stop > > >

Re: [PATCH v4 3/3] arm64: reliable stacktraces

2018-10-26 Thread Josh Poimboeuf
On Fri, Oct 26, 2018 at 04:21:57PM +0200, Torsten Duwe wrote: > Enhance the stack unwinder so that it reports whether it had to stop > normally or due to an error condition; unwind_frame() will report > continue/error/normal ending and walk_stackframe() will pass that > info. __save_stack_trace()

Re: [PATCH v12 06/12] livepatch: Simplify API by removing registration step

2018-10-23 Thread Josh Poimboeuf
On Tue, Oct 23, 2018 at 11:39:43AM -0500, Josh Poimboeuf wrote: > Given this discussion, I'm thinking there wouldn't be much to discuss at > LPC for this topic unless we had a prototype to look at (which I won't > have time to do). So I may drop my talk in favor of giving more time &g

Re: [PATCH v12 06/12] livepatch: Simplify API by removing registration step

2018-10-23 Thread Josh Poimboeuf
On Mon, Oct 22, 2018 at 03:25:10PM +0200, Petr Mladek wrote: > On Fri 2018-10-19 09:36:04, Josh Poimboeuf wrote: > > On Fri, Oct 19, 2018 at 02:16:19PM +0200, Miroslav Benes wrote: > > > On Thu, 18 Oct 2018, Josh Poimboeuf wrote: > > > > > > > On Thu, Oct 18

Re: [PATCH 2/3] objtool: move libelf check out of top Makefile

2018-10-19 Thread Josh Poimboeuf
On Fri, Oct 19, 2018 at 03:04:22PM +0900, Masahiro Yamada wrote: > Hi Josh, > > > On Wed, Oct 17, 2018 at 1:16 AM Josh Poimboeuf wrote: > > > > On Wed, Oct 17, 2018 at 12:51:40AM +0900, Masahiro Yamada wrote: > > > > ifdef CONFIG_UNWINDER_ORC > > >

Re: [PATCH v12 06/12] livepatch: Simplify API by removing registration step

2018-10-19 Thread Josh Poimboeuf
On Fri, Oct 19, 2018 at 02:16:19PM +0200, Miroslav Benes wrote: > On Thu, 18 Oct 2018, Josh Poimboeuf wrote: > > > On Thu, Oct 18, 2018 at 04:54:56PM +0200, Petr Mladek wrote: > > > On Mon 2018-10-15 18:01:43, Miroslav Benes wrote: > > > > On Fr

Re: [PATCH v12 06/12] livepatch: Simplify API by removing registration step

2018-10-18 Thread Josh Poimboeuf
On Thu, Oct 18, 2018 at 04:54:56PM +0200, Petr Mladek wrote: > On Mon 2018-10-15 18:01:43, Miroslav Benes wrote: > > On Fri, 12 Oct 2018, Petr Mladek wrote: > > > > > On Wed 2018-09-05 11:34:06, Miroslav Benes wrote: > > > > On Tue, 28 Aug 2018, Petr Mladek wrote: > > > > > Also the API and logic

Re: [PATCH v13 00/12] livepatch: Atomic replace feature

2018-10-18 Thread Josh Poimboeuf
On Mon, Oct 15, 2018 at 02:37:01PM +0200, Petr Mladek wrote: > The atomic replace allows to create cumulative patches. They > are useful when you maintain many livepatches and want to remove > one that is lower on the stack. In addition it is very useful when > more patches touch the same function

Re: [PATCH v13 05/12] livepatch: Refuse to unload only livepatches available during a forced transition

2018-10-18 Thread Josh Poimboeuf
On Thu, Oct 18, 2018 at 02:09:47PM +0200, Petr Mladek wrote: > On Wed 2018-10-17 13:35:19, Josh Poimboeuf wrote: > > I'm having trouble parsing the subject. How about: > > > > Allow unloading of patches added after using 'force' > > ok > > > > --- a/ker

Re: [PATCH v13 02/12] livepatch: Helper macros to define livepatch structures

2018-10-18 Thread Josh Poimboeuf
On Thu, Oct 18, 2018 at 01:11:53PM +0200, Petr Mladek wrote: > On Wed 2018-10-17 13:17:56, Josh Poimboeuf wrote: > > On Mon, Oct 15, 2018 at 02:37:03PM +0200, Petr Mladek wrote: > > > The definition of struct klp_func might be a bit confusing. > > > The original

Re: [PATCH v13 12/12] selftests/livepatch: introduce tests

2018-10-17 Thread Josh Poimboeuf
On Mon, Oct 15, 2018 at 02:37:13PM +0200, Petr Mladek wrote: > From: Joe Lawrence > > Add a few livepatch modules and simple target modules that the included > regression suite can run tests against: > > - basic livepatching (multiple patches, atomic replace) > - pre/post (un)patch

Re: [PATCH v13 09/12] livepatch: Remove Nop structures when unused

2018-10-17 Thread Josh Poimboeuf
On Mon, Oct 15, 2018 at 02:37:10PM +0200, Petr Mladek wrote: > +void klp_discard_replaced_stuff(struct klp_patch *new_patch) > +{ > + klp_discard_replaced_patches(new_patch); > + klp_discard_nops(new_patch); > +} > + > +/* Stuff? Really? :-) How about klp_discard_replaced()? -- Josh

Re: [PATCH v13 07/12] livepatch: Use lists to manage patches, objects and functions

2018-10-17 Thread Josh Poimboeuf
On Mon, Oct 15, 2018 at 02:37:08PM +0200, Petr Mladek wrote: > +static int klp_init_lists(struct klp_patch *patch) > +{ > + struct klp_object *obj; > + struct klp_func *func; > + > + INIT_LIST_HEAD(>obj_list); > + if (!patch->objs) > + return -EINVAL; > + > +

Re: [PATCH v13 06/12] livepatch: Simplify API by removing registration step

2018-10-17 Thread Josh Poimboeuf
On Mon, Oct 15, 2018 at 02:37:07PM +0200, Petr Mladek wrote: > @@ -319,96 +316,66 @@ forced it is guaranteed that no task sleeps or runs in > the old code. > 5. Livepatch life-cycle > === > > -Livepatching defines four basic operations that define the life cycle of each >

Re: [PATCH v13 05/12] livepatch: Refuse to unload only livepatches available during a forced transition

2018-10-17 Thread Josh Poimboeuf
I'm having trouble parsing the subject. How about: Allow unloading of patches added after using 'force' ? > --- a/kernel/livepatch/core.c > +++ b/kernel/livepatch/core.c > @@ -45,7 +45,8 @@ > */ > DEFINE_MUTEX(klp_mutex); > > -static LIST_HEAD(klp_patches); > +/* Registered patches */ >

Re: [PATCH v13 04/12] livepatch: Consolidate klp_free functions

2018-10-17 Thread Josh Poimboeuf
On Mon, Oct 15, 2018 at 02:37:05PM +0200, Petr Mladek wrote: > @@ -637,6 +647,7 @@ static int klp_init_patch(struct klp_patch *patch) > mutex_lock(_mutex); > > patch->enabled = false; > + INIT_LIST_HEAD(>list); Is this a bug fix? If so, it should go in a separate patch. I'm

Re: [PATCH v13 02/12] livepatch: Helper macros to define livepatch structures

2018-10-17 Thread Josh Poimboeuf
On Mon, Oct 15, 2018 at 02:37:03PM +0200, Petr Mladek wrote: > The definition of struct klp_func might be a bit confusing. > The original function is defined by name as a string. > The new function is defined by name as a function pointer > casted to unsigned long. > > This patch adds helper

Re: [PATCH 2/3] objtool: move libelf check out of top Makefile

2018-10-16 Thread Josh Poimboeuf
On Wed, Oct 17, 2018 at 12:51:40AM +0900, Masahiro Yamada wrote: > > ifdef CONFIG_UNWINDER_ORC > > > > chk_unwinder_orc = echo "int main() {}" | $(HOSTCC) -xc -o /dev/null -lelf - > > msg_unwinder_orc = "Cannot build objtool to generate ORC metadata for > > CONFIG_UNWINDER_ORC=y. " \ > >

Re: [PATCH 2/3] objtool: move libelf check out of top Makefile

2018-10-16 Thread Josh Poimboeuf
On Tue, Oct 16, 2018 at 06:10:52PM +0900, Masahiro Yamada wrote: > Another behavioral change is, missing libelf for CONFIG_STACK_VALIDATION > was previously a warning, but now a error. This behavioral change should be fine. It was already an error for UNWINDER_ORC, so this would only upgrade a

Re: [PATCH] x86/mm: annotate no_context with UNWIND_HINTS

2018-10-15 Thread Josh Poimboeuf
On Mon, Oct 15, 2018 at 09:03:40AM -0700, Andy Lutomirski wrote: > That being said, the generic macro is: > > # define unreachable() do { annotate_reachable(); do { } while (1); } while > (0) > > I'm probably missing some subtlety here, but shouldn't that be > annotate_*un*reachable()? That

Re: [PATCH] x86/mm: annotate no_context with UNWIND_HINTS

2018-10-15 Thread Josh Poimboeuf
On Mon, Oct 15, 2018 at 08:22:21AM -0700, Nathan Chancellor wrote: > > >>> @@ -760,9 +760,11 @@ no_context(struct pt_regs *regs, unsigned long > > >>> error_code, > > >>> * and then double-fault, though, because we're likely to > > >>> * break the console driver

  1   2   3   4   5   6   7   8   9   10   >