linux-kernel - Re: [GIT PULL] Scheduler updates for v6.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250803152411.7fd91614@gandalf.local.home>
Date: Sun, 3 Aug 2025 15:24:11 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org, Peter
 Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, Juri
 Lelli <juri.lelli@...hat.com>, Vincent Guittot
 <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
 Mel Gorman <mgorman@...e.de>, Tejun Heo <tj@...nel.org>, Valentin Schneider
 <vschneid@...hat.com>, Shrikanth Hegde <sshegde@...ux.ibm.com>
Subject: Re: [GIT PULL] Scheduler updates for v6.17

On Sun, 3 Aug 2025 12:10:56 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Sat, 2 Aug 2025 at 12:46, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > You could try to enable function tracer and stop the trace with the patch
> > below and see where it happened.
> >
> >  # echo function > /sys/kernel/tracing/current_tracer
> >  # echo 1 > /sys/kernel/tracing/tracing_on
> >
> > After it happens you can take a look at:
> >
> >   # cat /sys/kernel/tracing/trace  
> 
> Note that when this happens, the machine is dead.
> 
> It seems to be alive enough to get this logged, but it's dead from a
> functional standpoint. There's no "when it happens, do this".

Can you trigger a forced soft reboot? 

 echo 1 > /proc/sys/kernel/panic_on_warn

With the kernel command line "panic=1".

If your machine doesn't clear the memory on reboot, you could use the
persistent ring buffer too:

Adding to the kernel command line:

  reserve_mem=20M:12M:trace trace_instance=boot_mapped@...ce

Then use:

  # echo function > /sys/kernel/tracing/instances/boot_mapped/current_tracer
  # echo 1 > /sys/kernel/tracing/instances/boot_mapped/tracing_on

After a crash, if the memory is persistent it should have everything up to
the crash:

   # cat /sys/kernel/tracing/instances/boot_mapped/trace  


This is the exact scenario that this was created for.

-- Steve