From: Corey Minyard <minyard@acm.org>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: paulmck@linux.vnet.ibm.com,
Linux Kernel <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH 1/1] Use RCU for the UDP hash lock
Date: Thu, 25 Sep 2008 14:21:55 -0500 [thread overview]
Message-ID: <48DBE4D3.9060809@acm.org> (raw)
In-Reply-To: <20080925083431.3fa0f9c3@extreme>
Stephen Hemminger wrote:
> On Thu, 25 Sep 2008 08:29:36 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
>
>> On Wed, Sep 24, 2008 at 03:46:20PM -0500, Corey Minyard wrote:
>>
>>> Stephen Hemminger wrote:
>>>
>>>>
>>>>
>>>>> static inline void udp_lib_unhash(struct sock *sk)
>>>>> {
>>>>> - write_lock_bh(&udp_hash_lock);
>>>>> - if (sk_del_node_init(sk)) {
>>>>> + spin_lock_bh(&udp_hash_wlock);
>>>>> + if (sk_del_node_rcu(sk)) {
>>>>> inet_sk(sk)->num = 0;
>>>>> sock_prot_inuse_add(sock_net(sk), sk->sk_prot, -1);
>>>>> }
>>>>> - write_unlock_bh(&udp_hash_lock);
>>>>> + spin_unlock_bh(&udp_hash_wlock);
>>>>> + synchronize_sched();
>>>>>
>>>>>
>>>> Could this be synchronize_rcu? You are using rcu_read_lock() protected
>>>> sections.
>>>>
>>>>
>>> I meant to comment on that. I wasn't sure which to use, so I chose the
>>> more conservative approach. synchronize_rcu() might be appropriate.
>>>
>> You do indeed need to match the update-side and read-side primitives:
>>
>> Update-side Read-side
>>
>> synchronize_rcu() rcu_read_lock()
>> call_rcu() rcu_read_unlock()
>>
>> call_rcu_bh() rcu_read_lock_bh()
>> rcu_read_unlock_bh()
>>
>> synchronize_sched() preempt_disable()
>> preempt_enable()
>> [and anything else
>> that disables either
>> preemption or irqs]
>>
>> synchronize_srcu() srcu_read_lock()
>> srcu_read_unlock()
>>
>>
>> Mixing RCU or RCU-SCHED with RCU-BH will fail in Classic RCU systems,
>> while mixing RCU or RCU-BH with RCU-SCHED will fail in preemptable RCU
>> systems. Mixing SRCU with any of the other flavors of RCU will fail
>> on any system.
>>
>> So please match them up correctly!
>>
Ok, will do. I read more on this, and I think I understand the issues
better.
>>
>
> Also, for consistency with other parts of networking code, don't introduce
> the synchronize_sched() or synchronize_srcu() pattern to network protocols
> unless there is a no other way to achieve the desired result.
>
Do you mean synchronize_rcu(), too? It seems to be used in the net
code. To avoid that I'd need to add a struct rcu_head to struct sock.
Would that be preferable?
Thanks,
-corey
next prev parent reply other threads:[~2008-09-25 19:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <48DB2925.2070908@poczta.onet.pl>
2008-09-24 17:28 ` [PATCH 1/1] Use RCU for the UDP hash lock Corey Minyard
2008-09-24 19:40 ` Stephen Hemminger
2008-09-24 20:46 ` Corey Minyard
2008-09-25 15:29 ` Paul E. McKenney
2008-09-25 15:34 ` Stephen Hemminger
2008-09-25 19:21 ` Corey Minyard [this message]
2008-09-25 20:34 ` Stephen Hemminger
2008-09-25 8:45 ` Jarek Poplawski
2008-09-25 19:14 ` Corey Minyard
2008-09-26 3:18 Corey Minyard
2008-09-26 4:09 ` Paul E. McKenney
2008-09-26 13:49 ` Corey Minyard
2008-09-26 19:50 ` Jarek Poplawski
2008-09-26 5:46 ` Jarek Poplawski
2008-09-26 13:37 ` Corey Minyard
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=48DBE4D3.9060809@acm.org \
--to=minyard@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=shemminger@vyatta.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).