Re: [PATCH 3/3] objtool: Enable compilation of objtool for all architectures

On Tue, May 19, 2020 at 02:46:37PM -0700, Matt Helsley wrote: > On Tue, May 19, 2020 at 04:18:29PM -0500, Josh Poimboeuf wrote: > > On Tue, May 19, 2020 at 01:55:33PM -0700, Matt Helsley wrote: > > > +const char __attribute__ ((weak)) *objname; > > > + > > > +in

Re: [PATCH 3/3] objtool: Enable compilation of objtool for all architectures

ct objtool_file *file) > +{ > + return 127; > +} > + > +int __attribute__ ((weak)) create_orc_sections(struct objtool_file *file) > +{ > + return 127; > +} I think the aliased "missing_" functions are no longer needed, right? i.e. can we just have weak versions of check() and orc_dump()? Otherwise everything looks good to me. -- Josh

Re: objtool warning breaks build for fs/dlm/lock.o

On Mon, May 18, 2020 at 05:53:28PM -0500, Josh Poimboeuf wrote: > > I'm now struggling with a clang -fintegrated-as related failure: > > > > arch/x86/kernel/ftrace_64.o: warning: objtool: missing symbol for insn at > > offset 0x16 > > make[4]: *** [/git

Re: objtool warning breaks build for fs/dlm/lock.o

On Mon, May 18, 2020 at 09:57:50PM +0200, Arnd Bergmann wrote: > On Fri, May 8, 2020 at 1:29 AM Josh Poimboeuf wrote: > > > > On Wed, May 06, 2020 at 04:07:25PM +0200, Arnd Bergmann wrote: > > > Hi, > > > > > > During randconfig testing with clang-10

Re: [RFC][PATCH 4/5] objtool: Enable compilation of objtool for all architectures

oach neatly > avoids conditional preprocessor games and type casting though I do > agree it's surprising. > > Do you have any advice here? Would it work if we just move the check() and orc_dump() prototypes to objtool.h? Then weak.c can just include objtool.h. And check.h and orc.h would only need to be included for arches which implement them. -- Josh

Re: [RFC][PATCH 5/5] objtool: Report missing support for subcommands

lable. Technically they are available, they just always fail :-) And, people don't tend to use objtool directly anyway. BTW, several of the patches didn't apply cleanly to tip/master, so you'll probably need to rebase for v2. There've been a lot of objtool changes lately. Peter's been busy... -- Josh

Re: [RFC][PATCH 4/5] objtool: Enable compilation of objtool for all architectures

+ struct orc_entry orc; > +}; Why were these moved to arch.h? They're not necessarily arch-specific, but rather "check"-specific, so I think they still belong in check.h, if possible. -- Josh

Re: [RFC][PATCH 4/5] objtool: Enable compilation of objtool for all architectures

ng better than the > other. So it's more up to what the maintainer prefer! :) For now I'd prefer getting rid of the 'missing' arch and just having a single top-level weak.c which has all the weak functions in it. Keeps the clutter down :-) Down the road, if the number of weak functions got out of hand then we could look at splitting them up into multiple files. -- Josh

Re: [RFC][PATCH 3/5] objtool: Add support for relocations without addends

SHT_RELA: > + relas[idx].r_addend = rela->addend; > + relas[idx].r_offset = rela->offset; > + relas[idx].r_info = GELF_R_INFO(rela->sym->idx, > rela->type); > + break; > + default: > + break; > + } > idx++; There's a lot of trickiness going on here, in a valiant attempt to share code, but really most of the code ends up not being shared anyway. I think it would be a lot cleaner to just create a new "rel" version of this function. Then there could be a top-level elf_rebuild_reloc_section() which calls the appropriate "rel" or "rela" variant. -- Josh

Re: [RFC][PATCH 1/5] objtool: Exit successfully when requesting help

+ exit(129); > + else > + exit(0); Looks fine, though the 'else' isn't needed. -- Josh

[tip: objtool/urgent] x86/unwind/orc: Fix error handling in __unwind_start()

The following commit has been merged into the objtool/urgent branch of tip: Commit-ID: 71c95825289f585014fe9741b051d32a7a916680 Gitweb: https://git.kernel.org/tip/71c95825289f585014fe9741b051d32a7a916680 Author:Josh Poimboeuf AuthorDate:Thu, 14 May 2020 15:31:10 -05:00

Re: [PATCH] tools/perf-bench: Add basic syscall benchmark

(2), yet > without any of the additional template stuff from Ingo's version (based > on numa.c). The code is identical to what mmtests uses. > > [0] https://lore.kernel.org/lkml/20160201074156.ga27...@gmail.com/ > > Signed-off-by: Davidlohr Bueso It would be nice to see this merged. I posted something very similar back in 2016. -- Josh

