Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030997AbdI0BGD convert rfc822-to-8bit (ORCPT ); Tue, 26 Sep 2017 21:06:03 -0400 Received: from cmccmta3.chinamobile.com ([221.176.66.81]:19293 "EHLO cmccmta3.chinamobile.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967091AbdI0BGB (ORCPT ); Tue, 26 Sep 2017 21:06:01 -0400 X-RM-TRANSID: 2eea59caf9737b6-65b53 X-RM-SPAM-FLAG: 00000000 X-RM-TRANSID: 2ee259caf970156-ea3c8 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH v4 2/3] ipv4: Namespaceify tcp_fastopen_key knob From: =?gb2312?B?0c+6o8ur?= In-Reply-To: <20170926.111851.1172660559080066162.davem@davemloft.net> Date: Wed, 27 Sep 2017 09:05:53 +0800 Cc: kuznet@ms2.inr.ac.ru, edumazet@google.com, weiwan@google.com, lucab@debian.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <7216AFA7-24B9-4DCD-B3D5-AFDE739E7036@cmss.chinamobile.com> References: <1506088124-12650-2-git-send-email-yanhaishuang@cmss.chinamobile.com> <20170925.162445.234890912211240693.davem@davemloft.net> <20170926.111851.1172660559080066162.davem@davemloft.net> To: David Miller X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2072 Lines: 56 > On 2017??9??27??, at ????2:18, David Miller wrote: > > From: ?Ϻ?˫ > Date: Tue, 26 Sep 2017 09:25:51 +0800 > >>> On 2017??9??26??, at ????7:24, David Miller wrote: >>> >>> From: Haishuang Yan >>> Date: Fri, 22 Sep 2017 21:48:43 +0800 >>> >>>> @@ -9,13 +9,18 @@ >>>> #include >>>> #include >>>> >>>> -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.