From: Jiri Pirko <jiri@resnulli.us>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: John Fastabend <john.fastabend@gmail.com>,
David Miller <davem@davemloft.net>,
Jakub Kicinski <kubakici@wp.pl>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH] net: Revert "net_sched: no need to free qdisc in RCU callback"
Date: Fri, 22 Dec 2017 10:35:24 +0100 [thread overview]
Message-ID: <20171222093524.GA11519@nanopsycho> (raw)
In-Reply-To: <CAM_iQpVkV0YbOaSfmXb_=OpzpxepmxkXHKibKUcmhELZBM-Abg@mail.gmail.com>
Thu, Dec 21, 2017 at 09:59:56PM CET, xiyou.wangcong@gmail.com wrote:
>On Thu, Dec 21, 2017 at 12:39 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Why just moving qdisc_free to rcu is not enough? It would resolve this
>> issue and also avoid using synchronize net. Something like:
>
>If you mean Jakub's issue, apparently not:
>https://www.kernel.org/pub/linux/kernel/people/paulmck/Answers/RCU/RCUCBordering.html
>
>Jiri, you have to use a rcu barrier to wait for a rcu callback, not
>queuing another rcu callback, the ordering is simply NOT guaranteed.
Sure. But the ordering does not matter in this case. You just need to
make sure the reader does not see freed qdisc struct.
>
>What's more importantly, you already have one rcu barrier in the
>same function. Why keep believing you don't need it?
The rcu barrier is there for a different reason. It is there to avoid
reuse of old miniq that readers still might see in scenario
miniq1
miniq2
miniq1 again
prev parent reply other threads:[~2017-12-22 9:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-20 20:09 [PATCH] net: Revert "net_sched: no need to free qdisc in RCU callback" John Fastabend
2017-12-20 21:59 ` Jakub Kicinski
2017-12-20 23:40 ` John Fastabend
2017-12-20 22:41 ` Cong Wang
2017-12-20 23:05 ` John Fastabend
2017-12-20 23:23 ` Cong Wang
2017-12-20 23:34 ` John Fastabend
2017-12-21 8:39 ` Jiri Pirko
2017-12-21 20:59 ` Cong Wang
2017-12-22 9:35 ` Jiri Pirko [this message]
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=20171222093524.GA11519@nanopsycho \
--to=jiri@resnulli.us \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=kubakici@wp.pl \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/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).