[PATCH -tip urgent] x86/unwind/orc: Fix error handling in __unwind_start()

ent unwinding before ORC initialization") Reported-by: Pavel Machek Signed-off-by: Josh Poimboeuf --- arch/x86/kernel/unwind_orc.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c index 5b0bd8581f

Re: [PATCH 4.19 41/48] x86/unwind/orc: Prevent unwinding before ORC initialization

on.] > > Signed-off-by: Pavel Machek I already have the same memset patch (along with other error-handling fixes) which I'll be posting shortly once it runs through my testing. Since the sizeof(long) thing isn't really a bug, I'll make that change later, along with some other pending improvements I have. -- Josh

Re: [PATCH 4.19 41/48] x86/unwind/orc: Prevent unwinding before ORC initialization

On Wed, May 13, 2020 at 11:52:10PM +0200, Pavel Machek wrote: > Hi! > > > From: Josh Poimboeuf > > > > commit 98d0c8ebf77e0ba7c54a9ae05ea588f0e9e3f46e upstream. > > > > If the unwinder is called before the ORC data has been initialized, > > orc_find()

Re: [PATCH 4.19 37/48] x86/entry/64: Fix unwind hints in register clearing code

On Wed, May 13, 2020 at 11:48:56PM +0200, Pavel Machek wrote: > On Wed 2020-05-13 11:45:03, Greg Kroah-Hartman wrote: > > From: Josh Poimboeuf > > > > commit 06a9750edcffa808494d56da939085c35904e618 upstream. > > > > The PUSH_AND_CLEAR_REGS macro zeroe

Re: [patch V5 06/38] x86/entry: Provide helpers for execute on irqstack

gt; 64 bit only for now. 32 bit has a variant of that already. Once this is > cleaned up the two implementations might be consolidated as a cleanup on > top. > > Signed-off-by: Thomas Gleixner > Link: https://lore.kernel.org/r/20200507161020.783541...@infradead.org > --- > V5: Moved the actual switch to ASM code Acked-by: Josh Poimboeuf -- Josh

Re: [PATCH 2/3] security: add symbol namespace for reading file data

On Wed, May 13, 2020 at 04:16:22PM +, Luis Chamberlain wrote: > On Wed, May 13, 2020 at 10:40:31AM -0500, Eric W. Biederman wrote: > > Luis Chamberlain writes: > > > > > Certain symbols are not meant to be used by everybody, the security > > > helpers for reading files directly is one such ca

Re: [patch V4 part 1 35/36] x86: Replace ist_enter() with nmi_enter()

gnal or a wakeup) is performed from > > IRQ context very soon after the NMI, rather than from NMI context. > > > > AFAIK this is how this is done today by perf, ftrace, ebpf, and lttng. > > What Mathieu says. But I suspect you want to keep reading until > part4-18. That should get you what you really want. LALALALA At least give a spoiler alert for those of us still enjoying part 1! -- Josh

Re: objtool warning breaks build for fs/dlm/lock.o

On Fri, May 08, 2020 at 06:26:04PM +0200, Peter Zijlstra wrote: > On Fri, May 08, 2020 at 11:17:50AM -0500, Josh Poimboeuf wrote: > > On Fri, May 08, 2020 at 11:55:09AM +0200, Peter Zijlstra wrote: > > > On Fri, May 08, 2020 at 11:27:39AM +0200, Arnd Bergmann wrote: > >

Re: objtool warning breaks build for fs/dlm/lock.o

On Fri, May 08, 2020 at 11:45:18AM +0200, Peter Zijlstra wrote: > On Thu, May 07, 2020 at 06:29:41PM -0500, Josh Poimboeuf wrote: > > On Wed, May 06, 2020 at 04:07:25PM +0200, Arnd Bergmann wrote: > > > Hi, > > > > > > During randconfig testing with clan

Re: objtool warning breaks build for fs/dlm/lock.o

at some > > point > > I would prefer to trap immediately when a new warning pops up. > > Completely untested, and I'm 100% unsure of the Makefile change, but > something like so, then? Mostly looks good, but it only errors out on fatal errors, right? For -Werror (and what Arnd is asking about) should it also return error on "warnings > 0"? -- Josh

Re: mmotm 2020-05-05-15-28 uploaded (objtool warning)

-by: Peter Zijlstra (Intel) It helps to put an example of the fixed warning in the commit log, like: This fixes the following warning: arch/x86/hyperv/hv_apic.o: warning: objtool: hv_apic_write()+0x25: alternative modifies stack Otherwise it looks good. Acked-by: Josh Poimboeuf -- Josh

Re: [PATCH -next] livepatch: Make klp_apply_object_relocs static

