All of lore.kernel.org
 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 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.