From: Eric Dumazet <eric.dumazet@gmail.com>
To: William Allen Simpson <william.allen.simpson@gmail.com>
Cc: paulmck@linux.vnet.ibm.com,
Linux Kernel Developers <linux-kernel@vger.kernel.org>,
Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie
Date: Thu, 05 Nov 2009 14:19:28 +0100 [thread overview]
Message-ID: <4AF2D0E0.1040903@gmail.com> (raw)
In-Reply-To: <4AF2C266.1010603@gmail.com>
William Allen Simpson a écrit :
> Paul E. McKenney wrote:
>> On Tue, Nov 03, 2009 at 05:38:10PM -0500, William Allen Simpson wrote:
>>> Documentation/RCU/checklist.txt #7 says:
>>>
>>> One exception to this rule: rcu_read_lock() and rcu_read_unlock()
>>> may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh()
>>> in cases where local bottom halves are already known to be
>>> disabled, for example, in irq or softirq context. Commenting
>>> such cases is a must, of course! And the jury is still out on
>>> whether the increased speed is worth it.
>>
>> I strongly suggest using the matching primitives unless you have a
>> really strong reason not to.
>>
> Eric gave contrary advice. But he also suggested (in an earlier message)
> clearing the secrets with a timer, which could be a separate context --
> although much later in time.
>
> As you suggest, I'll use the _bh suffix everywhere until every i is dotted
> and t is crossed. Then, check for efficiency later after thorough
> analysis by experts such as yourself.
>
> This code will be hit on every SYN and SYNACK that has a cookie option.
> But it's just prior to a CPU intensive sha_transform -- in comparison,
> it's trivial.
>
I think you misunderstood my advice ;)
In the same function, you *cannot* use both variants like your last patch did :
spin_lock(&tcp_secret_locker);
...
rcu_read_lock_bh();
memcpy(&xvp->cookie_bakery[0],
&rcu_dereference(tcp_secret_generating)->secrets[0],
sizeof(tcp_secret_generating->secrets));
rcu_read_unlock_bh();
Reasoning is :
If you need _bh() for the rcu_read_lock_bh(), thats because you know
soft irq can happen anytime (they are not masked).
Then you also need _bh for the spin_lock() call, or risk deadlock.
-> tcp_cookie_generator();
spin_lock();
-> interrupt -> softirq -> SYN frame received -> tcp_cookie_generator() -> spin_lock(); hang
Your choices are :
------------------
1) Caller took care of disabling softirqs (or is only called from softirq handler),
then _bh suffixes are not necessary in tcp_cookie_generator().
-> spin_lock() & rcu_read_lock();
2) You dont know what called you (process context or softirq context)
-> you MUST use _bh prefixes on spin_lock_bh() & rcu_read_lock_bh();
next prev parent reply other threads:[~2009-11-05 13:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-30 11:00 [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie William Allen Simpson
2009-10-30 18:11 ` William Allen Simpson
2009-11-01 13:01 ` William Allen Simpson
2009-11-01 18:03 ` Eric Dumazet
2009-11-02 10:39 ` William Allen Simpson
2009-11-02 10:50 ` David Miller
2009-11-02 10:56 ` Eric Dumazet
2009-11-02 12:36 ` William Allen Simpson
2009-11-02 13:16 ` Eric Dumazet
2009-11-02 17:21 ` William Allen Simpson
2009-11-02 17:42 ` Eric Dumazet
2009-11-03 22:38 ` William Allen Simpson
2009-11-03 23:03 ` Eric Dumazet
2009-11-04 21:48 ` Paul E. McKenney
2009-11-05 12:17 ` William Allen Simpson
2009-11-05 12:45 ` William Allen Simpson
2009-11-05 13:34 ` Eric Dumazet
2009-11-05 13:19 ` Eric Dumazet [this message]
2009-11-05 19:44 ` William Allen Simpson
2009-11-05 14:59 ` Paul E. McKenney
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=4AF2D0E0.1040903@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=william.allen.simpson@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).