From: Thomas Graf <tgraf@suug.ch>
To: Patrick McHardy <kaber@trash.net>
Cc: davem@davemloft.net, netdev@oss.sgi.com, spam@crocom.com.pl,
kuznet@ms2.inr.ac.ru, jmorris@redhat.com
Subject: Re: [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs
Date: Sun, 7 Nov 2004 18:49:09 +0100 [thread overview]
Message-ID: <20041107174909.GC31969@postel.suug.ch> (raw)
In-Reply-To: <418E553C.2070006@trash.net>
> >We get a RTM_DELQDISC request so you'll increment refcnt in
> >qdisc_lookup and decrement it right before you call qdisc_destroy
> >so it actually can be deleted. The rcu callback works fine
> >and will set up a another rcu callback for the destroying of
> >the inner qdiscs. Right at this time you get a RTM_GETQDISC for
> >that inner qdisc so you'll lock on it, then the rcu callback
> >comes in and cannot delete the inner qdisc anymore. Do you want
> >to sleep in softirq context?
> >
> This can't happen. Once the inner qdiscs refcnt drops to zero
> they are removed from the list, before the rcu callback is scheduled.
> Once the RCU callback is scheduled it can't be found anymore.
Right, but what about when the RTM_GETQDISC comes in before the first
rcu callback is invoked? I'm not sure if this can happen in practice
though.
Anyways, I do think we should force the task to be completed, or
at least all the list unlinking, before the rtnl semaphore is given
back. I'm fine with postponing the deletion of the object but not
to postpone list manipulations even if we cannot reproduce it now.
We might be able to get a working solution for now but
this unneeded async behaviour will definitely cause much troubles
in the future.
I think no function that can be invoked from softirq context should
ever have the chance to sleep even if there is no path at the
moment. Why bother about this when we can move the possible sleep into
a user context only area?
> BTW: An alternative, quite unintrusive solution is to prevent anyone
> from finding the inner qdiscs after the outer one has been destroyed.
> This can be done be keeping inner qdiscs on qdisc->qdisc_list and only
> keep the top-level qdisc in struct net_device. Of course, this makes
> walking all qdiscs more complicated. A generation counter for the
> top-level qdisc should also work.
I agree, that's rather non trivial.
I'll wait for your patch but it's wrong in my eyes ;->
next prev parent reply other threads:[~2004-11-07 17:49 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-05 9:48 PROBLEM: IProute hangs after running traffic shaping scripts Szymon Miotk
2004-11-05 11:54 ` Thomas Graf
2004-11-05 14:16 ` [PATCH] PKT_SCHED: Initialize list field in dummy qdiscs Thomas Graf
2004-11-05 16:12 ` Patrick McHardy
2004-11-05 16:39 ` Thomas Graf
2004-11-05 17:26 ` Patrick McHardy
2004-11-05 17:58 ` Thomas Graf
2004-11-05 18:18 ` Patrick McHardy
2004-11-05 19:43 ` Thomas Graf
2004-11-06 1:18 ` Thomas Graf
2004-11-06 1:47 ` Patrick McHardy
2004-11-06 1:59 ` Thomas Graf
2004-11-06 14:50 ` Thomas Graf
2004-11-07 8:57 ` Patrick McHardy
2004-11-07 14:00 ` Thomas Graf
2004-11-07 16:19 ` Patrick McHardy
2004-11-07 16:33 ` Thomas Graf
2004-11-07 17:02 ` Patrick McHardy
2004-11-07 17:49 ` Thomas Graf [this message]
2004-11-07 18:22 ` Patrick McHardy
2004-11-07 19:08 ` Thomas Graf
2004-11-06 0:36 ` David S. Miller
2004-11-07 22:22 ` PROBLEM: IProute hangs after running traffic shaping scripts Patrick McHardy
2004-11-08 1:40 ` Patrick McHardy
2004-11-08 13:54 ` Thomas Graf
2004-11-08 16:12 ` Patrick McHardy
2004-11-08 18:33 ` Thomas Graf
2004-11-08 19:46 ` Patrick McHardy
2004-11-08 20:15 ` Thomas Graf
2004-11-10 0:18 ` David S. Miller
2004-11-10 0:40 ` Patrick McHardy
2004-11-10 0:55 ` Patrick McHardy
2004-11-10 6:13 ` David S. Miller
2004-11-10 12:08 ` Szymon Miotk
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=20041107174909.GC31969@postel.suug.ch \
--to=tgraf@suug.ch \
--cc=davem@davemloft.net \
--cc=jmorris@redhat.com \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@oss.sgi.com \
--cc=spam@crocom.com.pl \
/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).