Refactor ftrace code and move to using ftrace_replace_code() to help
simplify and make the code more maintainable.
- The existing ftrace.c code is moved to a separate file so that ppc64
elfv1 and clang -pg only support continue. This makes it possible to
converge ppc32 and ppc64 support furthe
Fix build warnings when DEBUG_FS is not enabled by using an empty
do-while loop instead of a value:
In file included from ../drivers/crypto/nx/nx.c:27:
../drivers/crypto/nx/nx.c: In function 'nx_register_algs':
../drivers/crypto/nx/nx.h:173:33: warning: statement with no effect
[-Wunused-value]
On Fri, 19 May 2023 14:48:59 PDT (-0700), sch...@linux-m68k.org wrote:
On Mai 19 2023, Alexandre Ghiti wrote:
I have tested the following patch successfully, can you give it a try
while I make sure this is the only place I forgot to add the -fno-pie
flag?
diff --git a/arch/riscv/kernel/Makefil
On Mai 19 2023, Alexandre Ghiti wrote:
> I have tested the following patch successfully, can you give it a try
> while I make sure this is the only place I forgot to add the -fno-pie
> flag?
>
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index fbdccc21418a..153864e4f399
https://bugzilla.kernel.org/show_bug.cgi?id=216715
--- Comment #6 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Would be nice to give it a new try with KCSAN enabled.
To get KCSAN on powerpc/32, apply following series:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=35473
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #36 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Would be nice to give it a new try with KCSAN enabled.
To get KCSAN on powerpc/32, apply following series:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=3547
Hi,
On Mon, May 8, 2023 at 8:52 AM Doug Anderson wrote:
>
> Hmmm, but I don't think you really need "all-to-all" checking to get
> the stacktraces you want, do you? Each CPU can be "watching" exactly
> one other CPU, but then when we actually lock up we could check all of
> them and dump stacks o
Hi,
On Thu, May 11, 2023 at 8:46 AM Petr Mladek wrote:
>
> > @@ -111,6 +125,11 @@ static void watchdog_hardlockup_interrupt_count(void)
> >
> > void watchdog_hardlockup_check(unsigned int cpu, struct pt_regs *regs)
> > {
> > + if (__this_cpu_read(watchdog_hardlockup_touch)) {
> > +
Hi,
On Thu, May 11, 2023 at 7:14 AM Petr Mladek wrote:
>
> On Thu 2023-05-04 15:13:41, Douglas Anderson wrote:
> > In preparation for the buddy hardlockup detector where the CPU
> > checking for lockup might not be the currently running CPU, add a
> > "cpu" parameter to watchdog_hardlockup_check(
From: Lecopzer Chen
Set safe maximum CPU frequency to 5 GHz in case a particular platform
doesn't implement cpufreq driver.
Although, architecture doesn't put any restrictions on
maximum frequency but 5 GHz seems to be safe maximum given the available
Arm CPUs in the market which are clocked much
From: Lecopzer Chen
When lockup_detector_init()->watchdog_hardlockup_probe(), PMU may be
not ready yet. E.g. on arm64, PMU is not ready until
device_initcall(armv8_pmu_driver_init). And it is deeply integrated
with the driver model and cpuhp. Hence it is hard to push this
initialization before s
On arm64, NMI support needs to be detected at runtime. Add a weak
function to the perf hardlockup detector so that an architecture can
implement it to detect whether NMIs are available.
Signed-off-by: Douglas Anderson
---
While I won't object to this patch landing, I consider it part of the
arm64
Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using
something arch-specific we will use the buddy system, where each CPU
watches out for another one. Specifically, each CPU will use its
softlockup hrtimer to check that t
The fact that there watchdog_hardlockup_enable(),
watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are
declared __weak means that the configured hardlockup detector can
define non-weak versions of those functions if it needs to. Instead of
doing this, the perf hardlockup detector hook
Do a search and replace of:
- NMI_WATCHDOG_ENABLED => WATCHDOG_HARDLOCKUP_ENABLED
- SOFT_WATCHDOG_ENABLED => WATCHDOG_SOFTOCKUP_ENABLED
- watchdog_nmi_ => watchdog_hardlockup_
- nmi_watchdog_available => watchdog_hardlockup_available
- nmi_watchdog_user_enabled => watchdog_hardlockup_user_enabled
-
In preparation for the buddy hardlockup detector, which wants the same
petting logic as the current perf hardlockup detector, move the code
to watchdog.c. While doing this, rename the global variable to match
others nearby. As part of this change we have to change the code to
account for the fact t
In preparation for the buddy hardlockup detector where the CPU
checking for lockup might not be the currently running CPU, add a
"cpu" parameter to watchdog_hardlockup_check().
As part of this change, make hrtimer_interrupts an atomic_t since now
the CPU incrementing the value and the CPU reading
These are tiny style changes:
- Add a blank line before a "return".
- Renames two globals to use the "watchdog_hardlockup" prefix.
- Store processor id in "unsigned int" rather than "int".
- Minor comment rewording.
- Use "else" rather than extra returns since it seemed more symmetric.
Reviewed-by
The perf hardlockup detector works by looking at interrupt counts and
seeing if they change from run to run. The interrupt counts are
managed by the common watchdog code via its watchdog_timer_fn().
Currently the API between the perf detector and the common code is a
function: is_hardlockup(). Whe
The code currently in "watchdog_hld.c" is for detecting hardlockups
using perf, as evidenced by the line in the Makefile that only
compiles this file if CONFIG_HARDLOCKUP_DETECTOR_PERF is
defined. Rename the file to prepare for the buddy hardlockup detector,
which doesn't use perf.
It could be arg
In preparation for the buddy hardlockup detector, add comments to
touch_nmi_watchdog() to make it obvious that it touches the configured
hardlockup detector regardless of whether it's backed by an NMI. Also
note that arch_touch_nmi_watchdog() may not be architecture-specific.
Ideally, we'd like to
From: Pingfan Liu
hardlockup_detector_event_create() should create perf_event on the
current CPU. Preemption could not get disabled because
perf_event_create_kernel_counter() allocates memory. Instead,
the CPU locality is achieved by processing the code in a per-CPU
bound kthread.
Add a check to
From: Lecopzer Chen
Nobody cares about the return value of watchdog_nmi_enable(),
changing its prototype to void.
Signed-off-by: Pingfan Liu
Signed-off-by: Lecopzer Chen
Reviewed-by: Petr Mladek
Acked-by: Nicholas Piggin
Signed-off-by: Douglas Anderson
---
I yanked this patch from the maili
From: Lecopzer Chen
No reference to WATCHDOG_DEFAULT, remove it.
Signed-off-by: Pingfan Liu
Signed-off-by: Lecopzer Chen
Reviewed-by: Petr Mladek
Signed-off-by: Douglas Anderson
---
I yanked this patch from the mailing lists [1] into my series just to
make it easier to avoid conflicts betwee
Currently, in the watchdog_overflow_callback() we first check to see
if the watchdog had been touched and _then_ we handle the workaround
for turbo mode. This order should be reversed.
Specifically, "touching" the hardlockup detector's watchdog should
avoid lockups being detected for one period th
This patch series adds the "buddy" hardlockup detector. In brief, the
buddy hardlockup detector can detect hardlockups without arch-level
support by having CPUs checkup on a "buddy" CPU periodically. All the
details are in the patch ("watchdog/hardlockup: detect hard lockups
using secondary (buddy)
The real watchdog_update_hrtimer_threshold() is defined in
kernel/watchdog_hld.c. That file is included if
CONFIG_HARDLOCKUP_DETECTOR_PERF and the function is defined in that
file if CONFIG_HARDLOCKUP_CHECK_TIMESTAMP.
The dummy version of the function in "nmi.h" didn't get that quite
right. While
If profile-guided optimization is enabled, the purgatory ends up with
multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Acked-by: Palmer Dabbelt
Signed-off-by: Rica
If profile-guided optimization is enabled, the purgatory ends up with
multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Signed-off-by: Ricardo Ribalda
---
arch/pow
If profile-guided optimization is enabled, the purgatory ends up with
multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Signed-off-by: Ricardo Ribalda
---
arch/x86
Clang16 links the purgatory text in two sections when PGO is in use:
[ 1] .text PROGBITS 0040
11a1 AX 0 0 16
[ 2] .rela.textRELA 3498
0648
When upreving llvm I realised that kexec stopped working on my test
platform.
The reason seems to be that due to PGO there are multiple .text sections
on the purgatory, and kexec does not supports that.
Signed-off-by: Ricardo Ribalda
---
Changes in v7:
- Fix $SUBJECT of riscv patch
- Rename PGO
Commit 1e8fed873e74 ("powerpc: drop ranges for definition of
ARCH_FORCE_MAX_ORDER") removed the limits on the possible values for
ARCH_FORCE_MAX_ORDER.
However removing the ranges entirely causes some common work flows to
break. For example building a defconfig (which uses 64K pages), changing
the
On 5/11/23 20:18, Andreas Schwab wrote:
On Mai 09 2023, Alexandre Ghiti wrote:
On 5/9/23 21:07, Andreas Schwab wrote:
That does not work with UEFI booting:
Loading Linux 6.4.0-rc1-1.g668187d-default ...
Loading initial ramdisk ...
Unhandled exception: Instruction access fault
EPC: 800
34 matches
Mail list logo
