On Wed, 14 May 2014, Darren Hart wrote:
> On May 13, 2014 11:54 PM, "Thomas Gleixner" wrote:
>
> I'll gladly accept new functional/algorithm type tests to futextest
> (performance stuff is probably going to perf instead, and Dave Miller beat
Dave Jones :)
> me to the fuzz tester with Trinity).
On Tue, 13 May 2014, Lai Jiangshan wrote:
> Hi, Thomas,
>
> I think this patch is just a workaround, it is not the proper fix.
> you need a updated deadlock-check mechanism:
>
> - (old) skip the check when top_waiter != task_top_pi_waiter(task)
> + (new) skip the check when top_waiter->prio > ta
On Tue, 13 May 2014, Steven Rostedt wrote:
> On Tue, 13 May 2014 16:27:11 -0700
> "Paul E. McKenney" wrote:
>
> > On Tue, May 13, 2014 at 06:44:30PM -0400, Steven Rostedt wrote:
> > > On Tue, 13 May 2014 15:00:09 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > >
> > > > Good points -- I was
On Tue, 13 May 2014, Steven Rostedt wrote:
> On Tue, 13 May 2014 15:00:09 -0700
> "Paul E. McKenney" wrote:
>
>
> > Good points -- I was indeed thinking about stress testing instead of
> > algorithmic testing.
>
> But doesn't lockdep use algorithmic tests too?
Kinda, but only for the deadloc
On Tue, May 13, 2014 at 07:53:36PM -0400, Steven Rostedt wrote:
> On Tue, 13 May 2014 16:27:11 -0700
> "Paul E. McKenney" wrote:
>
> > On Tue, May 13, 2014 at 06:44:30PM -0400, Steven Rostedt wrote:
> > > On Tue, 13 May 2014 15:00:09 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > >
> > > > Go
On Tue, 13 May 2014 16:27:11 -0700
"Paul E. McKenney" wrote:
> On Tue, May 13, 2014 at 06:44:30PM -0400, Steven Rostedt wrote:
> > On Tue, 13 May 2014 15:00:09 -0700
> > "Paul E. McKenney" wrote:
> >
> >
> > > Good points -- I was indeed thinking about stress testing instead of
> > > algorithm
On Tue, May 13, 2014 at 06:44:30PM -0400, Steven Rostedt wrote:
> On Tue, 13 May 2014 15:00:09 -0700
> "Paul E. McKenney" wrote:
>
>
> > Good points -- I was indeed thinking about stress testing instead of
> > algorithmic testing.
>
> But doesn't lockdep use algorithmic tests too?
I suppose yo
On Tue, 13 May 2014 15:00:09 -0700
"Paul E. McKenney" wrote:
> Good points -- I was indeed thinking about stress testing instead of
> algorithmic testing.
But doesn't lockdep use algorithmic tests too?
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Tue, May 13, 2014 at 11:27:16PM +0200, Thomas Gleixner wrote:
> On Tue, 13 May 2014, Paul E. McKenney wrote:
> > On Tue, May 13, 2014 at 04:20:41PM -0400, Steven Rostedt wrote:
> > > What about having a module that creates a bunch of threads and forces
> > > all the scenarios that we want to tes
On Tue, 13 May 2014, Paul E. McKenney wrote:
> On Tue, May 13, 2014 at 04:20:41PM -0400, Steven Rostedt wrote:
> > What about having a module that creates a bunch of threads and forces
> > all the scenarios that we want to test? Wouldn't it be easier to do
> > than to have a userspace interface to
On Tue, May 13, 2014 at 04:20:41PM -0400, Steven Rostedt wrote:
> On Tue, 13 May 2014 21:42:54 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > On Tue, 13 May 2014, Peter Zijlstra wrote:
> > >
> > > Now, if you and Steve get this sorted, nothing really happened except
> > > that Thomas got grumpy, wh
On Tue, 13 May 2014 21:42:54 +0200 (CEST)
Thomas Gleixner wrote:
> On Tue, 13 May 2014, Peter Zijlstra wrote:
> >
> > Now, if you and Steve get this sorted, nothing really happened except
> > that Thomas got grumpy, which is entirely normal, what else would he be?
> > :-)
>
> Who is that grumpy
On Tue, 13 May 2014, Peter Zijlstra wrote:
>
> Now, if you and Steve get this sorted, nothing really happened except
> that Thomas got grumpy, which is entirely normal, what else would he be?
> :-)
Who is that grumpy Thomas dude, should I know him?
Lai, Steven,
before you waste lots of time on
On Tue, May 13, 2014 at 10:48:15AM +0200, Peter Zijlstra wrote:
> On Tue, May 13, 2014 at 01:51:21PM +0800, Lai Jiangshan wrote:
> > I considered you blamed to me.
> > I would feel better if you directly blamed to me.
>
> Well, the way I see it all you're to blame for is 'forgetting' to update
> t
On Tue, May 13, 2014 at 01:51:21PM +0800, Lai Jiangshan wrote:
> I considered you blamed to me.
> I would feel better if you directly blamed to me.
Well, the way I see it all you're to blame for is 'forgetting' to update
the rt mutex test for 3 years, and while that is unfortunate, the much
bigger
Lai,
On Tue, 13 May 2014, Lai Jiangshan wrote:
> I think this patch is just a workaround, it is not the proper fix.
> you need a updated deadlock-check mechanism:
>
> - (old) skip the check when top_waiter != task_top_pi_waiter(task)
> + (new) skip the check when top_waiter->prio > task->prio
>
Hi, Thomas,
I think this patch is just a workaround, it is not the proper fix.
you need a updated deadlock-check mechanism:
- (old) skip the check when top_waiter != task_top_pi_waiter(task)
+ (new) skip the check when top_waiter->prio > task->prio
/*
* Drop out, when the task h
If a task T holds rtmutex L and has pending waiters on that lock then
an attempt of task T to recursivly lock L can escape the deadlock
detection if T itself does not end up being the top most waiter on
that lock. So it happily enqueues itself in the waiter list.
This was exposed by Dave Jones tri
18 matches
Mail list logo
