[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <7216AFA7-24B9-4DCD-B3D5-AFDE739E7036@cmss.chinamobile.com>
Date: Wed, 27 Sep 2017 09:05:53 +0800
From: 严海双 <yanhaishuang@...s.chinamobile.com>
To: David Miller <davem@...emloft.net>
Cc: kuznet@....inr.ac.ru, edumazet@...gle.com, weiwan@...gle.com,
lucab@...ian.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/3] ipv4: Namespaceify tcp_fastopen_key knob
> On 2017年9月27日, at 上午2:18, David Miller <davem@...emloft.net> wrote:
>
> From: 严海双 <yanhaishuang@...s.chinamobile.com>
> Date: Tue, 26 Sep 2017 09:25:51 +0800
>
>>> On 2017年9月26日, at 上午7:24, David Miller <davem@...emloft.net> wrote:
>>>
>>> From: Haishuang Yan <yanhaishuang@...s.chinamobile.com>
>>> Date: Fri, 22 Sep 2017 21:48:43 +0800
>>>
>>>> @@ -9,13 +9,18 @@
>>>> #include <net/inetpeer.h>
>>>> #include <net/tcp.h>
>>>>
>>>> -struct tcp_fastopen_context __rcu *tcp_fastopen_ctx;
>>>> -
>>>> -static DEFINE_SPINLOCK(tcp_fastopen_ctx_lock);
>>>> -
>>>> -void tcp_fastopen_init_key_once(bool publish)
>>>> +void tcp_fastopen_init_key_once(struct net *net)
>>>
>>> Why did you remove the 'publish' logic from this function?
>>>
>>
>> I think this logic is not necessary now, in proc_tcp_fastopen_key, I have removed
>> tcp_fastopen_init_key_once(false) where the ‘publish’ is false:
>>
>> - /* Generate a dummy secret but don't publish it. This
>> - * is needed so we don't regenerate a new key on the
>> - * first invocation of tcp_fastopen_cookie_gen
>> - */
>> - tcp_fastopen_init_key_once(false);
>> - tcp_fastopen_reset_cipher(user_key, TCP_FASTOPEN_KEY_LENGTH);
>> + tcp_fastopen_reset_cipher(net, user_key, TCP_FASTOPEN_KEY_LENGTH);
>>
>> It said we don't regenerate a new key on first invocation of tcp_fastopen_cookie_gen,
>> but in tcp_fastopen_cookie_gen,it didn’t call tcp_fastopen_init_key_once since
>> from commit dfea2aa654243 (tcp: Do not call tcp_fastopen_reset_cipher from interrupt context):
>>
>> And in other places where call tcp_fastopen_init_key_once, the ‘publish’ is always true:
>
> Ok, this simplification seems legitimate.
>
> But it is unrelated to this namespacification. So it should be in a separate patch,
> and should be documented well in the commit message using the great explanation you
> gave to me above.
>
> Please respin this series, with this patch #2 split up into two changes.
>
> Thank you.
Okay, thanks David for advise. I will split the patch #2 in next commit.
Powered by blists - more mailing lists