On Mon, 7 Sep 2020 13:41:40 +0200
pet...@infradead.org wrote:
> > I may have once known the rationale behind all this, but it's been a
> > long time since I worked on the PI code, and it's out of my cache.
Now I'm trying to cache all this in from a long PTO ;-)
>
> I suffer much the same prob
Adding the kexec list as well.
Joerg Vehlow writes:
> 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 revie
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
Joerg Vehlow writes:
> 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 c
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 only
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 for
On 07/09/20 12:41, pet...@infradead.org wrote:
> So cenceptually there's the problem that idle must always be runnable,
> and the moment you boost it, it becomes subject to a different
> scheduling class.
>
> Imagine for example what happens when we boost it to RT and then have it
> be subject to
On Mon, Sep 07, 2020 at 02:03:09PM +0200, Joerg Vehlow wrote:
>
>
> 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-
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 b
On Mon, Sep 07, 2020 at 12:51:37PM +0200, Joerg Vehlow wrote:
> 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 u
On Sat, Aug 22, 2020 at 07:49:28PM -0400, Steven Rostedt wrote:
> From this email:
>
> > The problem happens when that owner is the idle task, this can happen
> > when the irq/softirq hits the idle task, in that case the contending
> > mutex_lock() will try and PI boost the idle task, and that is
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,
bec
On Sat, 22 Aug 2020 14:32:52 +0200
pet...@infradead.org wrote:
> On Fri, Aug 21, 2020 at 05:03:34PM -0400, Steven Rostedt wrote:
>
> > > Sigh. Is it too hard to make mutex_trylock() usable from interrupt
> > > context?
> >
> >
> > That's a question for Thomas and Peter Z.
>
> You should r
On Fri, Aug 21, 2020 at 05:03:34PM -0400, Steven Rostedt wrote:
> > Sigh. Is it too hard to make mutex_trylock() usable from interrupt
> > context?
>
>
> That's a question for Thomas and Peter Z.
You should really know that too, the TL;DR answer is it's fundamentally
buggered, can't work.
The
On Fri, 21 Aug 2020 13:47:53 -0700
Andrew Morton wrote:
> On Fri, 21 Aug 2020 11:08:48 -0400 Steven Rostedt wrote:
>
> > On Fri, 21 Aug 2020 12:25:33 +0200
> > Joerg Vehlow wrote:
> >
> > > Hi Andrew and Others (please read at least the part with @RT developers),
> > >
> > > > Yup, mutex
On Fri, 21 Aug 2020 11:08:48 -0400 Steven Rostedt wrote:
> On Fri, 21 Aug 2020 12:25:33 +0200
> Joerg Vehlow wrote:
>
> > 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.
On Fri, 21 Aug 2020 12:25:33 +0200
Joerg Vehlow wrote:
> 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.
> >
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
approac
On Wed, 22 Jul 2020 06:30:53 +0200 Joerg Vehlow wrote:
> >> About 12 years ago this was not implemented using a mutex, but using xchg.
> >> See: 8c5a1cf0ad3ac5fcdf51314a63b16a440870f6a2
> > Yes, that commit is wrong, because mutex_trylock() is not to be taken in
> > interrupt context, where crash
On Wed, 22 Jul 2020 06:30:53 +0200
Joerg Vehlow wrote:
> Hi Andrew,
>
> it's been two month now and no reaction from you. Maybe you did not see
> this mail from Steven.
> Please look at this issue.
>
Perhaps you need to send the report again without the RT (just [BUG])
to get Andrew's attenti
Hi Andrew,
it's been two month now and no reaction from you. Maybe you did not see
this mail from Steven.
Please look at this issue.
Greets,
Jörg
On 5/28/2020 2:46 PM, Steven Rostedt wrote:
Hi Joerg,
This does look like Andrew's commit (from 2008) is buggy (and this is a
mainline bug, not
Hi Joerg,
This does look like Andrew's commit (from 2008) is buggy (and this is a
mainline bug, 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
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 re
23 matches
Mail list logo
