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.
next prev parent 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).