Peter Zijlstra wrote, On 12/08/2007 09:50 PM:
> On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
>
>> Which problems? I did not see any special things, it looked rather
>> straight forward. What have I overlooked?
>
> On suspend it locks the whole device tree, this means it has 'unbounded'
Peter,
Thanks for this clear answer.
Remy
2007/12/8, Peter Zijlstra <[EMAIL PROTECTED]>:
>
> On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
>
> > Which problems? I did not see any special things, it looked rather
> > straight forward. What have I overlooked?
>
> On suspend it locks the
On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
> Which problems? I did not see any special things, it looked rather
> straight forward. What have I overlooked?
On suspend it locks the whole device tree, this means it has 'unbounded'
nesting and holds an 'unbounded' number of locks.
Hello Ingo,
> no, you are wrong. If you want to do complex locking, you can still do
> it: take a look at the dev->sem conversion patches from Peter which
> correctly do this. Lockdep has all the facilities for that.
> (you just dont know about them)
Ok.
> the general policy message here is: do
Hello Peter,
> And while you might not see it in-tree anymore, lockdep does help out
> tremendously while developing new code. I'm sure that without it the
> locking would be in a much worse state than it is today.
I am not arguing that, I am also convinced it has done a good job.
> I have a
* Remy Bohmer <[EMAIL PROTECTED]> wrote:
> But... now we do not transfer the dev->sem to a mutex, because lockdep
> will start generating false positives, and thus we mask the lockdep
> error, by not converting the dev->sem to what it really is...
no, you are wrong. If you want to do complex
On Sat, 2007-12-08 at 20:52 +0100, Remy Bohmer wrote:
> Hello Peter and Daniel,
>
> > Yeah, it are different lock instances, however by virtue of sharing the
> > same lock init site, they belong to the same lock class. Lockdep works
> > by tracking class dependancies, not instance dependancies.
Hello Peter and Daniel,
> Yeah, it are different lock instances, however by virtue of sharing the
> same lock init site, they belong to the same lock class. Lockdep works
> by tracking class dependancies, not instance dependancies.
The device and its parent both indeed have different
On Sat, 2007-12-08 at 08:53 -0800, Daniel Walker wrote:
> On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote:
> > On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote:
> > > Hello Peter,
> > >
> > > > > What specifically is wrong with dev->sem ?
> > > >
> > > > Nothing really, other than
On Sat, 2007-12-08 at 09:06 -0800, Daniel Walker wrote:
> On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote:
>
> > > It must be the locking in __driver_attach(), taking dev->parent->sem
> > > then taking dev->sem .. Assuming those are different structures, why
> > > does lockdep trigger?
>
On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote:
> > It must be the locking in __driver_attach(), taking dev->parent->sem
> > then taking dev->sem .. Assuming those are different structures, why
> > does lockdep trigger?
>
> They aren't different, parent is a struct device again.
It's
On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote:
> On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote:
> > Hello Peter,
> >
> > > > What specifically is wrong with dev->sem ?
> > >
> > > Nothing really, other than that they use semaphores to avoid lockdep :-/
> > >
> > > I think I know
On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote:
> Hello Peter,
>
> > > What specifically is wrong with dev->sem ?
> >
> > Nothing really, other than that they use semaphores to avoid lockdep :-/
> >
> > I think I know how to annotate this, after Alan Stern explained all the
> > use cases,
On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote:
Hello Peter,
What specifically is wrong with dev-sem ?
Nothing really, other than that they use semaphores to avoid lockdep :-/
I think I know how to annotate this, after Alan Stern explained all the
use cases, but I haven't
On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote:
On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote:
Hello Peter,
What specifically is wrong with dev-sem ?
Nothing really, other than that they use semaphores to avoid lockdep :-/
I think I know how to annotate this,
On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote:
It must be the locking in __driver_attach(), taking dev-parent-sem
then taking dev-sem .. Assuming those are different structures, why
does lockdep trigger?
They aren't different, parent is a struct device again.
It's different
On Sat, 2007-12-08 at 09:06 -0800, Daniel Walker wrote:
On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote:
It must be the locking in __driver_attach(), taking dev-parent-sem
then taking dev-sem .. Assuming those are different structures, why
does lockdep trigger?
They
On Sat, 2007-12-08 at 08:53 -0800, Daniel Walker wrote:
On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote:
On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote:
Hello Peter,
What specifically is wrong with dev-sem ?
Nothing really, other than that they use semaphores
Hello Peter and Daniel,
Yeah, it are different lock instances, however by virtue of sharing the
same lock init site, they belong to the same lock class. Lockdep works
by tracking class dependancies, not instance dependancies.
The device and its parent both indeed have different
On Sat, 2007-12-08 at 20:52 +0100, Remy Bohmer wrote:
Hello Peter and Daniel,
Yeah, it are different lock instances, however by virtue of sharing the
same lock init site, they belong to the same lock class. Lockdep works
by tracking class dependancies, not instance dependancies.
The
* Remy Bohmer [EMAIL PROTECTED] wrote:
But... now we do not transfer the dev-sem to a mutex, because lockdep
will start generating false positives, and thus we mask the lockdep
error, by not converting the dev-sem to what it really is...
no, you are wrong. If you want to do complex
Hello Peter,
And while you might not see it in-tree anymore, lockdep does help out
tremendously while developing new code. I'm sure that without it the
locking would be in a much worse state than it is today.
I am not arguing that, I am also convinced it has done a good job.
I have a good
Hello Ingo,
no, you are wrong. If you want to do complex locking, you can still do
it: take a look at the dev-sem conversion patches from Peter which
correctly do this. Lockdep has all the facilities for that.
(you just dont know about them)
Ok.
the general policy message here is: do not
On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
Which problems? I did not see any special things, it looked rather
straight forward. What have I overlooked?
On suspend it locks the whole device tree, this means it has 'unbounded'
nesting and holds an 'unbounded' number of locks. Neither
Peter,
Thanks for this clear answer.
Remy
2007/12/8, Peter Zijlstra [EMAIL PROTECTED]:
On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
Which problems? I did not see any special things, it looked rather
straight forward. What have I overlooked?
On suspend it locks the whole device
Peter Zijlstra wrote, On 12/08/2007 09:50 PM:
On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
Which problems? I did not see any special things, it looked rather
straight forward. What have I overlooked?
On suspend it locks the whole device tree, this means it has 'unbounded'
Hello Peter,
> > What specifically is wrong with dev->sem ?
>
> Nothing really, other than that they use semaphores to avoid lockdep :-/
>
> I think I know how to annotate this, after Alan Stern explained all the
> use cases, but I haven't come around to implementing it. Hope to do that
>
Hello Peter,
What specifically is wrong with dev-sem ?
Nothing really, other than that they use semaphores to avoid lockdep :-/
I think I know how to annotate this, after Alan Stern explained all the
use cases, but I haven't come around to implementing it. Hope to do that
soonish.
I was
28 matches
Mail list logo
