From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: Jianguo Wu <wujianguo106@163.com>
Cc: mptcp@lists.linux.dev, pabeni@redhat.com, fw@strlen.de
Subject: Re: [PATCH v5 0/4] Fix some mptcp syncookie process bugs
Date: Tue, 22 Jun 2021 17:07:25 -0700 (PDT) [thread overview]
Message-ID: <58edc7e8-652-c5c8-5ee6-878981c6d7b2@linux.intel.com> (raw)
In-Reply-To: <d3c1f32b-806a-bf19-d6a2-324b80d4c387@163.com>
[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]
On Mon, 21 Jun 2021, Jianguo Wu wrote:
> Hi Mat,
>
> On 2021/6/19 8:26, Mat Martineau wrote:
>> On Wed, 16 Jun 2021, wujianguo106@163.com wrote:
>>
>>> From: Jianguo Wu <wujianguo@chinatelecom.cn>
>>>
>>> v4->v5:
>>> patch1: no changes
>>> patch2: no changes
>>> patch3: no changes
>>> patch4: add comment
>>
>> Hi Jianguo -
>>
>> One other thing that's helpful for reviewers on the list is to use the patch prefixes listed at https://github.com/multipath-tcp/mptcp_net-next/wiki/Patch-prefixes
>> when emailing patches to mptcp@lists.linux.dev
>>
>
> Thanks for your reminding!
>
>> For example, if these patches are intended for net-next they should be sent with [PATCH mptcp-next] in the subject line, or for the net tree they should have [PATCH mptcp-net]. If you're unsure where the patches belong, please ask!
>>
>
> and this patchset should use [PATCH mptcp-next]?
I think these look like mptcp-net patches, especially considering the risk
of double-free in patch 2.
For patch 4 I'm not sure if that would be best for net-next. Is it an
optimization or fixing a crash / error / warning?
-Mat
>
>> Thanks,
>>
>> Mat
>>
>>
>>>
>>> v3->v4:
>>> patch1: using seq and sport/dport for hashing, and ignore network headers altogether,
>>> as suggest by Florian
>>> patch2: no changes
>>> patch3: no changes
>>> patch4: no changes
>>>
>>> v2->v3:
>>> patch1: directly use inet6_ehashfn() for IPv6
>>> patch2: no changes
>>> patch3: no changes
>>> patch4: add Fixes tag.
>>>
>>> v1->v2:
>>> patch1: handle ipv6 sockets/addresses,
>>> always use 4-tuple drived hash and never look at skb->hash
>>> patch2: no changes
>>> patch3: split into 2 patches.
>>> patch4: new added.
>>>
>>> Jianguo Wu (4):
>>> mptcp: fix warning in __skb_flow_dissect() when do syn cookie for
>>> subflow join
>>> mptcp: remove redundant req destruct in subflow_check_req()
>>> mptcp: fix syncookie process if mptcp can not_accept new subflow
>>> mptcp: avoid processing packet if a subflow reset
>>>
>>> net/mptcp/options.c | 6 ++++++
>>> net/mptcp/subflow.c | 11 +++--------
>>> net/mptcp/syncookies.c | 16 +++++++++++++++-
>>> 3 files changed, 24 insertions(+), 9 deletions(-)
>>>
>>> --
??>> 1.8.3.1
>>>
>>>
>>>
>>
>> --
>> Mat Martineau
>> Intel
>
>
--
Mat Martineau
Intel
prev parent reply other threads:[~2021-06-23 0:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-16 10:49 [PATCH v5 0/4] Fix some mptcp syncookie process bugs wujianguo106
2021-06-16 10:49 ` [PATCH v5 1/4] mptcp: fix warning in __skb_flow_dissect() when do syn cookie for subflow join wujianguo106
2021-06-18 22:40 ` Mat Martineau
2021-06-21 6:14 ` Jianguo Wu
2021-06-21 10:09 ` Jianguo Wu
2021-06-22 23:38 ` Mat Martineau
2021-06-16 10:49 ` [PATCH v5 2/4] mptcp: remove redundant req destruct in subflow_check_req() wujianguo106
2021-06-16 10:49 ` [PATCH v5 3/4] mptcp: fix syncookie process if mptcp can not_accept new subflow wujianguo106
2021-06-18 23:19 ` Mat Martineau
2021-06-21 6:24 ` Jianguo Wu
2021-06-24 2:08 ` Jianguo Wu
2021-06-24 22:36 ` Mat Martineau
2021-06-16 10:49 ` [PATCH v5 4/4] mptcp: avoid processing packet if a subflow reset wujianguo106
2021-06-19 0:19 ` Mat Martineau
2021-06-21 6:35 ` Jianguo Wu
2021-06-23 0:00 ` Mat Martineau
2021-06-23 9:48 ` Paolo Abeni
2021-06-24 1:57 ` Jianguo Wu
2021-06-24 10:02 ` Paolo Abeni
2021-06-24 22:38 ` Mat Martineau
2021-06-25 0:51 ` Jianguo Wu
2021-06-19 0:26 ` [PATCH v5 0/4] Fix some mptcp syncookie process bugs Mat Martineau
2021-06-21 6:39 ` Jianguo Wu
2021-06-23 0:07 ` Mat Martineau [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=58edc7e8-652-c5c8-5ee6-878981c6d7b2@linux.intel.com \
--to=mathew.j.martineau@linux.intel.com \
--cc=fw@strlen.de \
--cc=mptcp@lists.linux.dev \
--cc=pabeni@redhat.com \
--cc=wujianguo106@163.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.