n time
> memory bloat by ~64 bytes per sentinel (further information Link :
> https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
>
> rm sentinel element from ctl_table arrays
>
> Acked-by: "Peter Zijlstra (Intel)"
Tested-by: Valentin Schneider
Review
; serialization of crash hotplug handling.
>
> Here, add a new mutex lock __crash_hotplug_lock to serialize crash
> hotplug handling specifically. This doesn't impact the usage of
> __kexec_lock.
>
> Signed-off-by: Baoquan He
Reviewed-by: Valentin Schneider
_
On 21/09/23 17:59, Eric DeVolder wrote:
> The design decision to use the atomic lock is described in the comment
> from kexec_internal.h, cited above. However, examining the code of
> __crash_kexec():
>
> if (kexec_trylock()) {
> if (kexec_crash_image) {
>
Hi,
On 13/07/22 10:39, Andrew Morton wrote:
> On Tue, 12 Jul 2022 12:13:03 +0100 Valentin Schneider
> wrote:
>
>> On 12/07/22 10:47, Baoquan He wrote:
>> > Hi,
>> >
>> > This series looks good, has it been taken into any tree?
>> >
>>
On 12/07/22 10:47, Baoquan He wrote:
> Hi,
>
> On 06/30/22 at 11:32pm, Valentin Schneider wrote:
>> Hi folks,
>>
>> Here's ~v3~ v4 where we now completely get rid of kexec_mutex.
>>
>> o Patch 1 makes sure all kexec_mutex acquisitions are trylocks
does halve the printable size of the crash kernel, but that's still
neighbouring 2G for 32bit kernels which should be ample enough.
Signed-off-by: Valentin Schneider
---
include/linux/kexec.h | 2 +-
kernel/kexec_core.c | 12
kernel/ksysfs.c | 7 ++-
3 files
for kexec (Eric)
v1 -> v2
o Changed from Peterson-like synchronization to simpler atomic_cmpxchg
(Petr)
o Slightly reworded changelog
o Added Fixes: tag. Technically should be up to since kexec can happen
in an NMI, but that isn't such a clear target
Cheers,
Valentin
Vale
rises.
Tested by triggering NMI panics via:
$ echo 1 > /proc/sys/kernel/panic_on_unrecovered_nmi
$ echo 1 > /proc/sys/kernel/unknown_nmi_panic
$ echo 1 > /proc/sys/kernel/panic
$ ipmitool power diag
Fixes: 6ce47fd961fa ("rtmutex: Warn if trylock is called from hard/
does halve the printable size of the crash kernel, but that's still
neighbouring 2G for 32bit kernels which should be ample enough.
Signed-off-by: Valentin Schneider
---
include/linux/kexec.h | 2 +-
kernel/kexec_core.c | 12
kernel/ksysfs.c | 7 ++-
3 files
rises.
Tested by triggering NMI panics via:
$ echo 1 > /proc/sys/kernel/panic_on_unrecovered_nmi
$ echo 1 > /proc/sys/kernel/unknown_nmi_panic
$ echo 1 > /proc/sys/kernel/panic
$ ipmitool power diag
Fixes: 6ce47fd961fa ("rtmutex: Warn if trylock is called from hard/
ke synchronization to simpler atomic_cmpxchg
(Petr)
o Slightly reworded changelog
o Added Fixes: tag. Technically should be up to since kexec can happen
in an NMI, but that isn't such a clear target
Cheers,
Valentin
Valentin Schneider (2):
kexec: Turn all kexec_mutex acquisitions
On 29/06/22 13:55, Petr Mladek wrote:
> On Tue 2022-06-28 18:33:08, Valentin Schneider wrote:
>>
>> 8c5a1cf0ad3a ("kexec: use a mutex for locking rather than xchg()") was
>> straightforward enough because it turned
>>
>> if (xchg(&lock, 1
On 27/06/22 13:42, Valentin Schneider wrote:
> On 25/06/22 12:04, Eric W. Biederman wrote:
>> At this point I recommend going back to being ``unconventional'' with
>> the kexec locking and effectively reverting commit 8c5a1cf0ad3a ("kexec:
>> use
On 25/06/22 12:04, Eric W. Biederman wrote:
> I am not particularly fond of this patch as it adds more complexity than
> is necessary to solve the problem.
>
> Calling a spade a spade PREEMPT_RT's mutex_trylock implementation is
> broken as it can not support the use cases of an ordinary mutex_tryl
On 24/06/22 09:30, Baoquan He wrote:
> On 06/20/22 at 12:15pm, Valentin Schneider wrote:
>> @@ -94,14 +94,20 @@ static int do_kexec_load(unsigned long entry, unsigned
>> long nr_segments,
>> /*
>> * Because we write directly to the reserved memory region wh
On 23/06/22 11:31, Sebastian Andrzej Siewior wrote:
> On 2022-06-20 12:15:20 [+0100], Valentin Schneider wrote:
>> Attempting to get a crash dump out of a debug PREEMPT_RT kernel via an NMI
>> panic() doesn't work. The cause of that lies in the PREEMPT_RT definition
r diag
Fixes: 6ce47fd961fa ("rtmutex: Warn if trylock is called from hard/softirq
context")
Signed-off-by: Valentin Schneider
---
v1 -> v2
o Changed from Peterson-like synchronization to simpler atomic_cmpxchg
(Petr)
o Slightly reworded changelog
o Added Fixes: tag. Techn
On 17/06/22 17:13, Sebastian Andrzej Siewior wrote:
> On 2022-06-16 13:37:09 [+0100], Valentin Schneider wrote:
>> Regarding the original explanation for the WARN & return:
>>
>> I don't get why 2) is a problem - if the lock is acquired by the trylock
>> t
On 17/06/22 15:52, Petr Mladek wrote:
> On Fri 2022-06-17 12:52:05, Valentin Schneider wrote:
>> If you look at __crash_kexec() in isolation yes, but if you look at panic()
>> and nmi_panic() only a single NMI can get in there. I think that is also
>> true for invocations via
Hi Tao,
On 17/06/22 18:42, Tao Zhou wrote:
> Hi Valentin,
>
> On Thu, Jun 16, 2022 at 01:37:09PM +0100, Valentin Schneider wrote:
>> @@ -964,24 +966,31 @@ late_initcall(kexec_core_sysctl_init);
>> */
>> void __noclone __crash_kexec(struct pt_regs *regs)
>>
loading vs executing a
crash kernel.
Tested by triggering NMI panics via:
$ echo 1 > /proc/sys/kernel/panic_on_unrecovered_nmi
$ echo 1 > /proc/sys/kernel/unknown_nmi_panic
$ echo 1 > /proc/sys/kernel/panic
$ ipmitool power diag
Signed-off-by: Valentin Schneider
---
Regarding
On 26/01/22 10:45, Pingfan Liu wrote:
> On Wed, Jan 26, 2022 at 12:29 AM Valentin Schneider
> wrote:
>>
>> On 25/01/22 11:39, Pingfan Liu wrote:
>> > The following identical code piece appears in both
>> > migrate_to_reboot_cpu() and smp_shutdown_nonboot_cpu
upposed to be a refactor with no change in behaviour? AFAICT it
actually does change things (and isn't necessarily clearer).
> Signed-off-by: Pingfan Liu
> Cc: Eric Biederman
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Valentin Schneider
> Cc: Vincent Donnefort
23 matches
Mail list logo
