On Wed, 23 Oct 2024 19:27:03 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Hi,
>
> This is an updated version of execmem ROX caches.
>
FYI, I booted a kernel before and after applying these patches with my
change:
https://lore.kernel.org/20241017113105.1edfa...@gandal
On Thu, 17 Oct 2024 14:25:05 +0300
Mike Rapoport wrote:
> With this series the module text is allocated as ROX at the first place, so
> the modifications ftrace does to module text have to either use text poking
> even before complete_formation() or deal with a writable copy like I did
> for relo
On Wed, 16 Oct 2024 17:01:28 -0400
Steven Rostedt wrote:
> If this is only needed for module load, can we at least still use the
> text_poke_early() at boot up?
>
> if (ftrace_poke_late) {
> text_poke_queue((void *)ip, new_code, MCOUNT_INSN_SIZE, NULL);
&g
On Wed, 16 Oct 2024 15:24:22 +0300
Mike Rapoport wrote:
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 8da0e66ca22d..b498897b213c 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -118,10 +118,13 @@ ftrace_modify_code_direct(unsigned long ip
On Mon, 9 Sep 2024 17:34:48 +0300
Mike Rapoport wrote:
> > This is insane, just force BUILDTIME_MCOUNT_SORT
>
> The comment in ftrace.c says "... while mcount loc in modules can not be
> sorted at build time"
>
> I don't know enough about objtool, but I'd presume it's because the sorting
> s
On Mon, 26 Aug 2024 09:55:29 +0300
Mike Rapoport wrote:
> From: Song Liu
>
> ftrace_process_locs sorts module mcount, which is inside RO memory. Add a
> ftrace_swap_func so that archs can use RO-memory-poke function to do the
> sorting.
Can you add the above as a comment above the ftrace_swap_
On Tue, 19 Sep 2023 20:31:50 +0200
Thomas Gleixner wrote:
> The removal of cond_resched() might cause latencies, but then I doubt
> that these museus pieces are used for real work :)
We could simply leave the cond_resched() around but defined as nops for
everything but the "nostalgia club" to ke
On Tue, 19 Sep 2023 15:32:05 +0100
Matthew Wilcox wrote:
> On Tue, Sep 19, 2023 at 04:24:48PM +0200, John Paul Adrian Glaubitz wrote:
> > If the conversion isn't hard, why is the first reflex the urge to remove an
> > architecture
> > instead of offering advise how to get the conversion done?
On Thu, 25 May 2023 22:17:33 -0700
Nadav Amit wrote:
> Ugh. If you cc’d me, I wouldn’t bother you during your vacation. :)
Oh, and if you are interested in tracing patches, just subscribe to
linux-trace-ker...@vger.kernel.org.
-- Steve
___
linux-um m
On Thu, 25 May 2023 22:17:33 -0700
Nadav Amit wrote:
> > FYI, I have a patch queued (still needs to go through testing) that
> > already does this ;-)
> >
> > https://lore.kernel.org/all/20230502164102.1a51c...@gandalf.local.home/
>
> Ugh. If you cc’d me, I wouldn’t bother you during your va
t, this change has been done a decade ago, and according to Steven
> Rostedt, ftrace should have improved and hopefully resolved nested
> tracing issues by now. Arguably, if functions that should be traced -
> for instance since they are used during tracing - still exist, they
> should b
On Tue, 29 Nov 2022 04:25:38 +
Nadav Amit wrote:
> I will need to further debug it, but this issue does not occur every time.
>
> The kernel didn’t crash exactly - it’s more of a deadlock. I have lockdep
> enabled, so it is not a deadlock that lockdep knows. Could it be that
> somehow thing
On Tue, 29 Nov 2022 02:36:22 +
Nadav Amit wrote:
> On Nov 22, 2022, at 12:51 PM, Nadav Amit wrote:
>
> > But more importantly, the current “inline”->”notrace” solution just papers
> > over missing “notrace” annotations. Anyone can remove the “inline” at any
> > given moment since there is n
On Tue, 22 Nov 2022 21:09:08 +0100
"Arnd Bergmann" wrote:
> On Tue, Nov 22, 2022, at 20:53, Nadav Amit wrote:
> > From: Nadav Amit
> >
> > Functions that are marked as "inline" are currently also not tracable.
> > Apparently, this has been done to prevent differences between different
> > config
Nit, the subject should have "tracing:" an not "ftrace:" as the former
encompasses the tracing infrastructure and the latter is for the function
hook part of that.
On Mon, 19 Sep 2022 12:00:12 +0200
Peter Zijlstra wrote:
> CONFIG_GENERIC_ENTRY disallows any and all tracing when RCU isn't
> ena
On Tue, 21 Jun 2022 17:15:47 +0200
Alexander Gordeev wrote:
> So I assume (checked actually) the return 0 below from kernel/sched/core.c:
> wait_task_inactive() is where it bails out:
>
> 3303 while (task_running(rq, p)) {
> 3304 if (match_state &&
> unli
On Tue, 28 Jun 2022 17:42:22 -0500
"Eric W. Biederman" wrote:
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index 156a99283b11..cb85bcf84640 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -202,6 +202,7 @@ static bool ptrace_freeze_traced(struct task_struct *task)
> spin_lo
On Thu, 9 Jun 2022 15:02:20 +0200
Petr Mladek wrote:
> > I'm somewhat curious whether we can actually remove that trace event.
>
> Good question.
>
> Well, I think that it might be useful. It allows to see trace and
> printk messages together.
Yes people still use it. I was just asked about
On Wed, 27 Apr 2022 19:49:17 -0300
"Guilherme G. Piccoli" wrote:
> Currently we don't have a way to check if there are dumpers set,
> except counting the list members maybe. This patch introduces a very
> simple helper to provide this information, by just keeping track of
> registered/unregistere
On Thu, 28 Apr 2022 09:01:13 +0800
Xiaoming Ni wrote:
> > +#ifdef CONFIG_DEBUG_NOTIFIERS
> > + {
> > + char sym_name[KSYM_NAME_LEN];
> > +
> > + pr_info("notifiers: registered %s()\n",
> > + notifier_name(n, sym_name));
> > + }
>
> Duplicate Code.
>
>
On Tue, 10 May 2022 13:38:39 +0200
Petr Mladek wrote:
> As already mentioned in the other reply, panic() sometimes stops
> the other CPUs using NMI, for example, see kdump_nmi_shootdown_cpus().
>
> Another situation is when the CPU using the lock ends in some
> infinite loop because something we
On Fri, 29 Apr 2022 10:46:35 -0300
"Guilherme G. Piccoli" wrote:
> Thanks Sergei and Steven, good idea! I thought about the switch change
> you propose, but I confess I got a bit confused by the "fallthrough"
> keyword - do I need to use it?
No. The fallthrough keyword is only needed when there'
Why not:
>
> case DIE_OOPS:
> case PANIC_NOTIFIER:
> do_dump = 1;
> break;
Agreed.
Other than that.
Acked-by: Steven Rostedt (Google)
-- Steve
___
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
23 matches
Mail list logo
