ed-off-by: Wardenjohn
Acked-by: Josh Poimboeuf
--
Josh
On Tue, May 07, 2024 at 10:56:09AM +0800, zhang warden wrote:
>
>
> > On May 7, 2024, at 10:41, Josh Poimboeuf wrote:
> >
> > On Tue, May 07, 2024 at 10:21:40AM +0800, zhang warden wrote:
> >>
> >>
> >>>
> >>> transition
On Tue, May 07, 2024 at 10:21:40AM +0800, zhang warden wrote:
>
>
> >
> > transition state. With this marcos renamed, comments are not
> > necessary at this point.
> >
> Sorry for my careless, the comment still remains in the code. However,
> comment in the code do no harms here. Maybe it can
On Mon, Apr 29, 2024 at 03:26:28PM +0800, zhangwar...@gmail.com wrote:
> From: Wardenjohn
>
> livepatch.h use KLP_UNDEFINED\KLP_UNPATCHED\KLP_PATCHED for klp transition
> state.
> When livepatch is ready but idle, using KLP_UNDEFINED seems very confusing.
> In order not to introduce potential
On Sat, Apr 13, 2024 at 08:48:57AM -0400, Steven Rostedt wrote:
> On Sat, 13 Apr 2024 12:53:38 +0200
> Peter Zijlstra wrote:
>
> > On Fri, Apr 12, 2024 at 09:37:24AM -0700, Beau Belgrave wrote:
> >
> > > > Anyway, since we typically run stuff from NMI context, accessing user
> > > > data is
On Fri, Nov 10, 2023 at 06:04:21PM +0100, Petr Mladek wrote:
> This POC is a material for the discussion "Simplify Livepatch Callbacks,
> Shadow Variables, and States handling" at LPC 2013, see
> https://lpc.events/event/17/contributions/1541/
>
> It obsoletes the patchset adding the garbage
On Thu, Nov 09, 2023 at 02:50:48PM -0800, Ankur Arora wrote:
> >> I guess I'm not fully understanding what the cond rescheds are for. But
> >> would an IPI to all CPUs setting NEED_RESCHED, fix it?
>
> Yeah. We could just temporarily toggle to full preemption, when
> NEED_RESCHED_LAZY is always
On Thu, Nov 09, 2023 at 12:31:47PM -0500, Steven Rostedt wrote:
> On Thu, 9 Nov 2023 09:26:37 -0800
> Josh Poimboeuf wrote:
>
> > On Tue, Nov 07, 2023 at 06:16:09PM -0500, Steven Rostedt wrote:
> > > On Tue, 7 Nov 2023 13:56:53 -0800
> > > Ankur Arora wro
On Tue, Nov 07, 2023 at 06:16:09PM -0500, Steven Rostedt wrote:
> On Tue, 7 Nov 2023 13:56:53 -0800
> Ankur Arora wrote:
>
> > This reverts commit e3ff7c609f39671d1aaff4fb4a8594e14f3e03f8.
> >
> > Note that removing this commit reintroduces "live patches failing to
> > complete within a
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
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) {
> +
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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'.
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
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
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.
> >
>
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
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
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
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
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
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
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,
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
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
> -
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
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
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)
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"
> > >
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
> > >
> >
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
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?
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
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?
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
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
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.
> > >
> > >
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)
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)
>
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 =
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
>
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(-)
>
>
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
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
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
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
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
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:
> >
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",
> + /*
> + *
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
>
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
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
gt; + */
> + childregs->cs = 3;
> +
> kthread_frame_init(frame, sp, arg);
> return 0;
> }
Acked-by: Josh Poimboeuf
--
Josh
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
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));
> +
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
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
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
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
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
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)
> > >
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(),
> +
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
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
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
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
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
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
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
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
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:
> >
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
> &
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 --
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
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).
>
>
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
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.
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
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
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
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
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.
>
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
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
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
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 ".
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
1 - 100 of 7781 matches
Mail list logo
