From: Jarek Poplawski <jarkao2@o2.pl>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: Patrick McHardy <kaber@trash.net>, Dave Jones <davej@redhat.com>,
hadi@cyberus.ca, netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: tc related lockdep warning.
Date: Fri, 29 Sep 2006 08:28:18 +0200 [thread overview]
Message-ID: <20060929062818.GA1011@ff.dom.local> (raw)
In-Reply-To: <20060928072000.014009f2@freekitty>
On Thu, Sep 28, 2006 at 07:20:00AM -0700, Stephen Hemminger wrote:
> On Thu, 28 Sep 2006 15:13:01 +0200
> Jarek Poplawski <jarkao2@o2.pl> wrote:
>
> > On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
> > > [My mail provider is down, so responding "manually"]
> > >
> > > Jarek Poplawski wrote:
> > > > > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
> > > >
> > > > Sorry again but I can't abstain from some doubts:
> > > >
> > > > ...
> > > > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > > > index 14de297..4d891be 100644
> > > > > --- a/net/core/dev.c
> > > > > +++ b/net/core/dev.c
> > > > > @@ -1480,14 +1480,16 @@ #endif
> > > > > if (q->enqueue) {
> > > > > /* Grab device queue */
> > > > > spin_lock(&dev->queue_lock);
> > > > > + q = dev->qdisc;
> > > >
> > > > I don't get it. If it is some anti-race step according to
> > > > rcu rules it should be again:
> > > > q = rcu_dereference(dev->qdisc);
> > >
> > > At this point RCU protection is not needed anymore since we
> > > have the lock. We simply want to avoid taking the lock for
> > > devices that don't have a real qdisc attached (like loopback).
> > > Thats what the test for q->enqueue is there for. RCU is only
> > > needed to avoid races between testing q->enqueue and freeing
> > > of the qdisc.
> >
> > But in Documentation/RCU/whatisRCU.txt I see this:
> >
> > /*
> > * Return the value of field "a" of the current gbl_foo
> > * structure. Use rcu_read_lock() and rcu_read_unlock()
> > * to ensure that the structure does not get deleted out
> > * from under us, and use rcu_dereference() to ensure that
> > * we see the initialized version of the structure (important
> > * for DEC Alpha and for people reading the code).
> > */
> > int foo_get_a(void)
> > {
> > int retval;
> >
> > rcu_read_lock();
> > retval = rcu_dereference(gbl_foo)->a;
> > rcu_read_unlock();
> > return retval;
> > }
> >
>
> The example uses rcu_read_lock() which is a weaker form of protection
> than a real lock, so the rcu_dereference() is needed to do memory barriers.
I don't question this and I know it is not required - I mean
what is in the parenthesis ("important ...") or here:
>From Documentation/RCU/checklist.txt:
The rcu_dereference() primitive is used by the various
"_rcu()" list-traversal primitives, such as the
list_for_each_entry_rcu(). Note that it is perfectly
legal (if redundant) for update-side code to use
rcu_dereference() and the "_rcu()" list-traversal
primitives. This is particularly useful in code
that is common to readers and updaters.
> In the qdisc case we have the proper spin_lock() so no additional
> barrier is needed.
So why isn't it done in the code instead of comments?:
if (q->enqueue) {
rcu_read_unlock();
/* Grab device queue */
spin_lock(&dev->queue_lock);
q = dev->qdisc;
...
}
rcu_read_unlock();
I mean the consequence.
Another thing is why? Now it looks RCU is good for the first test
but we don't believe it entirely (or assume the pointer could change
at this particular moment) so take this pointer again with
a real lock. I think RCU assures the consistency within it's block
and we should only test for NULL pointer.
Jarek P.
next prev parent reply other threads:[~2006-09-29 6:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-24 21:29 tc related lockdep warning Dave Jones
2006-09-25 12:43 ` Jarek Poplawski
2006-09-25 12:47 ` jamal
2006-09-25 13:05 ` Jarek Poplawski
2006-09-25 13:29 ` Patrick McHardy
2006-09-26 16:15 ` Patrick McHardy
2006-09-26 21:20 ` Dave Jones
2006-09-27 8:54 ` Jarek Poplawski
2006-09-27 9:57 ` Patrick McHardy
2006-09-28 12:17 ` Patrick McHardy
2006-09-28 13:13 ` Jarek Poplawski
2006-09-28 14:20 ` Stephen Hemminger
2006-09-29 6:28 ` Jarek Poplawski [this message]
2006-09-27 10:14 ` Patrick McHardy
2006-09-27 14:41 ` Ismail Donmez
2006-09-27 12:07 ` Patrick McHardy
2006-09-27 17:26 ` Ismail Donmez
2006-09-27 17:33 ` Dave Jones
2006-09-27 23:53 ` David Miller
2006-09-28 9:07 ` Jarek Poplawski
2006-09-28 8:17 ` 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=20060929062818.GA1011@ff.dom.local \
--to=jarkao2@o2.pl \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@osdl.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).