netdev - Re: [PATCH net-next v7 1/7] net: introduce rstreason to detect why the RST is sent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <70184416-344f-4e03-bfb7-0626ff845fe0@kernel.org>
Date: Mon, 22 Apr 2024 12:05:39 +0200
From: Matthieu Baerts <matttbe@...nel.org>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: edumazet@...gle.com, dsahern@...nel.org, martineau@...nel.org,
 geliang@...nel.org, kuba@...nel.org, pabeni@...hat.com, davem@...emloft.net,
 rostedt@...dmis.org, mhiramat@...nel.org, mathieu.desnoyers@...icios.com,
 atenart@...nel.org, mptcp@...ts.linux.dev, netdev@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next v7 1/7] net: introduce rstreason to detect why
 the RST is sent

On 22/04/2024 11:17, Jason Xing wrote:> On Mon, Apr 22, 2024 at 4:47 PM
Matthieu Baerts <matttbe@...nel.org> wrote:
>> On 22/04/2024 05:01, Jason Xing wrote:
>>> From: Jason Xing <kernelxing@...cent.com>

(...)

>>> diff --git a/include/net/rstreason.h b/include/net/rstreason.h
>>> new file mode 100644
>>> index 000000000000..c57bc5413c17
>>> --- /dev/null
>>> +++ b/include/net/rstreason.h
>>> @@ -0,0 +1,144 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>> +
>>> +#ifndef _LINUX_RSTREASON_H
>>> +#define _LINUX_RSTREASON_H
>>> +#include <net/dropreason-core.h>
>>> +#include <uapi/linux/mptcp.h>
>>> +
>>> +#define DEFINE_RST_REASON(FN, FNe)   \
>>> +     FN(MPTCP_RST_EUNSPEC)           \
>>> +     FN(MPTCP_RST_EMPTCP)            \
>>> +     FN(MPTCP_RST_ERESOURCE)         \
>>> +     FN(MPTCP_RST_EPROHIBIT)         \
>>> +     FN(MPTCP_RST_EWQ2BIG)           \
>>> +     FN(MPTCP_RST_EBADPERF)          \
>>> +     FN(MPTCP_RST_EMIDDLEBOX)        \
>>
>> Small detail: should it not make more sense to put the ones linked to
>> MPTCP at the end? I mean I guess MPTCP should be treated in second
>> priority: CONFIG_MPTCP could not be set, and the ones linked to TCP
>> should be more frequent, etc.
> 
> Do you mean that I need to adjust the order: 1) tcp reasons first, 2)
> independent reasons, 3) mptcp reasons ?

Correct, it looks like it is a more "natural" order.

> Reasonable. I will do it :)

Thanks!

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.