Hi Eric,
What is this patch supposed to be doing?
What bug is it fixing?
This information is part in the first message of this mail thread.
The patch was intendedfor the active discussion in this thread,
not for a broad review.
A short summary: In the rt kernel, a panic in an interrupt context
Hi,
here is the new version of the patch based on Peters suggestion
It looks like it works fine. I added the BUG_ON to __crash_kexec,
because it is a precondition, that panic_cpu is set correctly, otherwise
the whole locking logic fails.
The mutex_trylock can still be used, because it is
Hi Peter
On 9/7/2020 6:23 PM, pet...@infradead.org wrote:
According to the original comment in __crash_kexec, the mutex was used to
prevent a sys_kexec_load, while crash_kexec is executed. Your proposed patch
does not lock the mutex in crash_kexec.
Sure, but any mutex taker will (spin) wait
On 9/7/2020 1:46 PM, pet...@infradead.org wrote:
I think it's too complicated for that is needed, did you see my
suggestion from a year ago? Did i miss something obvious?
This one?
https://lore.kernel.org/linux-fsdevel/20191219090535.gv2...@hirez.programming.kicks-ass.net/
I think it may
Hi,
I guess there is currently no other way than to use something like Steven
proposed. I implemented and tested the attached patch with a module,
that triggers the soft lockup detection and it works as expected.
I did not use inline functions, but normal function implemented in
kexec_core,
Hi Andrew and Others (please read at least the part with @RT developers),
Yup, mutex_trylock() from interrupt is improper. Well dang, that's a
bit silly. Presumably the 2006 spin_lock_mutex() wasn't taken with
irqs-off.
Ho hum, did you look at switching the kexec code back to the xchg
, not an RT one). (top posting this so Andrew knows to look
further ;-)
On Thu, 28 May 2020 13:41:08 +0200
Joerg Vehlow wrote:
Hi,
I think I found a bug in the kernel with rt patches (or maybe even without).
This applies to all kernels propably starting at 2.6.27.
When a kernel panic is triggered
Hi,
I think I found a bug in the kernel with rt patches (or maybe even without).
This applies to all kernels propably starting at 2.6.27.
When a kernel panic is triggered from an interrupt handler, the dump-capture
kernel is not started, instead the system acts as if it was not installed.
The
Hi,
I already send a patch on 2019-09-09 to this mailing list with a similar
issue[1].
Sadly no replies, although this is a huge bug in the rt kernel.
I fixed it a bit differently, using smaller locked regions.
You have also propably a bug in your patch, because trans->queue.lock is
no
Hi,
is no one interested in this?
Hi,
I was looking thoroughly at the realtime testcase sched_football,
because it sometimes fails and like to know your opinion on the test case.
A short introduction to how the test works:
It creates nThreads threads called offense and n threads called
From: Joerg Vehlow
During the skb_queue_splice_init the tasklet could have been preempted
and __skb_queue_tail called, which led to an inconsistent queue.
Signed-off-by: Joerg Vehlow
---
net/xfrm/xfrm_input.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/xfrm
I just happen to be analyzing an error in the kernel if ipcomp is used with rt
patches. The reason was the meissing lock around the scratch buffer for the
compress call. Now that I have applied Juris fix, I get another error:
[ 139.717259] BUG: unable to handle kernel NULL pointer dereference
12 matches
Mail list logo