On Fri, May 08, 2020 at 10:53:41AM -0500, Josh Poimboeuf wrote: > On Fri, May 08, 2020 at 08:06:34PM +0800, Samuel Zou wrote: > > Fix the following sparse warning: > > > > kernel/livepatch/core.c:748:5: warning: symbol 'klp_apply_object_relocs' > > was not de

Re: [PATCH -next] livepatch: Make klp_apply_object_relocs static

tch description should probably state that it should be static because its only caller is in the file. With that change: Acked-by: Josh Poimboeuf -- Josh

Re: [PATCH v4 14/18] static_call: Add static_cond_call()

On Fri, May 08, 2020 at 05:27:30PM +0200, Peter Zijlstra wrote: > On Wed, May 06, 2020 at 12:24:55PM -0500, Josh Poimboeuf wrote: > > > On that note, what do you think about tweaking the naming from > > > > DEFINE_STATIC_COND_CALL(name, typename); > >

Re: [PATCH v4 16/18] static_call: Allow early init

this is much much earlier than needed for perf, but it > might allow other uses.) > > Signed-off-by: Peter Zijlstra (Intel) Looks good, I'll try to do some more testing today-ish. -- Josh

Re: objtool warning breaks build for fs/dlm/lock.o

by new compiler versions, I really think we need to revert 644592d32837 ("objtool: Fail the kernel build on fatal errors") because objtool is never going to be reliable enough such that we can be confident that failing the build is the right thing to do. -- Josh

Re: [RFC][PATCH 3/3] x86/entry, ORC: Teach objtool/unwind_orc about stack irq swizzles

