* 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 er
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 what
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 f
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 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, 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 <[EMAI
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 2.6.
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 w
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
> 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:
> > > > > O
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
> > > > PR
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
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() ther
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 th
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 lock
> 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 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: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() 2) dqptr_sem (somewhere later)
> > -> #0: 1) dq
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 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 er
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 supp
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, that'
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 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 [n
> > 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 ther
> 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]
...
[ 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: (&inode->i_mutex){--.
32 matches
Mail list logo
