On Fri, 6 Jun 2014 07:40:10 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 5 Jun 2014, Steven Rostedt wrote:
> > On Wed, 4 Jun 2014 17:32:37 +0200 (CEST)
> > Thomas Gleixner wrote:
> > + /*
> > +* When we dropped the spinlocks, if the owner of the lock we
> > +* are currently processing
On Fri, 6 Jun 2014, Thomas Gleixner wrote:
> On Thu, 5 Jun 2014, Steven Rostedt wrote:
> > On Wed, 4 Jun 2014 17:32:37 +0200 (CEST)
> > Thomas Gleixner wrote:
> > + /*
> > +* When we dropped the spinlocks, if the owner of the lock we
> > +* are currently processing changed since we chain
On Thu, 5 Jun 2014, Steven Rostedt wrote:
> On Wed, 4 Jun 2014 17:32:37 +0200 (CEST)
> Thomas Gleixner wrote:
> + /*
> + * When we dropped the spinlocks, if the owner of the lock we
> + * are currently processing changed since we chain walked
> + * to that lock, we are done with
On Wed, 4 Jun 2014 17:32:37 +0200 (CEST)
Thomas Gleixner wrote:
> On Tue, 3 Jun 2014, Steven Rostedt wrote:
> > On Fri, 23 May 2014 09:30:10 -0500
> > "Brad Mouring" wrote:
> > > /* Deadlock detection */
> > > if (lock == orig_lock || rt_mutex_owner(lock) == top_task) {
> > > + /*
>
On Wed, 4 Jun 2014, Steven Rostedt wrote:
> On Wed, 4 Jun 2014 20:02:16 +0200 (CEST)
> Thomas Gleixner wrote:
>
>
> > My brain still suffers from 3 days staring into futex.c
>
> Hopefully that's not permanent damage.
Staring into rtmutex.c does not make it any better ...
--
To unsubscribe fr
On Wed, 4 Jun 2014, Brad Mouring wrote:
> On Wed, Jun 04, 2014 at 09:53:16PM +0200, Thomas Gleixner wrote:
> > Your change wreckages the rt_mutex_owner(lock) == top_task test
> > simply because in that case:
> >
> >(rt_mutex_owner(lock) && rt_mutex_owner(lock) != task)
> >
> > evaluates to tr
On Wed, Jun 04, 2014 at 09:53:16PM +0200, Thomas Gleixner wrote:
> On Wed, 4 Jun 2014, Brad Mouring wrote:
> > On Wed, Jun 04, 2014 at 08:02:16PM +0200, Thomas Gleixner wrote:
> > > I'll fixup the check so it wont break the real deadlock case and queue
> > > it.
> >
> > How would the change break
On Wed, 4 Jun 2014, Brad Mouring wrote:
> On Wed, Jun 04, 2014 at 08:02:16PM +0200, Thomas Gleixner wrote:
> > I'll fixup the check so it wont break the real deadlock case and queue
> > it.
>
> How would the change break the real deadlock case?
> > /* Deadlock detection */
> > if (lock ==
On Wed, Jun 04, 2014 at 08:02:16PM +0200, Thomas Gleixner wrote:
> On Wed, 4 Jun 2014, Steven Rostedt wrote:
>
> > On Wed, 4 Jun 2014 17:32:37 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> > > T3 releases L3
> > > T2 gets L3
> > > T2 drops L3 and L2
> > > T2 blocks on L4 held by T4
> > > T4 bloc
On Wed, 4 Jun 2014 20:02:16 +0200 (CEST)
Thomas Gleixner wrote:
> My brain still suffers from 3 days staring into futex.c
Hopefully that's not permanent damage.
>
> I'll fixup the check so it wont break the real deadlock case and queue
> it.
>
Cool. Could you include my write up on the loc
On Wed, 4 Jun 2014, Steven Rostedt wrote:
> On Wed, 4 Jun 2014 17:32:37 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > T3 releases L3
> > T2 gets L3
> > T2 drops L3 and L2
> > T2 blocks on L4 held by T4
> > T4 blocked on L5 held by T5
> >
> > So we happily boost T4 and T5. Not what we really want
On Wed, 4 Jun 2014 17:32:37 +0200 (CEST)
Thomas Gleixner wrote:
> T3 releases L3
> T2 gets L3
> T2 drops L3 and L2
> T2 blocks on L4 held by T4
> T4 blocked on L5 held by T5
>
> So we happily boost T4 and T5. Not what we really want to do.
>
> Nasty, isn't it ?
>
Actually, we may go up a chai
On Tue, 3 Jun 2014, Steven Rostedt wrote:
> On Fri, 23 May 2014 09:30:10 -0500
> "Brad Mouring" wrote:
> > /* Deadlock detection */
> > if (lock == orig_lock || rt_mutex_owner(lock) == top_task) {
> > + /*
> > +* If the prio chain has changed out from under us, set th
On Wed, Jun 04, 2014 at 10:58:23AM -0400, Steven Rostedt wrote:
> On Wed, 4 Jun 2014 09:38:30 -0500
> "Brad Mouring" wrote:
>
> > On Wed, Jun 04, 2014 at 10:16:12AM -0400, Steven Rostedt wrote:
> > > On Wed, 4 Jun 2014 08:05:25 -0500
> > > "Brad Mouring" wrote:
> > >
> > > > A->L2
> >
On Wed, 4 Jun 2014 09:38:30 -0500
"Brad Mouring" wrote:
> On Wed, Jun 04, 2014 at 10:16:12AM -0400, Steven Rostedt wrote:
> > On Wed, 4 Jun 2014 08:05:25 -0500
> > "Brad Mouring" wrote:
> >
> > > A->L2
> > >
> > > This is a slight variation on what I was seeing. To use the nomenclatu
On Wed, Jun 04, 2014 at 10:16:12AM -0400, Steven Rostedt wrote:
> On Wed, 4 Jun 2014 08:05:25 -0500
> "Brad Mouring" wrote:
>
> > A->L2
> >
> > This is a slight variation on what I was seeing. To use the nomenclature
> > that you proposed at the start, rewinding to the point
> >
> >
On Wed, 4 Jun 2014 08:05:25 -0500
"Brad Mouring" wrote:
> A->L2
>
> This is a slight variation on what I was seeing. To use the nomenclature
> that you proposed at the start, rewinding to the point
>
>A->L2->B->L3->C->L4->D
>
> Let's assume things continue to unfold as you explai
On Tue, Jun 03, 2014 at 09:06:09PM -0400, Steven Rostedt wrote:
> Added LKML and Thomas et. al., as this looks to be mainline too, and
> we've been having so much fun with futexes lately.
>
> What I've thought about is this scenario. In
> rt_mutex_adjust_prio_chain(), at the bottom of the loop, ju
Added LKML and Thomas et. al., as this looks to be mainline too, and
we've been having so much fun with futexes lately.
What I've thought about is this scenario. In
rt_mutex_adjust_prio_chain(), at the bottom of the loop, just before
goto again is called, all locks are released, and we are fully
p
19 matches
Mail list logo