On Thu, May 07, 2020 at 07:38:09PM +0200, Peter Zijlstra wrote: > On Thu, May 07, 2020 at 06:10:23PM +0200, Peter Zijlstra wrote: > > Thomas would very much like objtool to understand and generate correct > > ORC unwind information for the minimal stack swizzle sequence: > > > > mov %rsp, (%[t

[tip: objtool/urgent] objtool: Fix infinite loop in find_jump_table()

The following commit has been merged into the objtool/urgent branch of tip: Commit-ID: 1119d265bc20226c241e5540fc8a246d9e30b272 Gitweb: https://git.kernel.org/tip/1119d265bc20226c241e5540fc8a246d9e30b272 Author:Josh Poimboeuf AuthorDate:Tue, 28 Apr 2020 16:45:16 -05:00

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

I'm worried about, it's all of them. There are a lot of possibilities, with all the different configs, and arches. Flags are usually added for a good reason, so one randomly missing flag could have unforeseen results. And I don't have any visibility into how GCC decides which flags to drop, and when. But the docs aren't comforting. Even if things seem to work now, that could (silently) change at any point in time. This time objtool warned about the missing frame pointer, but that's not necessarily going to happen for other flags. If we go this route, I would much rather do -fno-gcse on a file-wide basis. -- Josh

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

On Wed, May 06, 2020 at 09:45:01AM -0700, Alexei Starovoitov wrote: > On Wed, May 6, 2020 at 8:53 AM Josh Poimboeuf wrote: > > > > On Tue, May 05, 2020 at 04:59:39PM -0700, Alexei Starovoitov wrote: > > > As far as workaround I prefer t

Re: [PATCH v4 16/18] static_call: Allow early init

On Fri, May 01, 2020 at 10:29:05PM +0200, Peter Zijlstra wrote: > In order to use static_call() to wire up x86_pmu, we need to > initialize earlier; copy some of the tricks from jump_label to enable > this. > > Primarily we overload key->next to store a sites pointer when there > are no modules, t

Re: [PATCH v4 14/18] static_call: Add static_cond_call()

On Wed, May 06, 2020 at 07:58:52PM +0200, Peter Zijlstra wrote: > On Wed, May 06, 2020 at 12:24:55PM -0500, Josh Poimboeuf wrote: > > On Fri, May 01, 2020 at 10:29:03PM +0200, Peter Zijlstra wrote: > > > +++ b/arch/x86/include/asm/static_call.h > > > @@ -30,4 +

Re: [PATCH v4 00/18] Add static_call()

ere. I guess you dropped it because it's no longer needed b/c we fixed those 'undefined references' a different way. -- Josh

Re: [PATCH v4 14/18] static_call: Add static_cond_call()

n/example would be useful. On that note, what do you think about tweaking the naming from DEFINE_STATIC_COND_CALL(name, typename); static_cond_call(name)(args...); to DEFINE_STATIC_CALL_NO_FUNC(name, typename); static_call_if_func(name)(args...); ? Seems clearer to me. They're still STATIC_CALLs, so it seems logical to keep those two words together. And NO_FUNC clarifies the initialized value. Similarly RETTRAMP could be ARCH_DEFINE_STATIC_CALL_NO_FUNC. -- Josh

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

nd kernel stack > unwinding can fall back from ORC to FP for that frame. > wdyt? It seems dangerous to me. The GCC manual recommends against it. And how do we know what other flags are getting removed for various arches (now or in the future)? -- Josh

Re: [PATCH v4 07/18] static_call: Add inline static call infrastructure

continue; > + } > + > + stop = __stop_static_call_sites; > + > +#ifdef CONFIG_MODULES > + if (site_mod->mod) { > + stop = site_mod->mod->static_call_sites + > +site_mod->mod->num_static_call_sites; > + } > +#endif Instead of defining 'mod' in the inner loop below, it can be set at the top of the outer loop above. Then the above 'stop' calculation can be a little less verbose. -- Josh

Re: [PATCH v4 06/18] static_call: Add basic static call infrastructure

e STATIC_CALL_TRAMP_PREFIX_STR __stringify(STATIC_CALL_TRAMP_PREFIX) > +#define STATIC_CALL_TRAMP(name) > __PASTE(STATIC_CALL_TRAMP_PREFIX, name) > +#define STATIC_CALL_TRAMP_STR(name) __stringify(STATIC_CALL_TRAMP(name)) -- Josh

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

On Tue, May 05, 2020 at 12:53:20PM -0700, Alexei Starovoitov wrote: > On Tue, May 05, 2020 at 01:11:08PM -0500, Josh Poimboeuf wrote: > > On Tue, May 05, 2020 at 10:43:00AM -0700, Alexei Starovoitov wrote: > > > > Or, if you want to minimize the patch's impact on other ar

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

ly real solution is to revert 3193c0836f20 ("bpf: Disable GCC -fgcse optimization for ___bpf_prog_run()") Once you do that (and disable retpolines) then you should see the problem described in my other email. -- Josh

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

pproach. But DWARF has its own issues and we can't rely on it for live patching. As I mentioned we have a plan to use a compiler plugin to annotate jump tables (including GCC switch tables). But the approach taken by this patch should be good enough for now. -- Josh

Re: [PATCH 6/7] mm: parallelize deferred_init_memmap()

h until about the full number of physical cores. From number of cores up to number of threads, the performance stayed about flat; it didn't get any better or worse. - Josh

Re: BUG: stack guard page was hit in unwind_next_frame

h yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+e73ceacfd8560cc8a...@syzkaller.appspotmail.com Infinite loop in network code. #syz dup: BUG: stack guard page was hit in deref_stack_reg -- Josh

[tip: x86/urgent] x86/unwind/orc: Move ORC sorting variables under !CONFIG_MODULES

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: fb9cbbc895eb6e986dc90c928a35c793d75f435a Gitweb: https://git.kernel.org/tip/fb9cbbc895eb6e986dc90c928a35c793d75f435a Author:Josh Poimboeuf AuthorDate:Tue, 28 Apr 2020 02:16:40 -05:00

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

On Fri, May 01, 2020 at 08:06:22PM -0700, Alexei Starovoitov wrote: > On Fri, May 01, 2020 at 02:56:17PM -0500, Josh Poimboeuf wrote: > > On Fri, May 01, 2020 at 12:40:53PM -0700, Alexei Starovoitov wrote: > > > On Fri, May 01, 2020 at 02:22:04PM -0500, Josh Poimboeuf wrote: >

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

On Fri, May 01, 2020 at 12:40:53PM -0700, Alexei Starovoitov wrote: > On Fri, May 01, 2020 at 02:22:04PM -0500, Josh Poimboeuf wrote: > > On Fri, May 01, 2020 at 12:09:30PM -0700, Alexei Starovoitov wrote: > > > On Thu, Apr 30, 2020 at 02:07:43PM -0500, Josh Poimboeuf wrot

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

On Fri, May 01, 2020 at 12:09:30PM -0700, Alexei Starovoitov wrote: > On Thu, Apr 30, 2020 at 02:07:43PM -0500, Josh Poimboeuf wrote: > > Objtool decodes instructions and follows all potential code branches > > within a function. But it's not an emulator, so it doesn't

[tip: sched/core] sched/fair: Remove distribute_running from CFS bandwidth

The following commit has been merged into the sched/core branch of tip: Commit-ID: ab93a4bc955b3980c699430bc0b633f0d8b607be Gitweb: https://git.kernel.org/tip/ab93a4bc955b3980c699430bc0b633f0d8b607be Author:Josh Don AuthorDate:Fri, 10 Apr 2020 15:52:08 -07:00 Committer

Re: Remaining randconfig objtool warnings, linux-next-20200428

(hopefully) it's an issue with the plugin and how it interacts with GCC 10. -- Josh

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Fri, May 01, 2020 at 02:33:19PM +0200, Peter Zijlstra wrote: > On Thu, Apr 30, 2020 at 08:07:33PM -0500, Josh Poimboeuf wrote: > > On Thu, Apr 30, 2020 at 04:05:07PM +0200, Arnd Bergmann wrote: > > > lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x1

Re: [RFC][PATCH] x86/ftrace: Have ftrace trampolines turn read-only at the end of system boot up

On Fri, May 01, 2020 at 09:24:04AM -0400, Steven Rostedt wrote: > On Fri, 1 May 2020 00:17:06 -0500 > Josh Poimboeuf wrote: > > > > Would it be easier to just call a new __text_poke_bp() which skips the > > > SYSTEM_BOOTING check, since you know the trampoline wil

Re: [RFC][PATCH] x86/ftrace: Have ftrace trampolines turn read-only at the end of system boot up

On Thu, Apr 30, 2020 at 11:47:33PM -0500, Josh Poimboeuf wrote: > On Thu, Apr 30, 2020 at 08:21:47PM -0400, Steven Rostedt wrote: > > The cause is the "ftrace=function" would register the function tracer > > and create a trampoline, and it will set it as executable an

Re: [RFC][PATCH] x86/ftrace: Have ftrace trampolines turn read-only at the end of system boot up

On Thu, Apr 30, 2020 at 08:21:47PM -0400, Steven Rostedt wrote: > The cause is the "ftrace=function" would register the function tracer > and create a trampoline, and it will set it as executable and > read-only. Then the "trace_options=func_stack_trace" would then update > the same trampoline to i

Re: linux-next: Tree for Apr 30 (objtool warnings)

gt; > kernel/exit.o: warning: objtool: __x64_sys_exit_group()+0x2e: unreachable > > instruction > > kernel/cred.o: warning: objtool: copy_creds()+0x278: unreachable instruction > > net/core/skbuff.o: warning: objtool: skb_push()+0x9e: unreachable > > instruction > >

Re: [PATCH 0/7] padata: parallelize deferred page init

git padata-mt-definit-v1 > > https://oss.oracle.com/git/gitweb.cgi?p=linux-dmjordan.git;a=shortlog;h=refs/heads/padata-mt-definit-v1 For the series (and the three prerequisite patches): Tested-by: Josh Triplett Thank you for writing this, and thank you for working towards upstreaming it!

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Thu, Apr 30, 2020 at 04:05:07PM +0200, Arnd Bergmann wrote: > lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x133: call to > do_strncpy_from_user() with UACCESS enabled > lib/strnlen_user.o: warning: objtool: strnlen_user()+0x122: call to > do_strnlen_user() with UACCESS enabl

Re: [PATCH 0/7] padata: parallelize deferred page init

other virtual machines may have a huge amount of memory but not necessarily run for a long time; on such systems, boot time becomes critically important. Reducing boot time on cloud systems and VMs makes the difference between "leave running to reduce latency" and "just boot up when needed". - Josh Triplett

Re: Remaining randconfig objtool warnings, linux-next-20200428

e a bunch of irqs_disabled() checks, which means a bunch of PUSHFs with no POPFs. Am I reading it correctly that objtool assumes PUSHF is always paired with POPF? irqs_disabled() doesn't do that. -- Josh

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Thu, Apr 30, 2020 at 04:08:05PM -0500, Josh Poimboeuf wrote: > On Thu, Apr 30, 2020 at 02:46:30PM -0500, Josh Poimboeuf wrote: > > > Yup, makes sense. I think I've been getting confused by the syscall > > > wrappers. > > > > > > > How hard would

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Thu, Apr 30, 2020 at 10:59:44PM +0200, Arnd Bergmann wrote: > On Thu, Apr 30, 2020 at 9:46 PM Josh Poimboeuf wrote: > > On Thu, Apr 30, 2020 at 09:33:50AM -0500, Josh Poimboeuf wrote: > > > > > So there's an easy fix below, just define an x86-specific SYSCAL

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Thu, Apr 30, 2020 at 02:46:30PM -0500, Josh Poimboeuf wrote: > > Yup, makes sense. I think I've been getting confused by the syscall > > wrappers. > > > > > How hard would it be to change objtool instead of changing the sources? So I just realized this is

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Thu, Apr 30, 2020 at 09:33:50AM -0500, Josh Poimboeuf wrote: > On Thu, Apr 30, 2020 at 03:41:56PM +0200, Arnd Bergmann wrote: > > On Thu, Apr 30, 2020 at 1:28 AM Josh Poimboeuf wrote: > > > > > > On Wed, Apr 29, 2020 at 06:11:15PM -0500, Josh Poimboeuf wrote: >

[PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

6f20 ("bpf: Disable GCC -fgcse optimization for ___bpf_prog_run()") Reported-by: Randy Dunlap Reported-by: Arnd Bergmann Signed-off-by: Josh Poimboeuf --- include/linux/compiler-gcc.h | 2 -- include/linux/compiler_types.h | 4 kernel/bpf/core.c | 10 +++--- 3

Re: [PATCH v2 6/9] s390/module: Use s390_kernel_write() for late relocations

On Thu, Apr 30, 2020 at 10:38:21AM -0400, Joe Lawrence wrote: > On Thu, Apr 23, 2020 at 01:10:30PM -0500, Josh Poimboeuf wrote: > > On Thu, Apr 23, 2020 at 09:12:28AM -0500, Josh Poimboeuf wrote: > > > > > this is strange. While I would have expected an exception simil

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Thu, Apr 30, 2020 at 03:41:56PM +0200, Arnd Bergmann wrote: > On Thu, Apr 30, 2020 at 1:28 AM Josh Poimboeuf wrote: > > > > On Wed, Apr 29, 2020 at 06:11:15PM -0500, Josh Poimboeuf wrote: > > > > We can probably move those SYS_NI() instances to kernel/sys_ni.c, >

Re: BPF vs objtool again

bjtool is fine with the RETPOLINE double goto. It's only the !RETPOLINE double goto which is the problem, because that triggers more GCC weirdness (see 3193c0836f20). > Then pls do: > #if defined(CONFIG_RETPOLINE) || !defined(CONFIG_X86) > > since there is no need to mess with other archs. Getting rid of select_insn altogether would make the code a lot simpler, but it's your call. I'll make a patch soon. -- Josh

Re: [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool

On Wed, Apr 29, 2020 at 11:06:58PM -0500, Josh Poimboeuf wrote: > On Thu, Apr 30, 2020 at 10:32:17AM +0800, changhuaixin wrote: > > > > > > > On Apr 29, 2020, at 4:49 PM, Peter Zijlstra wrote: > > > > > > On Wed, Apr 29, 2020 at 02:46:24PM +0800, Hu

Re: [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool

the critical path. Thanks, I like it. It will help make the in-kernel unwinder even simpler. And it will enable unwinding from early boot. Maybe someday we can move all the table sorting code into objtool, once we have objtool running on vmlinux.o. I'll try to review the patches soon. -- Josh

Re: BPF vs objtool again

;code]; #else /* !CONFIG_RETPOLINE */ #define CONT ({ insn++; goto *jumptable[insn->code]; }) #define CONT_JMP ({ insn++; goto *jumptable[insn->code]; }) #endif /* CONFIG_RETPOLINE */ But since this is legacy path, I think the first one is much nicer. Also, JMP_TAIL_CALL has a "goto select_insn", is it ok to convert that to CONT? -- Josh

Re: BPF vs objtool again

On Wed, Apr 29, 2020 at 04:41:59PM -0700, Alexei Starovoitov wrote: > On Wed, Apr 29, 2020 at 04:51:59PM -0500, Josh Poimboeuf wrote: > > On Thu, Jul 18, 2019 at 12:14:08PM -0700, tip-bot for Josh Poimboeuf wrote: > > > Commit-ID: 3193c0836f203a91bef96d88c64cccf0be0

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Wed, Apr 29, 2020 at 06:11:15PM -0500, Josh Poimboeuf wrote: > > We can probably move those SYS_NI() instances to kernel/sys_ni.c, > > which does not include the header, but it's still a bit ugly. I'll try > > that tomorrow > > unless you come up with a better

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Thu, Apr 30, 2020 at 12:46:57AM +0200, Arnd Bergmann wrote: > On Wed, Apr 29, 2020 at 8:55 PM Josh Poimboeuf wrote: > > > > On Tue, Apr 28, 2020 at 11:10:44AM -0500, Josh Poimboeuf wrote: > > > > ==> build/x86/0xE0F2ACFF_defconfig/log <== > > > >

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Thu, Apr 30, 2020 at 12:46:57AM +0200, Arnd Bergmann wrote: > On Wed, Apr 29, 2020 at 8:55 PM Josh Poimboeuf wrote: > > > > On Tue, Apr 28, 2020 at 11:10:44AM -0500, Josh Poimboeuf wrote: > > > > ==> build/x86/0xE0F2ACFF_defconfig/log <== > > > >

BPF vs objtool again

On Thu, Jul 18, 2019 at 12:14:08PM -0700, tip-bot for Josh Poimboeuf wrote: > Commit-ID: 3193c0836f203a91bef96d88c64cccf0be090d9c > Gitweb: > https://git.kernel.org/tip/3193c0836f203a91bef96d88c64cccf0be090d9c > Author: Josh Poimboeuf > AuthorDate: Wed, 17 Jul 2019

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Tue, Apr 28, 2020 at 11:10:44AM -0500, Josh Poimboeuf wrote: > > ==> build/x86/0x2EA4CE4F_defconfig/log <== > > kernel/kcov.o: warning: objtool: write_comp_data()+0x1b: call to > > check_kcov_mode() with UACCESS enabled > > kernel/kcov.o: warning: objtool: __sanit

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Tue, Apr 28, 2020 at 11:10:44AM -0500, Josh Poimboeuf wrote: > > ==> build/x86/0xE0F2ACFF_defconfig/log <== > > kernel/time/posix-stubs.o: warning: objtool: __x64_sys_timer_create()+0x23: > > sibling call from callable instruction with modified stack frame This one is

[PATCH v4 01/11] livepatch: Disallow vmlinux.ko

ggested-by: Peter Zijlstra Signed-off-by: Josh Poimboeuf Acked-by: Miroslav Benes Acked-by: Joe Lawrence --- kernel/livepatch/core.c | 5 + 1 file changed, 5 insertions(+) diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index c3512e7e0801..40cfac8156fd 100644 --- a/kernel/livepa

[PATCH v4 07/11] x86/module: Use text_poke() for late relocations

state to determine whether memcpy() can be used. Implement text_poke() for UML. ] Cc: x...@kernel.org Suggested-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Acked-by: Joe Lawrence Acked-by: Miroslav Benes

[PATCH v4 05/11] s390: Change s390_kernel_write() return type to match memcpy()

s390_kernel_write()'s function type is almost identical to memcpy(). Change its return type to "void *" so they can be used interchangeably. Cc: linux-s...@vger.kernel.org Cc: heiko.carst...@de.ibm.com Signed-off-by: Josh Poimboeuf Acked-by: Joe Lawrence Acked-by: Miroslav Benes

[PATCH v4 06/11] s390/module: Use s390_kernel_write() for late relocations

state to determine whether memcpy() can be used. Test and add fixes. ] Cc: linux-s...@vger.kernel.org Cc: Heiko Carstens Cc: Gerald Schaefer Cc: Christian Borntraeger Suggested-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Josh Poimboeuf Acked-by: Peter

[PATCH v4 04/11] livepatch: Prevent module-specific KLP rela sections from referencing vmlinux symbols

Prevent module-specific KLP rela sections from referencing vmlinux symbols. This helps prevent ordering issues with module special section initializations. Presumably such symbols are exported and normal relas can be used instead. Suggested-by: Peter Zijlstra Signed-off-by: Josh Poimboeuf

[PATCH v4 08/11] livepatch: Remove module_disable_ro() usage

With arch_klp_init_object_loaded() gone, and apply_relocate_add() now using text_poke(), livepatch no longer needs to use module_disable_ro(). Signed-off-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Acked-by: Joe Lawrence Acked-by: Miroslav Benes --- kernel/livepatch/core.c | 2 -- 1

[PATCH v4 03/11] livepatch: Remove .klp.arch

27;t have to worry about them when removing module_disable_ro(). [ jpoimboe: Rewrote patch description. Tweaked klp_init_object_loaded() error path. ] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Acked-by: Joe Lawrence Acked-by:

[PATCH v4 02/11] livepatch: Apply vmlinux-specific KLP relocations early

g problems still exist and we *do* still need .klp.arch. Or do we? Stay tuned. Suggested-by: Peter Zijlstra Signed-off-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Acked-by: Joe Lawrence Acked-by: Miroslav Benes --- include/linux/livepatch.h | 14 kernel/livepatch/core.c |

[PATCH v4 09/11] module: Remove module_disable_ro()

module_disable_ro() has no more users. Remove it. Signed-off-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Acked-by: Joe Lawrence Acked-by: Miroslav Benes --- include/linux/module.h | 2 -- kernel/module.c| 13 - 2 files changed, 15 deletions(-) diff --git a

[PATCH v4 10/11] x86/module: Use text_mutex in apply_relocate_add()

same task. Signed-off-by: Josh Poimboeuf Acked-by: Joe Lawrence Acked-by: Miroslav Benes --- arch/x86/kernel/module.c | 9 +++-- kernel/livepatch/core.c | 6 -- 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c index 7614f47

[PATCH v4 11/11] module: Make module_enable_ro() static again

Now that module_enable_ro() has no more external users, make it static again. Suggested-by: Jessica Yu Signed-off-by: Josh Poimboeuf --- include/linux/module.h | 6 -- kernel/module.c| 4 ++-- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/include/linux/module.h b

[PATCH v4 00/11] livepatch,module: Remove .klp.arch and module_disable_ro()

tps://lkml.kernel.org/r/20191021135312.jbbxsuipxldocdjk@treble This has been tested with kpatch-build integration tests and klp-convert selftests. Josh Poimboeuf (8): livepatch: Disallow vmlinux.ko livepatch: Apply vmlinux-specific KLP relocations early livepatch: Prevent module-specific KLP rela se

Re: linux-next: Tree for Apr 29 (objtool warning)

t; call to __stack_chk_fail() with UACCESS enabled > > Full randconfig file is attached. Peter, I think should __stack_chk_fail() be on the safe list? -- Josh

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Tue, Apr 28, 2020 at 05:48:38PM -0500, Josh Poimboeuf wrote: > On Wed, Apr 29, 2020 at 12:33:27AM +0200, Peter Zijlstra wrote: > > On Tue, Apr 28, 2020 at 05:03:53PM -0500, Josh Poimboeuf wrote: > > > On Tue, Apr 28, 2020 at 11:55:54PM +0200, Peter Zijlstra wrote: > >

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Wed, Apr 29, 2020 at 12:33:27AM +0200, Peter Zijlstra wrote: > On Tue, Apr 28, 2020 at 05:03:53PM -0500, Josh Poimboeuf wrote: > > On Tue, Apr 28, 2020 at 11:55:54PM +0200, Peter Zijlstra wrote: > > > > binutils.git/gas/configure/tc-i386.c:i386_generate_nops > > >

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Tue, Apr 28, 2020 at 11:55:54PM +0200, Peter Zijlstra wrote: > On Tue, Apr 28, 2020 at 03:38:55PM -0500, Josh Poimboeuf wrote: > > This one makes no sense to me. It looks like the assembler is inserting > > a jump as part of the alignment padding??? WTH. > >

[PATCH] objtool: Fix infinite loop in find_jump_table()

it didn't recognize the boundary between the two functions. Fix that with a new prev_insn_same_sym() helper, which doesn't cross subfunction boundaries. Reported-by: Kristen Carlson Accardi Signed-off-by: Josh Poimboeuf --- tools/objtool/check.c | 15 +-- 1 file changed,

Re: [PATCH] x86/unwind/orc: fix unused function warnings

ic int *cur_orc_ip_table = __start_orc_unwind_ip; > +static struct orc_entry *cur_orc_table = __start_orc_unwind; > > static void orc_sort_swap(void *_a, void *_b, int size) > { > -- > 2.26.0 > -- Josh

Re: Remaining randconfig objtool warnings, linux-next-20200428

On Tue, Apr 28, 2020 at 10:19:46PM +0200, Arnd Bergmann wrote: > On Tue, Apr 28, 2020 at 6:10 PM Josh Poimboeuf wrote: > > On Tue, Apr 28, 2020 at 04:49:15PM +0200, Arnd Bergmann wrote: > > > ==> build/x86/0xFD7B7323_defconfig/log <== > > > arch/x86/entry/entry_64

Re: [PATCH v2 00/14] objtool vs retpoline

valid ORC unwind information for them, which > in turn means we can now unwind through a retpoline. > > New since last time: > > - 1-3, alternatives vs ORC unwind > - 7-9: implement some suggestions from Julien > - addressed feedback For patches 2-14: Acked-by: Josh Poi

Re: [PATCH v2 02/14] objtool: Fix ORC vs alternatives

ffmovq $0x,0x78(%rsp) > f61: ff ff > f63: e8 00 00 00 00 callq f68 > f68: e9 73 02 00 00 jmpq 11e0 > ###sp:(und) bp:(und) type:call end:0 > f6d: 0f 1f 00nopl (%rax) &

Re: [PATCH v2 01/14] objtool: Allow branches within the same alternative.

LL, insn, *state); > if (ret && backtrace) > BT_FUNC("<=== (sym)", insn); > return ret; > --- a/tools/objtool/check.h > +++ b/tools/objtool/check.h > @@ -30,12 +30,13 @@ struct instruction { > unsigned int len; > enum insn_type type; > unsigned long immediate; > - bool alt_group, dead_end, ignore, ignore_alts; > + bool dead_end, ignore, ignore_alts; > bool hint; > bool retpoline_safe; > s8 instr; > u8 visited; > u8 ret_offset; > + int alt_group; > struct symbol *call_dest; > struct instruction *jump_dest; > struct instruction *first_jump_src; > > -- Josh

Re: [PATCH v3 09/10] module: Remove module_disable_ro()

On Tue, Apr 28, 2020 at 06:41:55PM +0200, Jessica Yu wrote: > +++ Josh Poimboeuf [28/04/20 11:36 -0500]: > > On Tue, Apr 28, 2020 at 06:25:05PM +0200, Jessica Yu wrote: > > > +++ Josh Poimboeuf [25/04/20 06:07 -0500]: > > > > module_disable_ro()

<    3   4   5   6   7   8   9   10   11   12   >