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
code do no harms here. Maybe it can be kept.
The comments aren't actually correct.
For example, KLP_TRANSITION_UNPATCHED doesn't always mean "transitioning
to unpatched state". Sometimes it means "transitioning *from* unpatched
state".
--
Josh
N_UNPATCHED
KLP_TRANSITION_PATCHED
which shouldn't break userspace AFAIK.
--
Josh
ME work? Are there pointers to work I
> > > could look at and think about what a rebase looks like? Or do you have
> > > someone in mind I should work with for this?
> >
> > I've been offline for a little while and still need to catch up with
> > things
s_post_patch_replaced(void);
void klp_states_pre_unpatch_replaced(void);
void klp_states_post_unpatch_replaced(void);
?
(note that passing klp_transition_patch might be optional since state.c
already has visibility to it anyway)
--
Josh
d hook (because non-ORC
unwinders can't unwind reliably through preemption) which called klp to
unwind from the context of the task.
Without something to hook into, we have a problem. We could of course
hook into schedule(), but if the kthread never calls schedule() from a
non-preempted context then it still doesn't help.
--
Josh
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
if they go
through the preemption path then we have the same problem for non-ORC.
Worst case we'll need to sprinkle cond_livepatch() everywhere :-/
--
Josh
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
h then translates to
0009 06320004 R_X86_64_PLT32
x2apic_prepare_cpu - 4
so the original addend of '8' is no longer valid. Copying the '-4'
wouldn't be right either, because that only applies to a PLT32 text
reloc. A '0' should be appropriate for the 32S data reloc.
This addend might not actually be read by any code, so it may not
currently be an actual bug, but better safe than sorry.
--
Josh
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
On Mon, Apr 19, 2021 at 2:01 AM Peter Zijlstra wrote:
>
> Josh, you being on the other Google team, the one that actually uses the
> cgroup interface AFAIU, can you fight the good fight with TJ on this?
A bit of extra context is in
https://lore.kernel.org/lkml/cabk29nttsc
Hi Peter,
Looks reasonable to me.
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4756,7 +4756,8 @@
>
> sbni= [NET] Granch SBNI12 leased line adapter
>
> - sched_debug [KNL] Enables verbose
On Fri, Apr 16, 2021 at 8:05 AM Peter Zijlstra wrote:
>
> On Tue, Mar 30, 2021 at 03:44:12PM -0700, Josh Don wrote:
> > Peter,
> >
> > Since you've already pulled the need_resched warning patch into your
> > tree, I'm including just the diff based on that patch (in
if the tick is disabled.
This feature (LATENCY_WARN) is default disabled.
Signed-off-by: Paul Turner
Signed-off-by: Josh Don
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20210323035706.572953-1-josh...@google.com
---
This squashes the fixup from https://lkml.org/lkml/2021/3
On Fri, Apr 16, 2021 at 12:27:39PM +0800, Boqun Feng wrote:
> Josh, I think it's good if we can connect to the people working on Rust
> memoryg model, I think the right person is Ralf Jung and the right place
> is https://github.com/rust-lang/unsafe-code-guidelines, but you
> cer
@ -2,9 +2,9 @@
>
> ifdef CONFIG_FUNCTION_TRACER
> # Do not profile debug and lowlevel utilities
> -CFLAGS_REMOVE_spinlock.o = -pg
> -CFLAGS_REMOVE_time.o = -pg
> -CFLAGS_REMOVE_irq.o = -pg
> +CFLAGS_REMOVE_spinlock.o = $(CC_FLAGS_FTRACE)
> +CFLAGS_REMOVE_time.o = $(CC_FLAGS_FTRACE)
> +CFLAGS_REMOVE_irq.o = $(CC_FLAGS_FTRACE)
> endif
>
> # Make sure early boot has no stackprotector
> --
> 2.20.1
>
>
>
--
Josh
On Wed, Apr 14, 2021 at 01:21:52PM -0700, Linus Torvalds wrote:
> On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox wrote:
> >
> > There's a philosophical point to be discussed here which you're skating
> > right over! Should rust-in-the-linux-kernel provide the same memory
> > allocation APIs as
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
lp_reliable() which describes what that means.
Hm, for that matter, even without renaming things, a comment above
stack_trace_save_tsk_reliable() describing the meaning of "reliable"
would be a good idea.
--
Josh
.
The only exceptions which really matter are those which end up calling
schedule(), e.g. preemption or page faults.
Being able to consistently detect *all* possible unreliable paths would
be nice in theory, but it's unnecessary and may not be worth the extra
complexity.
--
Josh
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
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 6db12ee0456d0e369c7b59788d46e15a56ad0294
Gitweb:
https://git.kernel.org/tip/6db12ee0456d0e369c7b59788d46e15a56ad0294
Author:Josh Hunt
AuthorDate:Thu, 01 Apr 2021 22:58:33 -04:00
Committer
On Thu, Apr 8, 2021 at 9:47 AM Peter Zijlstra wrote:
>
> On Thu, Apr 08, 2021 at 03:25:52PM +0200, Michal Koutný wrote:
>
> > I'm curious whether the cgroup API actually simplifies things that are
> > possible with the clone/prctl API or allows anything that wouldn't be
> > otherwise possible.
>
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
is concerned with the
> speculative behavior of PSF but desires a smaller performance impact than
> setting SSBD.
Hi Ramakrishna,
Is there a realistic scenario where an application would want to disable
PSF, but not disable SSB?
Maybe I'm missing something, but I'd presume an application would either
care about this class of attacks, or not.
--
Josh
d extra energy
> and maintance of core things like sysfs for stuff like this that does
> not matter in any system other than a developer's box.
So I mentioned this on IRC, and some folks were surprised to hear that
module unloading is unsupported and is just a development aid.
Is this stance documented anywhere?
If we really believe this to be true, we should make rmmod taint the
kernel.
--
Josh
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
least at SUSE we do not support the option. But we are only one of the
> many downstream users. So yes, there is the option.
Same for Red Hat. Unloading livepatch modules seems to work fine, but
isn't officially supported.
That said, if rmmod is just considered a development aid, and we're
going to be ignoring bugs, we should make it official with a new
TAINT_RMMOD.
--
Josh
oline' on the stack, the unwinder needs a way to get the
original return address. Masami has been working on an interface to
make that possible for x86. I assume something similar could be done
for arm64.
> Optprobes
> =
>
> Optprobes may be implemented in the future for arm64. For optprobes,
> the relevant trampoline(s) can be added to special_functions[].
Similar comment here, livepatch doesn't unwind from such trampolines.
--
Josh
o unwind */
> + if (fp == (unsigned long) task_pt_regs(tsk)->stackframe)
> return -ENOENT;
As far as I can tell, the regs stackframe value is initialized to zero
during syscall entry, so isn't this basically just 'if (fp == 0)'?
Shouldn't it instead be comparing with the _address_ of the stackframe
field to make sure it reached the end?
--
Josh
Hi Peter,
I walked through the reference counting, and it seems good to me
(though it did take a few passes to fully digest the invariants for
the fat cookie stuff).
> +unsigned long sched_core_alloc_cookie(unsigned int type)
> {
> struct sched_core_cookie *ck = kmalloc(sizeof(*ck),
/lkml/2021/3/24/1485 ? If that doesn't work I think your
suggestion of reverting nolock makes sense to me. We've moved to using
fq as our default now b/c of this bug.
Josh
Currently only root can write files under /proc/pressure. Relax this to
allow tasks running as unprivileged users with CAP_SYS_RESOURCE to be
able to write to these files.
Signed-off-by: Josh Hunt
Acked-by: Johannes Weiner
---
kernel/sched/psi.c | 20 ++--
1 file changed, 14
Thanks, allowing for multiple group cookies in a hierarchy is a nice
improvement.
> + if (tgi != tg) {
> + if (tgi->core_cookie || (tgi->core_parent &&
> tgi->core_parent != tg))
> + continue;
> +
> +
> +/*
> + * sched_core_update_cookie - Common helper to update a task's core cookie.
> This
> + * updates the selected cookie field.
> + * @p: The task whose cookie should be updated.
> + * @cookie: The new cookie.
> + * @cookie_type: The cookie field to which the cookie corresponds.
No
On 4/1/21 10:47 AM, Eric W. Biederman wrote:
Kees Cook writes:
On Wed, Mar 31, 2021 at 11:36:28PM -0500, Eric W. Biederman wrote:
Josh Hunt writes:
Currently only root can write files under /proc/pressure. Relax this to
allow tasks running as unprivileged users with CAP_SYS_RESOURCE
Currently only root can write files under /proc/pressure. Relax this to
allow tasks running as unprivileged users with CAP_SYS_RESOURCE to be
able to write to these files.
Signed-off-by: Josh Hunt
---
kernel/sched/psi.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
d either ;-) ]
Of course the downside is, when you get an interrupt during the frame
pointer setup, unwinding is broken. But I think that's acceptable for
generated code. We've lived with that limitation for all code, with
CONFIG_FRAME_POINTER, for many years.
Eventually we may want to have a way to register generated code (and the
ORC for it).
--
Josh
Peter,
Since you've already pulled the need_resched warning patch into your
tree, I'm including just the diff based on that patch (in response to
Mel's comments) below. This should be squashed into the original
patch.
Thanks,
Josh
---
>From 85796b4d299b1cf3f99bde154a356ce1061221b7 Mon Sep 17
On Mon, Mar 29, 2021 at 2:55 AM Peter Zijlstra wrote:
>
> OK, fixed the fails. My tired head made it unconditionally return the
> cookie-id of 'current' instead of task. Pushed out an update.
I see you have the per-task and prctl stuff pulled into your tree. I
can rebase the compound cookie and
On Tue, Mar 30, 2021 at 2:29 AM Peter Zijlstra wrote:
> > On Wed, Mar 24, 2021 at 05:40:17PM -0400, Joel Fernandes (Google) wrote:
> > > +
> > > + if (!tg->core_tagged && val) {
> > > + /* Tag is being set. Check ancestors and descendants. */
> > > + if
onix.de
Masahiro, any idea how we can force a full tree rebuild when changing
the unwinder?
--
Josh
define GEN(reg) __EXPORT_THUNK(__x86_indirect_alt_call_ ## reg)
> +#include
> +
> +#undef GEN
> +#define GEN(reg) __EXPORT_THUNK(__x86_indirect_alt_jmp_ ## reg)
> +#include
> +
Git complains about this last newline.
Otherwise everything looks pretty good to me. Let me run it through the
test matrix.
--
Josh
Hi Peter,
On Fri, Mar 26, 2021 at 5:10 PM Peter Zijlstra wrote:
>
> On Wed, Mar 24, 2021 at 05:40:14PM -0400, Joel Fernandes (Google) wrote:
> > From: Josh Don
> >
> > A single unsigned long is insufficient as a cookie value for core
> > scheduling. We wil
> On Wed, Mar 24, 2021 at 01:39:16PM +, Mel Gorman wrote:
> I'm not going to NAK because I do not have hard data that shows they must
> exist. However, I won't ACK either because I bet a lot of tasty beverages
> the next time we meet that the following parameters will generate reports
> if
On Wed, Mar 24, 2021 at 4:27 AM Mel Gorman wrote:
>
> I'm not a fan of the name. I know other sysctls have _enabled in the
> name but it's redundant. If you say the name out loud, it sounds weird.
> I would suggest an alternative but see below.
Now using the version rebased by Peter; this
it is
> kretprobe_trampoline,
> it should be recovered.
> What about this?
I think the REGS and REGS_PARTIAL cases can also be affected by function
graph tracing. So should they use the generic unwind_recover_ret_addr()
instead of unwind_recover_kretprobe()?
--
Josh
On Mon, Mar 22, 2021 at 8:54 PM Li, Aubrey wrote:
>
> On 2021/3/22 20:56, Peter Zijlstra wrote:
> > On Mon, Mar 22, 2021 at 08:31:09PM +0800, Li, Aubrey wrote:
> >> Please let me know if I put cookie match check at the right position
> >> in task_hot(), if so, I'll obtain some performance data of
if the tick is disabled.
This feature is default disabled. It can be toggled on using sysctl
resched_latency_warn_enabled.
Signed-off-by: Paul Turner
Signed-off-by: Josh Don
---
Delta from v1:
- separate sysctl for enabling/disabling and triggering warn_once
behavior
- add documentation
- static
; Mel Gorman
> SUSE Labs
Makes sense, I'll include this in v2.
Thanks,
Josh
> > +static unsigned long sched_core_alloc_task_cookie(void)
> > +{
> > + struct sched_core_task_cookie *ck =
> > + kmalloc(sizeof(struct sched_core_task_cookie), GFP_KERNEL);
>
> struct sched_core_task_cookie *ck = kmalloc(sizeof(*ck), GFP_KERNEL);
>
> Also, those type
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
be fixed length? Objtool can use sym->len as the
alternative replacement length. Then alternatives can add nops as
needed.
--
Josh
eloc == reloc;
> +}
I believe the 2nd condition will always be true, so it can just be
'return reloc->base'.
--
Josh
section().
> + reloc->offset = offset;
> + reloc->type = type;
> + reloc->sym = sym;
> + reloc->addend = addend;
>
> list_add_tail(>list, >reloc_list);
This should be sec->reloc->reloc_list?
--
Josh
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.
> > >
> > >
> + WARN("elf_create_undef_symbol");
> + return -1;
> + }
> + }
> +
> + elf_add_alternative(file->elf, insn, sym,
> + ALT_NOT(X86_FEATURE_RETPOLINE), 5, 5);
> +
> + return 0;
> +}
Need to propagate the error.
--
Josh
p_destinations(file);
> + /*
> + * Must be before add_{jump,call}_destination; for they can add
> + * magic alternatives.
> + */
> + ret = add_special_section_alts(file);
This reordering is unfortunate. Maybe there's a better way, though I
don't have any ideas, at least until I get to the most controversial
patch.
--
Josh
e really dynamic jumps in
>* disguise, so convert them accordingly.
There's another one in add_call_destinations().
--
Josh
-1)
> + return NULL;
> +
> + sym->sym.st_info = 0x10; /* STB_GLOBAL, STT_NOTYPE */
There's a generic macro for this:
sym->sym.st_info = GELF_ST_INFO(STB_GLOBAL, STT_NOTYPE);
And sym->bind and sym->type should probably get set.
--
Josh
or consistency with my other suggestions
(elf_add_reloc() and elf_add_string()). And return an int.
--
Josh
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
The warning is WAI (holding spinlock for 100ms). However, since this
is expected for locktorture, it makes sense to not have the warning
enabled while the test is running. I can add that to the patch.
ory
> is the right approach.
I'm certainly open to any better ideas that would allow GCC plugins to
be enabled in distro kernel builds.
--
Josh
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:
> >
r CONFIG_MODULE_UNLOAD, the code ends up in the normal text area, so
static_call_is_init() is false and kernel_text_address() is true.
For !CONFIG_MODULE_UNLOAD, the code gets discarded during module load,
so static_call_is_init() and kernel_text_address() are both false. I
guess that will trigger a warning?
--
Josh
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
>
gt; elf_create_undef_symbol() also look at gelf_getsymshndx() of symtab ?
>
> What toolchain generates these extended sections and how? That is, how
> do I test this crud..
SHN_XINDEX is basically a special-case extension to original ELF for
supporting more than 64k sections.
--
Josh
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 1:31 AM Ingo Molnar wrote:
>
>
> * Josh Don wrote:
>
> > +static inline u64 resched_latency_check(struct rq *rq)
> > +{
> > + int latency_warn_ms = READ_ONCE(sysctl_resched_latency_warn_ms);
> > + bo
On Wed, Mar 17, 2021 at 1:25 AM Ingo Molnar wrote:
>
> * Josh Don wrote:
>
> > If resched_latency_warn_ms is set to the default value, only one warning
> > will be produced per boot.
>
> Looks like a value hack, should probably be a separate flag,
> defaulti
static calls?
We might consider a STATIC_CALL_SITE_EXIT flag, but I suppose we've run
out of flag space.
--
Josh
, only one warning
will be produced per boot.
This warning only exists under CONFIG_SCHED_DEBUG. If it goes off, it is
likely that there is a missing cond_resched() somewhere.
Signed-off-by: Paul Turner
Signed-off-by: Josh Don
---
We've caught various bugs using this patch. In fact, a followup
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
; +
> + } else if (!strncmp(reloc->sym->name, "__x86_indirect_thunk_",
> 21)) {
> + /*
> + * Retpoline calls are really dynamic calls in
> + * disguise, so convert them accodingly.
s/accodingly/accordingly/
--
Josh
ntroduced to the series.
>
> Daniel, can you also test this again? I and Josh discussed a bit different
> method and I've implemented it on this version.
>
> This actually changes the kretprobe behavisor a bit, now the instraction
> pointer in
> the pt_regs passed to kretprob
1 - 100 of 13971 matches
Mail list logo
