* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-22 at 07:11 +0100, Jarek Poplawski wrote:
> > Here is some joke:
> >
> > [PATCH] lockdep: lockdep_depth vs. debug_locks
> >
> > lockdep really shouldn't be used when debug_locks == 0!
>
> This happens then lockdep reports a fatal
On Wed, Mar 21, 2007 at 10:28:02PM -0800, Andrew Morton wrote:
> On Thu, 22 Mar 2007 07:11:19 +0100 Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> >
> > Here is some joke:
> >
> > [PATCH] lockdep: lockdep_depth vs. debug_locks
> >
> > lockdep really shouldn't be used when debug_locks == 0!
> >
On Thu, 2007-03-22 at 07:11 +0100, Jarek Poplawski wrote:
> Here is some joke:
>
> [PATCH] lockdep: lockdep_depth vs. debug_locks
>
> lockdep really shouldn't be used when debug_locks == 0!
This happens then lockdep reports a fatal error, at which point
it will stop tracking locks and leave
On Thu, Mar 22, 2007 at 08:06:44AM +0100, Jarek Poplawski wrote:
...
> This should definitely solve this problem - as it was said
> a few times before lockdep stops registering locks after
> a bug, so even the lock which caused the warning isn't
> reported. Here lockdep found a bug in a workqueue
On Wed, Mar 21, 2007 at 10:28:02PM -0800, Andrew Morton wrote:
...
> I assume that some codepath is incrementing ->lockdep_depth even when
> debug_locks==0. Isn't that wrong of it?
>
lockdep simply stops to update lockdep_depth just after (during)
a bug or a WARN.
Jarek P.
-
To unsubscribe
On Wed, Mar 21, 2007 at 10:28:02PM -0800, Andrew Morton wrote:
> On Thu, 22 Mar 2007 07:11:19 +0100 Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> >
> > Here is some joke:
> >
> > [PATCH] lockdep: lockdep_depth vs. debug_locks
> >
> > lockdep really shouldn't be used when debug_locks == 0!
> >
On Wed, Mar 21, 2007 at 10:28:02PM -0800, Andrew Morton wrote:
On Thu, 22 Mar 2007 07:11:19 +0100 Jarek Poplawski [EMAIL PROTECTED] wrote:
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
This isn't a
On Wed, Mar 21, 2007 at 10:28:02PM -0800, Andrew Morton wrote:
...
I assume that some codepath is incrementing -lockdep_depth even when
debug_locks==0. Isn't that wrong of it?
lockdep simply stops to update lockdep_depth just after (during)
a bug or a WARN.
Jarek P.
-
To unsubscribe from
On Thu, Mar 22, 2007 at 08:06:44AM +0100, Jarek Poplawski wrote:
...
This should definitely solve this problem - as it was said
a few times before lockdep stops registering locks after
a bug, so even the lock which caused the warning isn't
reported. Here lockdep found a bug in a workqueue
On Thu, 2007-03-22 at 07:11 +0100, Jarek Poplawski wrote:
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
This happens then lockdep reports a fatal error, at which point
it will stop tracking locks and leave whatever
On Wed, Mar 21, 2007 at 10:28:02PM -0800, Andrew Morton wrote:
On Thu, 22 Mar 2007 07:11:19 +0100 Jarek Poplawski [EMAIL PROTECTED] wrote:
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
This isn't a
* Peter Zijlstra [EMAIL PROTECTED] wrote:
On Thu, 2007-03-22 at 07:11 +0100, Jarek Poplawski wrote:
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
This happens then lockdep reports a fatal error, at which
On Thu, 22 Mar 2007 07:11:19 +0100 Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> Here is some joke:
>
> [PATCH] lockdep: lockdep_depth vs. debug_locks
>
> lockdep really shouldn't be used when debug_locks == 0!
>
This isn't a very good changelog.
>
> Reported-by: Folkert van Heusden
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
Reported-by: Folkert van Heusden <[EMAIL PROTECTED]>
Inspired-by: Oleg Nesterov <[EMAIL PROTECTED]>
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp
On 03/21, Oleg Nesterov wrote:
>
> On 03/21, Jarek Poplawski wrote:
> >
> > So, if
> > you have another idea for looking after it, let us know.
>
> No, I don't.
Perhaps we can add lockdep_depth() checks to laundromat_main/nfs4_laundromat
to rule out workqueue.c. According to the trace, we return
On 03/21, Jarek Poplawski wrote:
>
> > Sorry, I can't understand you. lockdep_depth is counted within a process,
> > which starts before f(), yes. This process is cwq->thread, it was forked
> > during create_workqueue(). It does not take any locks directly, only by
> > calling work->func().
> I thought you are trying to diagnose a bug and maybe Folkert could test,
> if this patch makes any difference. Sorry, if I missed the real problem.
Yes please let me know when I can test a patch.
Folkert van Heusden
--
www.biglumber.com <- site where one can exchange PGP key signatures
On Wed, Mar 21, 2007 at 05:46:20PM +0300, Oleg Nesterov wrote:
> On 03/21, Jarek Poplawski wrote:
> >
> > On Tue, Mar 20, 2007 at 07:07:59PM +0300, Oleg Nesterov wrote:
> > > On 03/20, Jarek Poplawski wrote:
> > ...
> > > > >>> On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
> > > > >
On 03/21, Jarek Poplawski wrote:
>
> On Tue, Mar 20, 2007 at 07:07:59PM +0300, Oleg Nesterov wrote:
> > On 03/20, Jarek Poplawski wrote:
> ...
> > > >>> On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
> > > > On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL
> > > >
On Tue, Mar 20, 2007 at 07:07:59PM +0300, Oleg Nesterov wrote:
> On 03/20, Jarek Poplawski wrote:
...
> > >>> On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
> > > On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL
> > > PROTECTED]> wrote:
> > > ...
> > > [
On Tue, Mar 20, 2007 at 07:07:59PM +0300, Oleg Nesterov wrote:
On 03/20, Jarek Poplawski wrote:
...
On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden [EMAIL
PROTECTED] wrote:
...
[ 1756.728209] BUG: workqueue leaked lock
On 03/21, Jarek Poplawski wrote:
On Tue, Mar 20, 2007 at 07:07:59PM +0300, Oleg Nesterov wrote:
On 03/20, Jarek Poplawski wrote:
...
On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden [EMAIL
PROTECTED] wrote:
...
On Wed, Mar 21, 2007 at 05:46:20PM +0300, Oleg Nesterov wrote:
On 03/21, Jarek Poplawski wrote:
On Tue, Mar 20, 2007 at 07:07:59PM +0300, Oleg Nesterov wrote:
On 03/20, Jarek Poplawski wrote:
...
On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
On Tue, 13 Mar 2007
I thought you are trying to diagnose a bug and maybe Folkert could test,
if this patch makes any difference. Sorry, if I missed the real problem.
Yes please let me know when I can test a patch.
Folkert van Heusden
--
www.biglumber.com - site where one can exchange PGP key signatures
On 03/21, Jarek Poplawski wrote:
Sorry, I can't understand you. lockdep_depth is counted within a process,
which starts before f(), yes. This process is cwq-thread, it was forked
during create_workqueue(). It does not take any locks directly, only by
calling work-func(). laundry_wq
On 03/21, Oleg Nesterov wrote:
On 03/21, Jarek Poplawski wrote:
So, if
you have another idea for looking after it, let us know.
No, I don't.
Perhaps we can add lockdep_depth() checks to laundromat_main/nfs4_laundromat
to rule out workqueue.c. According to the trace, we return with
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
Reported-by: Folkert van Heusden [EMAIL PROTECTED]
Inspired-by: Oleg Nesterov [EMAIL PROTECTED]
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp
On Thu, 22 Mar 2007 07:11:19 +0100 Jarek Poplawski [EMAIL PROTECTED] wrote:
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
This isn't a very good changelog.
Reported-by: Folkert van Heusden [EMAIL
On 03/20, Jarek Poplawski wrote:
>
> >> On Fri, 16 Mar 2007 09:41:20 +0100 Peter Zijlstra <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
> > On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL
> > PROTECTED]> wrote:
> >
On Tue, 2007-03-20 at 15:21 +0100, Jan Kara wrote:
> On Tue 20-03-07 14:35:10, Arjan van de Ven wrote:
> >
> >
> > > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex
> > > being
> > > acquired under dqptr_sem in quota code. But looking at the path from
> > > con_close()
On Tue 20-03-07 14:35:10, Arjan van de Ven wrote:
>
>
> > Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being
> > acquired under dqptr_sem in quota code. But looking at the path from
> > con_close() there's another inversion with i_mutex which is also acquired
> > along
On Tue 20-03-07 14:44:46, Jarek Poplawski wrote:
> On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote:
> > On Tue 20-03-07 12:31:51, Jarek Poplawski wrote:
> > > On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote:
> > > > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski
On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote:
> On Tue 20-03-07 12:31:51, Jarek Poplawski wrote:
> > On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote:
> > > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote:
> > > ...
> > > > IMHO lockdep found that two
> Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being
> acquired under dqptr_sem in quota code. But looking at the path from
> con_close() there's another inversion with i_mutex which is also acquired
> along the path for sysfs. And we can hardly get rid of it in the
On Tue 20-03-07 12:31:51, Jarek Poplawski wrote:
> On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote:
> > On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote:
> > ...
> > > IMHO lockdep found that two locks are taken in different order:
> > >
> > > -> #1: 1) tty_mutex in
On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote:
...
> IMHO lockdep found that two locks are taken in different order:
>
> -> #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later)
> -> #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with print_warning()
Should
On 15-03-2007 20:17, Folkert van Heusden wrote:
>>> On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL PROTECTED]>
>>> wrote:
...
> Haha ok :-)
>
> Good, since I run 2.6.20 with these debugging switches switched on, I
> get occasionally errors like these. I get ALWAYS the following
On 19-03-2007 07:24, Neil Brown wrote:
> On Friday March 16, [EMAIL PROTECTED] wrote:
>> OK. That's not necessarily a bug: one could envisage a (weird) piece of
>> code which takes a lock then releases it on a later workqueue invokation.
>> But I'm not sure that nfs4_laundromat() is actually
On 19-03-2007 07:24, Neil Brown wrote:
On Friday March 16, [EMAIL PROTECTED] wrote:
OK. That's not necessarily a bug: one could envisage a (weird) piece of
code which takes a lock then releases it on a later workqueue invokation.
But I'm not sure that nfs4_laundromat() is actually supposed
On 15-03-2007 20:17, Folkert van Heusden wrote:
On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden [EMAIL PROTECTED]
wrote:
...
Haha ok :-)
Good, since I run 2.6.20 with these debugging switches switched on, I
get occasionally errors like these. I get ALWAYS the following error
when
On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote:
...
IMHO lockdep found that two locks are taken in different order:
- #1: 1) tty_mutex in con_console() 2) dqptr_sem (somewhere later)
- #0: 1) dqptr_sem 2) tty_console in dquot_alloc_space() with print_warning()
Should be:
-
On Tue 20-03-07 12:31:51, Jarek Poplawski wrote:
On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote:
On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote:
...
IMHO lockdep found that two locks are taken in different order:
- #1: 1) tty_mutex in con_console()
Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being
acquired under dqptr_sem in quota code. But looking at the path from
con_close() there's another inversion with i_mutex which is also acquired
along the path for sysfs. And we can hardly get rid of it in the quota
On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote:
On Tue 20-03-07 12:31:51, Jarek Poplawski wrote:
On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote:
On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote:
...
IMHO lockdep found that two locks are taken
On Tue 20-03-07 14:44:46, Jarek Poplawski wrote:
On Tue, Mar 20, 2007 at 01:19:09PM +0100, Jan Kara wrote:
On Tue 20-03-07 12:31:51, Jarek Poplawski wrote:
On Tue, Mar 20, 2007 at 12:22:53PM +0100, Jarek Poplawski wrote:
On Tue, Mar 20, 2007 at 12:17:01PM +0100, Jarek Poplawski wrote:
On Tue 20-03-07 14:35:10, Arjan van de Ven wrote:
Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex being
acquired under dqptr_sem in quota code. But looking at the path from
con_close() there's another inversion with i_mutex which is also acquired
along the path
On Tue, 2007-03-20 at 15:21 +0100, Jan Kara wrote:
On Tue 20-03-07 14:35:10, Arjan van de Ven wrote:
Yes, I was looking at it. Hmm, we can possibly get rid of tty_mutex
being
acquired under dqptr_sem in quota code. But looking at the path from
con_close() there's another
On 03/20, Jarek Poplawski wrote:
On Fri, 16 Mar 2007 09:41:20 +0100 Peter Zijlstra [EMAIL PROTECTED]
wrote:
On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden [EMAIL
PROTECTED] wrote:
...
[ 1756.728209] BUG: workqueue
On Friday March 16, [EMAIL PROTECTED] wrote:
>
> OK. That's not necessarily a bug: one could envisage a (weird) piece of
> code which takes a lock then releases it on a later workqueue invokation.
> But I'm not sure that nfs4_laundromat() is actually supposed to be doing
> anything like that.
>
On Friday March 16, [EMAIL PROTECTED] wrote:
OK. That's not necessarily a bug: one could envisage a (weird) piece of
code which takes a lock then releases it on a later workqueue invokation.
But I'm not sure that nfs4_laundromat() is actually supposed to be doing
anything like that.
On 15-03-2007 20:17, Folkert van Heusden wrote:
>>> On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL PROTECTED]>
>>> wrote:
>>> ...
>>> [ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
> ...
>>> [ 1846.684023] [] kernel_thread_helper+0x7/0x10
>> Oleg,
On Fri, 16 Mar 2007 09:41:20 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
> > > On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL
> > > PROTECTED]> wrote:
> > > ...
> > > [ 1756.728209] BUG: workqueue leaked lock or
On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
> > On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL PROTECTED]>
> > wrote:
> > ...
> > [ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
> > [ 1756.728271] last function: laundromat_main+0x0/0x69
On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden [EMAIL PROTECTED]
wrote:
...
[ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
[ 1756.728271] last function: laundromat_main+0x0/0x69 [nfsd]
[
On Fri, 16 Mar 2007 09:41:20 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Thu, 2007-03-15 at 11:06 -0800, Andrew Morton wrote:
On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden [EMAIL
PROTECTED] wrote:
...
[ 1756.728209] BUG: workqueue leaked lock or atomic:
On 15-03-2007 20:17, Folkert van Heusden wrote:
On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden [EMAIL PROTECTED]
wrote:
...
[ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
...
[ 1846.684023] [c1003bdb] kernel_thread_helper+0x7/0x10
Oleg, that's a fairly
> > On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL PROTECTED]>
> > wrote:
> > ...
> > [ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
...
> > [ 1846.684023] [] kernel_thread_helper+0x7/0x10
> Oleg, that's a fairly incomprehensible message we have in
> On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden <[EMAIL PROTECTED]>
> wrote:
> ...
> [ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
> [ 1756.728271] last function: laundromat_main+0x0/0x69 [nfsd]
> [ 1756.728392] 2 locks held by nfsd4/3577:
> [
On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden [EMAIL PROTECTED]
wrote:
...
[ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
[ 1756.728271] last function: laundromat_main+0x0/0x69 [nfsd]
[ 1756.728392] 2 locks held by nfsd4/3577:
[ 1756.728435] #0:
On Tue, 13 Mar 2007 17:50:14 +0100 Folkert van Heusden [EMAIL PROTECTED]
wrote:
...
[ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
...
[ 1846.684023] [c1003bdb] kernel_thread_helper+0x7/0x10
Oleg, that's a fairly incomprehensible message we have in there.
...
[ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
[ 1756.728271] last function: laundromat_main+0x0/0x69 [nfsd]
[ 1756.728392] 2 locks held by nfsd4/3577:
[ 1756.728435] #0: (client_mutex){--..}, at: [] mutex_lock+0x8/0xa
[ 1756.728679] #1: (>i_mutex){--..},
...
[ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
[ 1756.728271] last function: laundromat_main+0x0/0x69 [nfsd]
[ 1756.728392] 2 locks held by nfsd4/3577:
[ 1756.728435] #0: (client_mutex){--..}, at: [c1205b88] mutex_lock+0x8/0xa
[ 1756.728679] #1:
62 matches
Mail list logo
