Re: [PATCH 01/15] objtool: Find a destination for jumps beyond the section end

2021-04-20 Thread Josh Poimboeuf
On Tue, Apr 20, 2021 at 01:25:43PM -0700, Sami Tolvanen wrote: > On Tue, Apr 20, 2021 at 11:14 AM Josh Poimboeuf wrote: > > > > On Fri, Apr 16, 2021 at 01:38:30PM -0700, Sami Tolvanen wrote: > > > With -ffunction-sections, Clang can generate a jump beyond the end

Re: [PATCH 02/15] objtool: Add CONFIG_CFI_CLANG support

2021-04-20 Thread Josh Poimboeuf
On Fri, Apr 16, 2021 at 01:38:31PM -0700, Sami Tolvanen wrote: > +static int fix_cfi_relocs(const struct elf *elf) > +{ > + struct section *sec, *tmpsec; > + struct reloc *reloc, *tmpreloc; > + > + list_for_each_entry_safe(sec, tmpsec, >sections, list) { > +

Re: [PATCH 01/15] objtool: Find a destination for jumps beyond the section end

2021-04-20 Thread Josh Poimboeuf
On Fri, Apr 16, 2021 at 01:38:30PM -0700, Sami Tolvanen wrote: > With -ffunction-sections, Clang can generate a jump beyond the end of > a section when the section ends in an unreachable instruction. Why? Can you show an example? -- Josh

[tip: objtool/core] x86/crypto/aesni-intel_avx: Standardize stack alignment prologue

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: e163be86fff3deec70f63330fc43fedf892c9aee Gitweb: https://git.kernel.org/tip/e163be86fff3deec70f63330fc43fedf892c9aee Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:17 -06:00

[tip: objtool/core] x86/crypto/aesni-intel_avx: Remove unused macros

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: 4f08300916e882a0c34a2f325ff3fea2be2e57b3 Gitweb: https://git.kernel.org/tip/4f08300916e882a0c34a2f325ff3fea2be2e57b3 Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:15 -06:00

[tip: objtool/core] x86/crypto/aesni-intel_avx: Fix register usage comments

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: ff5796b6dbea4763fdca002101e32b60aa17f8e8 Gitweb: https://git.kernel.org/tip/ff5796b6dbea4763fdca002101e32b60aa17f8e8 Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:16 -06:00

[tip: objtool/core] objtool: Support asm jump tables

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: 99033461e685b48549ec77608b4bda75ddf772ce Gitweb: https://git.kernel.org/tip/99033461e685b48549ec77608b4bda75ddf772ce Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:14 -06:00

[tip: objtool/core] x86/crypto/sha512-avx2: Standardize stack alignment prologue

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: ec063e090bd6487097d459bb4272508b78448270 Gitweb: https://git.kernel.org/tip/ec063e090bd6487097d459bb4272508b78448270 Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:24 -06:00

[tip: objtool/core] x86/crypto/sha_ni: Standardize stack alignment prologue

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: 35a0067d2c02a7c35466db5f207b7b9265de84d9 Gitweb: https://git.kernel.org/tip/35a0067d2c02a7c35466db5f207b7b9265de84d9 Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:20 -06:00

[tip: objtool/core] x86/crypto/crc32c-pcl-intel: Standardize jump table

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: 2b02ed55482a1c5c310a7f53707292fcf1601e7a Gitweb: https://git.kernel.org/tip/2b02ed55482a1c5c310a7f53707292fcf1601e7a Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:19 -06:00

[tip: objtool/core] x86/crypto/camellia-aesni-avx2: Unconditionally allocate stack buffer

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: dabe5167a3cbb4bf16b20c0e5b6497513e2e3a08 Gitweb: https://git.kernel.org/tip/dabe5167a3cbb4bf16b20c0e5b6497513e2e3a08 Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:18 -06:00

[tip: objtool/core] x86/crypto/sha512-ssse3: Standardize stack alignment prologue

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: 27d26793f2105281d9374928448142777cef6f74 Gitweb: https://git.kernel.org/tip/27d26793f2105281d9374928448142777cef6f74 Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:25 -06:00

[tip: objtool/core] x86/crypto/sha256-avx2: Standardize stack alignment prologue

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: ce5846668076aa76a17ab559f0296374e3611fec Gitweb: https://git.kernel.org/tip/ce5846668076aa76a17ab559f0296374e3611fec Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:22 -06:00

[tip: objtool/core] x86/crypto/sha1_avx2: Standardize stack alignment prologue

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: 20114c899cafa8313534a841cab0ab1f7ab09672 Gitweb: https://git.kernel.org/tip/20114c899cafa8313534a841cab0ab1f7ab09672 Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:21 -06:00

[tip: objtool/core] x86/crypto: Enable objtool in crypto code

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: 7d3d10e0e85fb7c23a86a70f795b1eabd2bc030b Gitweb: https://git.kernel.org/tip/7d3d10e0e85fb7c23a86a70f795b1eabd2bc030b Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:26 -06:00

[tip: objtool/core] x86/crypto/sha512-avx: Standardize stack alignment prologue

2021-04-20 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the objtool/core branch of tip: Commit-ID: d61684b56edf369f0a6d388088d7c9d59f1618d4 Gitweb: https://git.kernel.org/tip/d61684b56edf369f0a6d388088d7c9d59f1618d4 Author:Josh Poimboeuf AuthorDate:Wed, 24 Feb 2021 10:29:23 -06:00

Re: [PATCH v2] X86: Makefile: Replace -pg with CC_FLAGS_FTRACE

2021-04-16 Thread Josh Poimboeuf
Adding Steven Rostedt (ftrace maintainer). On Fri, Apr 16, 2021 at 01:39:28PM +0800, zhaoxiao wrote: > In preparation for x86 supporting ftrace built on other compiler > options, let's have the x86 Makefiles remove the $(CC_FLAGS_FTRACE) > flags, whatever these may be, rather than assuming '-pg'.

Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks

2021-04-13 Thread Josh Poimboeuf
On Mon, Apr 12, 2021 at 05:59:33PM +0100, Mark Brown wrote: > On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote: > > > Hm, for that matter, even without renaming things, a comment above > > stack_trace_save_tsk_reliable() describing the meaning of "reliable&qu

Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks

2021-04-09 Thread Josh Poimboeuf
On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote: > On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote: > > > FWIW, over the years we've had zero issues with encoding the frame > > > pointer on x86. After you save pt_regs, you enc

Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks

2021-04-09 Thread Josh Poimboeuf
On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote: > > FWIW, over the years we've had zero issues with encoding the frame > > pointer on x86. After you save pt_regs, you encode the frame pointer to > > point to it. Ideally in the same macro so it's hard to overlook. > > >

Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks

2021-04-09 Thread Josh Poimboeuf
On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote: > On Mon, Apr 05, 2021 at 03:43:09PM -0500, madve...@linux.microsoft.com wrote: > > From: "Madhavan T. Venkataraman" > > > > There are a number of places in kernel code where the stack trace is not > > reliable. Enhance the unwinder

Re: [PATCH 0/5] Introduce support for PSF mitigation

2021-04-09 Thread Josh Poimboeuf
On Thu, Apr 08, 2021 at 09:56:47AM -0500, Saripalli, RK wrote: > Josh, thank you for taking the time to review the patches. > > On 4/7/2021 5:39 PM, Josh Poimboeuf wrote: > > On Tue, Apr 06, 2021 at 10:49:59AM -0500, Ramakrishna Saripalli wrote: > >> Because PS

Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate

2021-04-08 Thread Josh Poimboeuf
On Thu, Apr 08, 2021 at 08:18:21AM +0200, Greg KH wrote: > On Wed, Apr 07, 2021 at 03:17:46PM -0500, Josh Poimboeuf wrote: > > On Fri, Apr 02, 2021 at 09:54:12AM +0200, Greg KH wrote: > > > On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote: > > > > As

Re: [PATCH 0/5] Introduce support for PSF mitigation

2021-04-07 Thread Josh Poimboeuf
On Tue, Apr 06, 2021 at 10:49:59AM -0500, Ramakrishna Saripalli wrote: > Because PSF speculation is limited to the current program context, > the impact of bad PSF speculation is very similar to that of > Speculative Store Bypass (Spectre v4) > > Predictive Store Forwarding controls: > There are

Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate

2021-04-07 Thread Josh Poimboeuf
On Fri, Apr 02, 2021 at 09:54:12AM +0200, Greg KH wrote: > On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote: > > As for the syfs deadlock possible with drivers, this fixes it in a generic > > way: > > > > commit fac43d8025727a74f80a183cc5eb74ed902a5d14 > > Author: Luis

Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate

2021-04-07 Thread Josh Poimboeuf
On Wed, Apr 07, 2021 at 04:09:44PM +0200, Peter Zijlstra wrote: > On Tue, Apr 06, 2021 at 10:54:23AM -0500, Josh Poimboeuf wrote: > > > Same for Red Hat. Unloading livepatch modules seems to work fine, but > > isn't officially supported. > > > > That sai

Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate

2021-04-06 Thread Josh Poimboeuf
On Tue, Apr 06, 2021 at 02:00:19PM +0200, Miroslav Benes wrote: > Hi, > > > > Driver developers will simply have to open code these protections. In > > > light of what I see on LTP / fuzzing, I suspect the use case will grow > > > and we'll have to revisit this in the future. But for now, sure,

Re: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks

2021-04-03 Thread Josh Poimboeuf
On Tue, Mar 30, 2021 at 02:09:51PM -0500, madve...@linux.microsoft.com wrote: > From: "Madhavan T. Venkataraman" > > There are a number of places in kernel code where the stack trace is not > reliable. Enhance the unwinder to check for those cases and mark the > stack trace as unreliable. Once

Re: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record

2021-04-03 Thread Josh Poimboeuf
On Thu, Apr 01, 2021 at 10:24:04PM -0500, madve...@linux.microsoft.com wrote: > From: "Madhavan T. Venkataraman" > @@ -447,9 +464,9 @@ SYM_FUNC_START_LOCAL(__primary_switched) > #endif > bl switch_to_vhe // Prefer VHE if possible > add sp, sp, #16 > -

Re: [RFC PATCH -tip 3/3] x86/kprobes,orc: Unwind optprobe trampoline correctly

2021-03-31 Thread Josh Poimboeuf
On Wed, Mar 31, 2021 at 02:44:56PM +0900, Masami Hiramatsu wrote: > +#ifdef CONFIG_UNWINDER_ORC > +unsigned long recover_optprobe_trampoline(unsigned long addr, unsigned long > *sp) > +{ > + unsigned long offset, entry, probe_addr; > + struct optimized_kprobe *op; > + struct orc_entry

Re: [PATCH -tip v4 10/12] x86/kprobes: Push a fake return address at kretprobe_trampoline

2021-03-29 Thread Josh Poimboeuf
On Fri, Mar 26, 2021 at 10:20:09AM -0400, Steven Rostedt wrote: > On Fri, 26 Mar 2021 21:03:49 +0900 > Masami Hiramatsu wrote: > > > I confirmed this is not related to this series, but occurs when I build > > kernels with different > > configs without cleanup. > > > > Once I build kernel with

Re: [PATCH v3 16/16] objtool,x86: Rewrite retpoline thunk calls

2021-03-29 Thread Josh Poimboeuf
On Fri, Mar 26, 2021 at 04:12:15PM +0100, Peter Zijlstra wrote: > @@ -61,3 +89,15 @@ SYM_FUNC_END(__x86_indirect_thunk_\reg) > #define GEN(reg) EXPORT_THUNK(reg) > #include > > +#undef GEN > +#define GEN(reg) ALT_THUNK reg > +#include > + > +#undef GEN > +#define GEN(reg)

Re: [PATCH -tip v4 10/12] x86/kprobes: Push a fake return address at kretprobe_trampoline

2021-03-24 Thread Josh Poimboeuf
On Wed, Mar 24, 2021 at 10:40:58AM +0900, Masami Hiramatsu wrote: > On Tue, 23 Mar 2021 23:30:07 +0100 > Peter Zijlstra wrote: > > > On Mon, Mar 22, 2021 at 03:41:40PM +0900, Masami Hiramatsu wrote: > > > ".global kretprobe_trampoline\n" > > > ".type kretprobe_trampoline, @function\n" > > >

Re: [PATCH -tip v3 05/11] x86/kprobes: Add UNWIND_HINT_FUNC on kretprobe_trampoline code

2021-03-21 Thread Josh Poimboeuf
On Sat, Mar 20, 2021 at 10:05:43PM +0900, Masami Hiramatsu wrote: > On Sat, 20 Mar 2021 21:16:16 +0900 > Masami Hiramatsu wrote: > > > On Fri, 19 Mar 2021 21:22:39 +0900 > > Masami Hiramatsu wrote: > > > > > From: Josh Poimboeuf > > > > >

Re: [PATCH -tip v3 05/11] x86/kprobes: Add UNWIND_HINT_FUNC on kretprobe_trampoline code

2021-03-21 Thread Josh Poimboeuf
On Sat, Mar 20, 2021 at 09:16:16PM +0900, Masami Hiramatsu wrote: > On Fri, 19 Mar 2021 21:22:39 +0900 > Masami Hiramatsu wrote: > > > From: Josh Poimboeuf > > > > Add UNWIND_HINT_FUNC on kretporbe_trampoline code so that ORC > > information is generated on t

Re: [PATCH v2 14/14] objtool,x86: Rewrite retpoline thunk calls

2021-03-19 Thread Josh Poimboeuf
On Fri, Mar 19, 2021 at 04:56:30PM +0100, Peter Zijlstra wrote: > On Fri, Mar 19, 2021 at 10:30:26AM -0500, Josh Poimboeuf wrote: > > On Fri, Mar 19, 2021 at 09:06:44AM +0100, Peter Zijlstra wrote: > > > > Also doesn't the alternative code already insert nops?

Re: [PATCH v2 08/14] objtool: Add elf_create_reloc() helper

2021-03-19 Thread Josh Poimboeuf
On Fri, Mar 19, 2021 at 04:24:40PM +0100, Peter Zijlstra wrote: > On Fri, Mar 19, 2021 at 10:12:59AM -0500, Josh Poimboeuf wrote: > > > > -void elf_add_reloc(struct elf *elf, struct reloc *reloc) > > > +int elf_add_reloc(struct elf *elf, struct section *sec, uns

Re: [PATCH v2 14/14] objtool,x86: Rewrite retpoline thunk calls

2021-03-19 Thread Josh Poimboeuf
On Fri, Mar 19, 2021 at 09:06:44AM +0100, Peter Zijlstra wrote: > > Also doesn't the alternative code already insert nops? > > Problem is that the {call,jmp} *%\reg thing is not fixed length. They're > 2 or 3 bytes depending on which register is picked. Why do they need to be fixed length?

Re: [PATCH 5/9] objtool: Rework rebuild_reloc logic

2021-03-19 Thread Josh Poimboeuf
On Fri, Mar 19, 2021 at 10:22:54AM +0100, Peter Zijlstra wrote: > @@ -814,6 +814,11 @@ struct section *elf_create_reloc_section > } > } > > +static inline bool is_reloc_section(struct section *reloc) > +{ > + return reloc->base && reloc->base->reloc == reloc; > +} I believe the 2nd

Re: [PATCH v2 08/14] objtool: Add elf_create_reloc() helper

2021-03-19 Thread Josh Poimboeuf
On Fri, Mar 19, 2021 at 10:47:36AM +0100, Peter Zijlstra wrote: > Full patch, because diff on a diff on a diff is getting ludicrous hard > to read :-) Appreciated :-) > -void elf_add_reloc(struct elf *elf, struct reloc *reloc) > +int elf_add_reloc(struct elf *elf, struct section *sec, unsigned

Re: [PATCH v2 10/14] objtool: Extract elf_symbol_add()

2021-03-19 Thread Josh Poimboeuf
On Fri, Mar 19, 2021 at 10:54:05AM +0100, Peter Zijlstra wrote: > On Thu, Mar 18, 2021 at 09:14:03PM -0500, Josh Poimboeuf wrote: > > On Thu, Mar 18, 2021 at 06:11:13PM +0100, Peter Zijlstra wrote: > > > Create a common helper to add symbols. > > > > > >

Re: [PATCH v2 14/14] objtool,x86: Rewrite retpoline thunk calls

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 06:11:17PM +0100, Peter Zijlstra wrote: > When the compiler emits: "CALL __x86_indirect_thunk_\reg" for an > indirect call, have objtool rewrite it to: > > ALTERNATIVE "call __x86_indirect_thunk_\reg", > "call *%reg", ALT_NOT(X86_FEATURE_RETPOLINE)

Re: [PATCH v2 12/14] objtool: Allow archs to rewrite retpolines

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 06:11:15PM +0100, Peter Zijlstra wrote: > @@ -1212,6 +1225,8 @@ static int handle_group_alt(struct objto > dest_off = arch_jump_destination(insn); > if (dest_off == special_alt->new_off + special_alt->new_len) >

Re: [PATCH v2 05/14] objtool: Per arch retpoline naming

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 06:11:08PM +0100, Peter Zijlstra wrote: > @@ -872,7 +877,7 @@ static int add_jump_destinations(struct > } else if (reloc->sym->type == STT_SECTION) { > dest_sec = reloc->sym->sec; > dest_off =

Re: [PATCH v2 11/14] objtool: Add elf_create_undef_symbol()

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 06:11:14PM +0100, Peter Zijlstra wrote: > Allow objtool to create undefined symbols; this allows creating > relocations to symbols not currently in the symbol table. > > Signed-off-by: Peter Zijlstra (Intel) > --- > tools/objtool/elf.c | 63 >

Re: [PATCH v2 10/14] objtool: Extract elf_symbol_add()

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 06:11:13PM +0100, Peter Zijlstra wrote: > Create a common helper to add symbols. > > Signed-off-by: Peter Zijlstra (Intel) > --- > tools/objtool/elf.c | 57 > ++-- > 1 file changed, 33 insertions(+), 24 deletions(-) > >

Re: [PATCH v2 09/14] objtool: Extract elf_strtab_concat()

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 06:11:12PM +0100, Peter Zijlstra wrote: > Create a common helper to append strings to a strtab. > > Signed-off-by: Peter Zijlstra (Intel) > --- > tools/objtool/elf.c | 73 > +--- > 1 file changed, 42 insertions(+), 31

Re: [PATCH v2 08/14] objtool: Add elf_create_reloc() helper

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 06:11:11PM +0100, Peter Zijlstra wrote: > We have 4 instances of adding a relocation. Create a common helper > to avoid growing even more. > > Signed-off-by: Peter Zijlstra (Intel) I'm not a fan of the API -- how about squashing this in? Untested, of course. diff --git

Re: [PATCH 5/9] objtool: Rework rebuild_reloc logic

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 12:38:42PM -0500, Josh Poimboeuf wrote: > On Thu, Mar 18, 2021 at 06:04:25PM +0100, Peter Zijlstra wrote: > > On Thu, Mar 18, 2021 at 11:36:40AM -0500, Josh Poimboeuf wrote: > > > > I was thinking you could get a section changed without touchin

Re: [PATCH] kbuild: rebuild GCC plugins when the compiler is upgraded

2021-03-18 Thread Josh Poimboeuf
On Wed, Mar 10, 2021 at 10:44:46PM +0900, Masahiro Yamada wrote: > > Masahiro, > > > > Ping. Do you have a better approach for building GCC plugins in the > > external module directory? > > > I am not sure if building GCC plugins in the external module directory > is the right approach. I'm

Re: [PATCH 5/9] objtool: Rework rebuild_reloc logic

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 06:04:25PM +0100, Peter Zijlstra wrote: > On Thu, Mar 18, 2021 at 11:36:40AM -0500, Josh Poimboeuf wrote: > > > I was thinking you could get a section changed without touching > > > relocations, but while that is theoretically possible, it is excee

Re: [PATCH 5/9] objtool: Rework rebuild_reloc logic

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 01:57:03PM +0100, Peter Zijlstra wrote: > On Wed, Mar 17, 2021 at 07:49:17PM -0500, Josh Poimboeuf wrote: > > On Wed, Mar 17, 2021 at 09:12:15AM +0100, Peter Zijlstra wrote: > > > On Tue, Mar 16, 2021 at 10:34:17PM -0500, Josh Poimboeuf wrote: > >

Re: [PATCH 3/3] static_call: Fix static_call_update() sanity check

2021-03-18 Thread Josh Poimboeuf
On Thu, Mar 18, 2021 at 12:31:59PM +0100, Peter Zijlstra wrote: > if (!kernel_text_address((unsigned long)site_addr)) { > - WARN_ONCE(1, "can't patch static call site at > %pS", > + /* > + *

Re: [PATCH 5/9] objtool: Rework rebuild_reloc logic

2021-03-17 Thread Josh Poimboeuf
On Wed, Mar 17, 2021 at 09:12:15AM +0100, Peter Zijlstra wrote: > On Tue, Mar 16, 2021 at 10:34:17PM -0500, Josh Poimboeuf wrote: > > On Fri, Mar 12, 2021 at 06:16:18PM +0100, Peter Zijlstra wrote: > > > --- a/tools/objtool/elf.c > > > +++ b/tools/objtool/elf.c >

Re: [PATCH 6/9] objtool: Add elf_create_undef_symbol()

2021-03-17 Thread Josh Poimboeuf
On Wed, Mar 17, 2021 at 03:13:43PM +0100, Peter Zijlstra wrote: > On Wed, Mar 17, 2021 at 02:52:23PM +0100, Miroslav Benes wrote: > > > > + if (!elf_symbol_add(elf, sym, SHN_XINDEX)) { > > > + WARN("elf_symbol_add"); > > > + return NULL; > > > + } > > > > SHN_XINDEX means that

Re: [PATCH v4 3/9] x86/entry: Convert ret_from_fork to C

2021-03-17 Thread Josh Poimboeuf
edule_tail_wrapper was > obsolete: the encode_frame_pointer mechanism (see copy_thread()) solves the > same problem more cleanly. > > Cc: Josh Poimboeuf > Signed-off-by: Andy Lutomirski Acked-by: Josh Poimboeuf -- Josh

Re: [PATCH v4 2/9] x86/kthread,dumpstack: Set task_pt_regs->cs.RPL=3 for kernel threads

2021-03-17 Thread Josh Poimboeuf
gt; + */ > + childregs->cs = 3; > + > kthread_frame_init(frame, sp, arg); > return 0; > } Acked-by: Josh Poimboeuf -- Josh

Re: [PATCH] objtool,static_call: Don't emit static_call_site for .exit.text

2021-03-17 Thread Josh Poimboeuf
On Wed, Mar 17, 2021 at 01:45:57PM +0100, Peter Zijlstra wrote: > arguably it simply isn't a good idea to use static_call() in __exit > code anyway, since module unload is never a performance critical path. Couldn't you make the same argument about __init functions, which are allowed to do static

Re: [PATCH 5/9] objtool: Rework rebuild_reloc logic

2021-03-16 Thread Josh Poimboeuf
On Fri, Mar 12, 2021 at 06:16:18PM +0100, Peter Zijlstra wrote: > --- a/tools/objtool/elf.c > +++ b/tools/objtool/elf.c > @@ -479,6 +479,8 @@ void elf_add_reloc(struct elf *elf, stru > > list_add_tail(>list, >reloc_list); > elf_hash_add(elf->reloc_hash, >hash, reloc_hash(reloc)); > +

Re: [PATCH 4/9] objtool: Fix static_call list generation

2021-03-16 Thread Josh Poimboeuf
On Fri, Mar 12, 2021 at 06:16:17PM +0100, Peter Zijlstra wrote: > @@ -1701,6 +1706,9 @@ static int decode_sections(struct objtoo > if (ret) > return ret; > > + /* > + * Must be before add_{jump_call}_desetination. > + */ s/desetination/destination/ -- Josh

Re: [PATCH 2/9] objtool: Correctly handle retpoline thunk calls

2021-03-16 Thread Josh Poimboeuf
On Fri, Mar 12, 2021 at 06:16:15PM +0100, Peter Zijlstra wrote: > Just like JMP handling, convert a direct CALL to a retpoline thunk > into a retpoline safe indirect CALL. > > Signed-off-by: Peter Zijlstra (Intel) > --- > tools/objtool/check.c | 12 > 1 file changed, 12

Re: [PATCH -tip v2 00/10] kprobes: Fix stacktrace with kretprobes

2021-03-15 Thread Josh Poimboeuf
On Fri, Mar 12, 2021 at 03:41:44PM +0900, Masami Hiramatsu wrote: > Hello, > > Here is the 2nd version of the series to fix the stacktrace with kretprobe. > > The 1st series is here; > > https://lore.kernel.org/bpf/161495873696.346821.10161501768906432924.stgit@devnote2/ > > In this version I

Re: [GIT pull] locking/urgent for v5.12-rc3

2021-03-15 Thread Josh Poimboeuf
On Mon, Mar 15, 2021 at 01:08:27PM +0100, Peter Zijlstra wrote: > On Mon, Mar 15, 2021 at 12:26:12PM +0100, Peter Zijlstra wrote: > > Ooooh, modules don't have this. They still have regular > > .static_call_sites sections, and *those* are unaligned. > > > > Section Headers: > > [Nr] Name

Re: [PATCH -tip 0/5] kprobes: Fix stacktrace in kretprobes

2021-03-11 Thread Josh Poimboeuf
On Thu, Mar 11, 2021 at 10:54:38AM +0900, Masami Hiramatsu wrote: > On Wed, 10 Mar 2021 19:06:15 -0600 > Josh Poimboeuf wrote: > > > On Thu, Mar 11, 2021 at 09:20:18AM +0900, Masami Hiramatsu wrote: > > > > > bool unwind_next_fr

Re: [PATCH -tip 0/5] kprobes: Fix stacktrace in kretprobes

2021-03-10 Thread Josh Poimboeuf
On Thu, Mar 11, 2021 at 09:20:18AM +0900, Masami Hiramatsu wrote: > > > bool unwind_next_frame(struct unwind_state *state) > > > { > > > unsigned long ip_p, sp, tmp, orig_ip = state->ip, prev_sp = state->sp; > > > @@ -536,6 +561,18 @@ bool unwind_next_frame(struct unwind_state *state) > > >

Re: [PATCH -tip 0/5] kprobes: Fix stacktrace in kretprobes

2021-03-10 Thread Josh Poimboeuf
On Thu, Mar 11, 2021 at 12:55:09AM +0900, Masami Hiramatsu wrote: > +#ifdef CONFIG_KRETPROBES > +static unsigned long orc_kretprobe_correct_ip(struct unwind_state *state) > +{ > + return kretprobe_find_ret_addr( > + (unsigned long)kretprobe_trampoline_addr(), > +

Re: [PATCH -tip 0/5] kprobes: Fix stacktrace in kretprobes

2021-03-10 Thread Josh Poimboeuf
On Wed, Mar 10, 2021 at 06:57:34PM +0900, Masami Hiramatsu wrote: > > If I understand correctly, for #1 you need an unwind hint which treats > > the instruction *after* the "pushq %rsp" as the beginning of the > > function. > > Thanks for the patch. In that case, should I still change the stack

Re: [PATCH] kbuild: rebuild GCC plugins when the compiler is upgraded

2021-03-09 Thread Josh Poimboeuf
On Fri, Mar 05, 2021 at 08:50:59PM -0600, Josh Poimboeuf wrote: > > Is this a bad coding contest? > > > > I am not asking you to add ugly ifeq or whatever > > hacks to say "this worked for me". > > > > Please feel free to do this in the fed

Re: [PATCH] objtool: Fix a memory leak bug

2021-03-09 Thread Josh Poimboeuf
On Tue, Mar 09, 2021 at 04:46:16PM +0800, Jiapeng Chong wrote: > Fix the following cppcheck warnings: > > tools/objtool/check.c(1102): error: Memory leak: orig_alt_group. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong Hi Jiapeng, Objtool is a short-running process which exits

Re: [PATCH -tip 0/5] kprobes: Fix stacktrace in kretprobes

2021-03-08 Thread Josh Poimboeuf
On Mon, Mar 08, 2021 at 11:52:10AM +0900, Masami Hiramatsu wrote: > So at the kretprobe handler, we have 2 issues. > 1) the return address (caller_func+0x15) is not on the stack. >this can be solved by searching from current->kretprobe_instances. > 2) the stack frame size of

[tip: x86/urgent] x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2

2021-03-06 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the x86/urgent branch of tip: Commit-ID: e504e74cc3a2c092b05577ce3e8e013fae7d94e6 Gitweb: https://git.kernel.org/tip/e504e74cc3a2c092b05577ce3e8e013fae7d94e6 Author:Josh Poimboeuf AuthorDate:Fri, 05 Feb 2021 08:24:02 -06:00

[tip: x86/urgent] x86/unwind/orc: Silence warnings caused by missing ORC data

2021-03-06 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the x86/urgent branch of tip: Commit-ID: b59cc97674c947861783ca92b9a6e7d043adba96 Gitweb: https://git.kernel.org/tip/b59cc97674c947861783ca92b9a6e7d043adba96 Author:Josh Poimboeuf AuthorDate:Fri, 05 Feb 2021 08:24:03 -06:00

[tip: x86/urgent] x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2

2021-03-06 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 8bd7b3980ca62904814d536b3a2453001992a0c3 Gitweb: https://git.kernel.org/tip/8bd7b3980ca62904814d536b3a2453001992a0c3 Author:Josh Poimboeuf AuthorDate:Fri, 05 Feb 2021 08:24:02 -06:00

[tip: x86/urgent] x86/unwind/orc: Silence warnings caused by missing ORC data

2021-03-06 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the x86/urgent branch of tip: Commit-ID: d072f941c1e234f8495cc4828370b180318bf49b Gitweb: https://git.kernel.org/tip/d072f941c1e234f8495cc4828370b180318bf49b Author:Josh Poimboeuf AuthorDate:Fri, 05 Feb 2021 08:24:03 -06:00

Re: [PATCH] kbuild: rebuild GCC plugins when the compiler is upgraded

2021-03-05 Thread Josh Poimboeuf
On Sat, Mar 06, 2021 at 11:18:31AM +0900, Masahiro Yamada wrote: > On Sat, Mar 6, 2021 at 10:28 AM Josh Poimboeuf wrote: > > > > On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote: > > > On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote: > >

Re: [PATCH] kbuild: rebuild GCC plugins when the compiler is upgraded

2021-03-05 Thread Josh Poimboeuf
On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote: > On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote: > > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook wrote: > > > > > > This seems fine to me, but I want to make sure Josh has somewhere to > &

Re: [PATCH] x86: kprobes: orc: Fix ORC walks in kretprobes

2021-03-05 Thread Josh Poimboeuf
On Fri, Mar 05, 2021 at 11:25:15AM -0800, Daniel Xu wrote: > > BTW, is this a regression? or CONFIG_UNWINDER_ORC has this issue before? > > It seems that the above commit just changed the default unwinder. This means > > OCR stack unwinder has this bug before that commit. > > I see your point --

Re: [PATCH RFC] kbuild: Prevent compiler mismatch with external modules

2021-03-05 Thread Josh Poimboeuf
still ugly. > > > I attached my alternative implementation. Thanks for the attached patch, yours looks much cleaner. Looks like it warns on *any* mismatch, rather than just a major.minor mismatch. But that's ok with me. Acked-by: Josh Poimboeuf -- Josh

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-05 Thread Josh Poimboeuf
On Sat, Mar 06, 2021 at 01:03:32AM +0900, Masahiro Yamada wrote: > > Ok. So it sounds like the best/easiest option is the original patch in > > this thread: when building an external module with a GCC mismatch, just > > disable the GCC plugin, with a warning (or an error for randstruct). > >

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-04 Thread Josh Poimboeuf
On Thu, Mar 04, 2021 at 11:12:42AM -0800, Linus Torvalds wrote: > On Thu, Mar 4, 2021 at 7:36 AM Masahiro Yamada wrote: > > > > All the kernel-space objects are rebuilt > > when the compiler is upgraded. > > I very much NAK'ed that one. Why did that go in? > > Or maybe I NAK'ed another version

Re: [PATCH] kbuild: rebuild GCC plugins when the compiler is upgraded

2021-03-04 Thread Josh Poimboeuf
On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote: > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook wrote: > > > > This seems fine to me, but I want to make sure Josh has somewhere to > > actually go with this. Josh, does this get you any closer? No, this doesn't seem to help me at all.

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-04 Thread Josh Poimboeuf
On Thu, Mar 04, 2021 at 09:27:28PM +0900, Masahiro Yamada wrote: > I agree with rebuilding GCC plugins when the compiler is upgraded > for *in-tree* building. > Linus had reported it a couple of months before, > and I just submitted a very easy fix. Hm? So does that mean that a GCC version

[tip: x86/urgent] x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2

2021-03-04 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 38b6eb474ed2df3d159396c3d4312c8a7b2d5196 Gitweb: https://git.kernel.org/tip/38b6eb474ed2df3d159396c3d4312c8a7b2d5196 Author:Josh Poimboeuf AuthorDate:Fri, 05 Feb 2021 08:24:02 -06:00

[tip: x86/urgent] x86/unwind/orc: Silence warnings caused by missing ORC data

2021-03-04 Thread tip-bot2 for Josh Poimboeuf
The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 86402dcc894951c0a363b6aee12d955ff923b35e Gitweb: https://git.kernel.org/tip/86402dcc894951c0a363b6aee12d955ff923b35e Author:Josh Poimboeuf AuthorDate:Fri, 05 Feb 2021 08:24:03 -06:00

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-03 Thread Josh Poimboeuf
On Wed, Mar 03, 2021 at 12:56:52PM -0800, Linus Torvalds wrote: > On Wed, Mar 3, 2021 at 12:24 PM Josh Poimboeuf wrote: > > > > Your nack is for a different reason: GCC plugins are second-class > > citizens. Fair enough... > > MNo, I didn't NAK it. Quite the rev

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-03 Thread Josh Poimboeuf
On Wed, Mar 03, 2021 at 11:25:34AM -0800, Linus Torvalds wrote: > On Wed, Mar 3, 2021 at 11:15 AM Josh Poimboeuf wrote: > > > > Adding Linus, who indicated in another thread that we shouldn't force > > exact GCC versions because there's no technical reason to do so. >

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-03 Thread Josh Poimboeuf
On Wed, Mar 03, 2021 at 02:24:12PM -0600, Josh Poimboeuf wrote: > On Wed, Mar 03, 2021 at 11:57:33AM -0800, Linus Torvalds wrote: > > On Wed, Mar 3, 2021 at 11:38 AM Josh Poimboeuf wrote: > > > > > > > But in the meantime, making the plugins depend on the gcc version

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-03 Thread Josh Poimboeuf
On Wed, Mar 03, 2021 at 11:57:33AM -0800, Linus Torvalds wrote: > On Wed, Mar 3, 2021 at 11:38 AM Josh Poimboeuf wrote: > > > > > But in the meantime, making the plugins depend on the gcc version some > > > way is certainly better than not doing so. > > > &g

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-03 Thread Josh Poimboeuf
On Thu, Mar 04, 2021 at 03:49:35AM +0900, Masahiro Yamada wrote: > > This problem is becoming more prevalent. We will need to fix it one way > > or another, if we want to support distro adoption of these GCC > > plugin-based features. > > > > Frank suggested a possibly better idea: always rebuild

Re: [PATCH 0/3] objtool: OBJTOOL_ARGS and --backup

2021-03-03 Thread Josh Poimboeuf
On Fri, Feb 26, 2021 at 11:57:42AM +0100, Peter Zijlstra wrote: > Boris asked for an environment variable to have objtool preserve the original > object file so that it becomes trivial to inspect what actually changed. I might bikeshed the suffix ".o.orig" instead of ".

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-03 Thread Josh Poimboeuf
On Mon, Jan 25, 2021 at 02:42:10PM -0600, Josh Poimboeuf wrote: > When building out-of-tree kernel modules, the build system doesn't > require the GCC version to match the version used to build the original > kernel. That's probably [1] fine. > > In fact, for many distros, the

Upper bound mode for kernel timers

2021-03-01 Thread Josh Poimboeuf
Hi Thomas, As discussed on IRC: We had a report of a regression in the TCP keepalive timer. The user had a 3600s keepalive timer for preventing firewall disconnects (on a 3650s interval). They observed keepalive timers coming in up to four minutes late, causing unexpected disconnects. The

Re: [PATCH 00/13] x86/crypto/asm: objtool support

2021-02-25 Thread Josh Poimboeuf
On Thu, Feb 25, 2021 at 10:46:56AM +0100, Peter Zijlstra wrote: > On Wed, Feb 24, 2021 at 10:29:13AM -0600, Josh Poimboeuf wrote: > > Standardize the crypto asm to make it resemble compiler-generated code, > > so that objtool can understand it. > > > > This magically

Re: [PATCH 2/2] x86/unwind/orc: Silence warnings caused by missing ORC data

2021-02-24 Thread Josh Poimboeuf
On Wed, Feb 24, 2021 at 07:07:31PM +0100, Peter Zijlstra wrote: > On Wed, Feb 24, 2021 at 09:18:05AM -0600, Josh Poimboeuf wrote: > > On Wed, Feb 24, 2021 at 03:52:01PM +0100, Peter Zijlstra wrote: > > > On Fri, Feb 05, 2021 at 08:24:03AM -0600, Josh Poimboeuf wrote: > &

[PATCH 05/13] x86/crypto/camellia-aesni-avx2: Unconditionally allocate stack buffer

2021-02-24 Thread Josh Poimboeuf
A conditional stack allocation violates traditional unwinding requirements when a single instruction can have differing stack layouts. There's no benefit in allocating the stack buffer conditionally. Just do it unconditionally. Signed-off-by: Josh Poimboeuf --- arch/x86/crypto/camellia-aesni

[PATCH 12/13] x86/crypto/sha512-ssse3: Standardize stack alignment prologue

2021-02-24 Thread Josh Poimboeuf
Use a more standard prologue for saving the stack pointer before realigning the stack. This enables ORC unwinding by allowing objtool to understand the stack realignment. Signed-off-by: Josh Poimboeuf --- arch/x86/crypto/sha512-ssse3-asm.S | 41 ++ 1 file changed

[PATCH 08/13] x86/crypto/sha1_avx2: Standardize stack alignment prologue

2021-02-24 Thread Josh Poimboeuf
Use a more standard prologue for saving the stack pointer before realigning the stack. This enables ORC unwinding by allowing objtool to understand the stack realignment. Signed-off-by: Josh Poimboeuf --- arch/x86/crypto/sha1_avx2_x86_64_asm.S | 8 1 file changed, 4 insertions(+), 4

[PATCH 13/13] x86/crypto: Enable objtool in crypto code

2021-02-24 Thread Josh Poimboeuf
Now that all the stack alignment prologues have been cleaned up in the crypto code, enable objtool. Among other benefits, this will allow ORC unwinding to work. Signed-off-by: Josh Poimboeuf --- arch/x86/crypto/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/crypto

[PATCH 09/13] x86/crypto/sha256-avx2: Standardize stack alignment prologue

2021-02-24 Thread Josh Poimboeuf
Use a more standard prologue for saving the stack pointer before realigning the stack. This enables ORC unwinding by allowing objtool to understand the stack realignment. Signed-off-by: Josh Poimboeuf --- arch/x86/crypto/sha256-avx2-asm.S | 13 ++--- 1 file changed, 6 insertions(+), 7

[PATCH 04/13] x86/crypto/aesni-intel_avx: Standardize stack alignment prologue

2021-02-24 Thread Josh Poimboeuf
Use RBP instead of R14 for saving the old stack pointer before realignment. This resembles what compilers normally do. This enables ORC unwinding by allowing objtool to understand the stack realignment. Signed-off-by: Josh Poimboeuf --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 10

  1   2   3   4   5   6   7   8   9   10   >