All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Schillstrom <hans@schillstrom.com>
To: David Rientjes <rientjes@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Christoph Lameter <cl@gentwo.org>, Ingo Molnar <mingo@redhat.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Matt Mackall <mpm@selenic.com>,
	Sitsofe Wheeler <sitsofe@yahoo.com>,
	linux-mm@kvack.org
Subject: Re: possible slab deadlock while doing ifenslave
Date: Fri, 14 Oct 2011 08:30:47 +0200	[thread overview]
Message-ID: <201110140830.48368.hans@schillstrom.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1110131557090.10968@chino.kir.corp.google.com>


On Friday, October 14, 2011 01:03:40 David Rientjes wrote:
> On Thu, 13 Oct 2011, Hans Schillstrom wrote:
> 
> > > > Hello,
> > > > I got this when I was testing a VLAN patch i.e. using Dave Millers net-next from today.
> > > > When doing this on a single core i686 I got the warning every time,
> > > > however ifenslave is not hanging it's just a warning
> > > > Have not been testing this on a multicore jet.
> > > > 
> > > > There is no warnings with a 3.0.4 kernel.
> > > > 
> > > > Is this a known warning ?
> > > > 
> > > > ~ # ifenslave bond0 eth1 eth2
> > > > 
> > > > =============================================
> > > > [ INFO: possible recursive locking detected ]
> > > > 3.1.0-rc9+ #3
> > > > ---------------------------------------------
> > > > ifenslave/749 is trying to acquire lock:
> > > >  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> > > > 
> > > > but task is already holding lock:
> > > >  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> > > > 
> > > 
> > > Hmm, the only candidate that I can see that may have caused this is 
> > > 83835b3d9aec ("slab, lockdep: Annotate slab -> rcu -> debug_object -> 
> > > slab").  Could you try reverting that patch in your local tree and seeing 
> > > if it helps?
> > > 
> > 
> > That was not our candidate ...
> > i.e. same results
> > 
> 
> Ok, I think this may be related to what Sitsofe reported in the "lockdep 
> recursive locking detected" thread on LKML (see 
> http://marc.info/?l=linux-kernel&m=131805699106560).
> 
> Peter and Christoph hypothesized that 056c62418cc6 ("slab: fix lockdep 
> warnings") may not have had full coverage when setting lockdep classes for 
> kmem_list3 locks that may be called inside of each other because of 
> off-slab metadata.
> 
> I think it's safe to say there is no deadlock possibility here or we would 
> have seen it since 2006 and this is just a matter of lockdep annotation 
> that needs to be done.  So don't worry too much about the warning even 
> though I know it's annoying and it suppresses future lockdep output (even 
> more annoying!).

I have not seen any deadlock, and so far I've got hundreds of this warnings.

> 
> I'm not sure if there's a patch to address that yet, I think one was in 
> the works.  If not, I'll take a look at rewriting that lockdep annotation.
> 

If you want me to do some more testing, I keep the setup for a couple of month.

Thanks
Hans

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2011-10-14  6:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-12  8:19 possible slab deadlock while doing ifenslave Hans Schillstrom
2011-10-12 20:35 ` David Rientjes
2011-10-13  8:19   ` Hans Schillstrom
2011-10-13 23:03     ` David Rientjes
2011-10-13 23:21       ` Peter Zijlstra
2011-10-14  6:30       ` Hans Schillstrom [this message]
2011-11-28 21:19       ` Peter Zijlstra
2011-11-28 21:20         ` Peter Zijlstra
2011-11-29 14:58           ` Christoph Lameter
2011-11-29 15:38             ` Peter Zijlstra
2011-11-29 14:55         ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201110140830.48368.hans@schillstrom.com \
    --to=hans@schillstrom.com \
    --cc=cl@gentwo.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=mpm@selenic.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=sitsofe@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.