netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: jamal <hadi@cyberus.ca>
Cc: Denys Fedoryshchenko <denys@visp.net.lb>, netdev@vger.kernel.org
Subject: Re: circular locking, mirred, 2.6.24.2
Date: Thu, 6 Mar 2008 22:40:00 +0100	[thread overview]
Message-ID: <20080306214000.GC2876@ami.dom.local> (raw)
In-Reply-To: <1204836523.4457.103.camel@localhost>

On Thu, Mar 06, 2008 at 03:48:42PM -0500, jamal wrote:
> On Thu, 2008-06-03 at 18:56 +0100, Jarek Poplawski wrote:
> 
> > Every netdevice after register_netdevice() has its queue_lock and
> > ingress_lock initialized with the same static lock_class_keys, so unless
> > changed later, these locks are treated by lockdep as 2 global locks.
> >  So, taking such locks with different order should be reported. 
> 
> ok.
> 
> > This really
> > happens in act_mirred, and I don't know yet, why this wasn't reported
> > earlier.
> 
> Look closely at those traces again ;-> there are *three* different
> netdevices involved, one (loopback) seems to be _totaly_ unrelated.
> Tracing of those locks just seems confused - perhaps the pernet stuff is
> confusing loopback?

But currently lockdep doesn't know dev->queue_lock could mean eth or lo.
It sees one class of devices using one lock. We can let it know (e.g.
dev->_xmit_lock is different according to dev->type), but it wasn't
necessary. I hope it will suffice here if lockdep knows more about ifb,
but similar problem could theoretically happen with other devs.

> > Of course, if there are two different devices this could be safe, but
> > not always (e.g. thread1 has dev_eth0->ingress_lock and wants
> > dev_eth1->queue_lock, thread2 has dev_eth1->ingress_lock, wants
> > dev_eth0->qdisc_lock, and thread3 has dev_eth0->qdisc_lock and wants

Sorry, should be:
 dev_eth0->queue_lock, and thread3 has dev_eth0->queue_lock and wants

> > dev_eth0->ingress_lock). With ifb this shouldn't be the case, but
> > anyway we have to tell lockdep that ifb uses a different pair of locks.
> 
> thread3 can not happen because we dont allow it (the other 2 are not
> contentious).

Could you explain why? It's a qdisc_lock_tree case and probably not only
this.

> There are cases where redirecting will cause you problems (example if
> you redirected to yourself and cause an infinite redirect) which are
> listed in iproute2/doc. Denys script is fine afaics.

Yes, but it seems such redirection between two eths like above mentioned
is legal?

Jarek P.

  reply	other threads:[~2008-03-06 21:34 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24 22:20 circular locking, mirred, 2.6.24.2 Denys Fedoryshchenko
2008-02-25  9:56 ` Jarek Poplawski
2008-02-25 10:48   ` Denys Fedoryshchenko
2008-02-25 11:39     ` Jarek Poplawski
2008-03-05 10:45       ` Denys Fedoryshchenko
2008-03-05 13:54         ` [BUG] Probably lockdep bug " Jarek Poplawski
2008-03-06  9:41           ` Jarek Poplawski
2008-03-06 13:40         ` Jarek Poplawski
2008-03-06 13:57           ` Denys Fedoryshchenko
2008-03-06 14:27             ` jamal
2008-03-06 15:50               ` Denys Fedoryshchenko
2008-03-06 20:25                 ` Jarek Poplawski
2008-03-06 20:56                   ` jamal
2008-03-06 22:12                     ` Jarek Poplawski
2008-03-06 23:43                       ` Denys Fedoryshchenko
2008-03-07  0:09                         ` jamal
2008-03-07  0:15                           ` Denys Fedoryshchenko
2008-03-07  0:25                             ` jamal
2008-03-07  9:31                         ` Jarek Poplawski
2008-03-07 10:19                           ` Denys Fedoryshchenko
2008-03-07 10:48                             ` Jarek Poplawski
2008-03-07 14:58                             ` jamal
2008-03-06 20:44                 ` jamal
2008-03-06 13:59           ` jamal
2008-03-06 17:56             ` Jarek Poplawski
2008-03-06 20:48               ` jamal
2008-03-06 21:40                 ` Jarek Poplawski [this message]
2008-03-06 23:40                   ` jamal
2008-03-07  7:51                     ` Jarek Poplawski
2008-03-07  8:32                       ` Jarek Poplawski
2008-03-07 13:53                       ` jamal
2008-03-08  8:46                         ` Jarek Poplawski
2008-03-08  8:58                           ` Jarek Poplawski
2008-03-08  9:56                             ` Denys Fedoryshchenko
2008-03-08 10:16                             ` Denys Fedoryshchenko
2008-03-08 10:43                               ` Jarek Poplawski
2008-03-08 10:52                                 ` Jarek Poplawski
2008-03-08 11:09                                   ` Denys Fedoryshchenko
2008-03-08 12:02                                     ` Jarek Poplawski
2008-03-19  0:46                                       ` Denys Fedoryshchenko
2008-03-19  7:34                                         ` [PATCH][NET] ifb: set separate lockdep classes for queue locks Jarek Poplawski
2008-03-19 11:34                                           ` jamal
2008-03-19 12:20                                             ` Jarek Poplawski
2008-03-20 22:37                                           ` David Miller
2008-03-21  0:03                                             ` [PATCH take2][NET] " Jarek Poplawski
2008-03-21  0:05                                               ` David Miller
2008-03-21  0:15                                               ` Jarek Poplawski

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=20080306214000.GC2876@ami.dom.local \
    --to=jarkao2@gmail.com \
    --cc=denys@visp.net.lb \
    --cc=hadi@cyberus.ca \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).