From: sashiko-bot@kernel.org
To: "Anil Kaushik" <anilkaushikwireless@gmail.com>, mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v14 3/6] mptcp: pm: in-kernel: add the subflow-retries limit
Date: Sun, 01 Nov 2026 07:27:53 +0000 [thread overview]
Message-ID: <sashiko-outbox-192308@kernel.org> (raw)
In-Reply-To: <20261101072051.3853492-4-anilkaushikwireless@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] mptcp: pm: mixed limit validation in mptcp_pm_nl_set_limits_doit()
--
commit a548b0ce8ac5f215ffb57499482e189af72f45ad
Author: Anil Kaushik <anilkaushikwireless@gmail.com>
mptcp: pm: in-kernel: add the subflow-retries limit
This commit adds a new subflow-retries limit to the in-kernel path manager
for configuring the number of SYN retries when re-creating a subflow after
a timeout, and exposes it in struct mptcp_info.
> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
> index d3014bf57bf3c..7fb4c78743409 100644
> --- a/net/mptcp/pm_kernel.c
> +++ b/net/mptcp/pm_kernel.c
[ ... ]
> @@ -1419,7 +1428,8 @@ static int parse_limit(struct genl_info *info, int id, unsigned int *limit)
> int mptcp_pm_nl_set_limits_doit(struct sk_buff *skb, struct genl_info *info)
> {
> struct pm_nl_pernet *pernet = genl_info_pm_nl(info);
> - unsigned int rcv_addrs, subflows;
> + unsigned int rcv_addrs, subflows, retries;
> + struct nlattr *attr;
> int ret;
>
> spin_lock_bh(&pernet->lock);
> @@ -1433,8 +1443,13 @@ int mptcp_pm_nl_set_limits_doit(struct sk_buff *skb, struct genl_info *info)
> if (ret)
> goto unlock;
>
> + /* the maximum, MAX_TCP_SYNCNT, is checked by the policy */
> + attr = info->attrs[MPTCP_PM_ATTR_SUBFLOW_RETRIES];
> + retries = nla_get_u32_default(attr, pernet->limit_subflow_retries);
[Severity: Low]
As reported by Matthieu Baerts on v7 [1], mptcp_pm_nl_set_limits_doit() in
net/mptcp/pm_kernel.c now mixes two different limit validation approaches:
MPTCP_PM_ATTR_RCV_ADD_ADDRS and MPTCP_PM_ATTR_SUBFLOWS are checked via
parse_limit(), while MPTCP_PM_ATTR_SUBFLOW_RETRIES relies on the netlink
policy and nla_get_u32_default().
Should a prerequisite patch convert the existing two limits to use netlink
policy validation and nla_get_u32_default() as well (or should this new
limit continue using parse_limit()) so all limits in
mptcp_pm_nl_set_limits_doit() are handled uniformly?
[1] https://lore.kernel.org/r/56679372-0ae6-43bf-b0fa-a6b853a1b68c@kernel.org
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261101072051.3853492-1-anilkaushikwireless@gmail.com?part=3
next prev parent reply other threads:[~2026-11-01 7:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 7:20 [PATCH mptcp-next v14 0/6] mptcp: pm: in-kernel: retry subflows closed after an error Anil Kaushik
2026-11-01 7:20 ` [PATCH mptcp-next v14 1/6] selftests: mptcp: connect: retry write() on EAGAIN Anil Kaushik
2026-11-01 7:20 ` [PATCH mptcp-next v14 2/6] netlink: specs: mptcp: add the subflow-retries attribute Anil Kaushik
2026-11-02 21:38 ` netdev-bot+sashiko
2026-11-01 7:20 ` [PATCH mptcp-next v14 3/6] mptcp: pm: in-kernel: add the subflow-retries limit Anil Kaushik
2026-11-01 7:27 ` sashiko-bot [this message]
2026-11-01 7:20 ` [PATCH mptcp-next v14 4/6] mptcp: pm: in-kernel: retry subflows closed after an error Anil Kaushik
2026-11-01 7:49 ` sashiko-bot
2026-11-01 7:56 ` Anil Kaushik
2026-11-01 7:20 ` [PATCH mptcp-next v14 5/6] selftests: mptcp: pm_nl_ctl: support the subflow-retries limit Anil Kaushik
2026-11-01 7:20 ` [PATCH mptcp-next v14 6/6] selftests: mptcp: join: validate subflow retry after link failure Anil Kaushik
2026-11-02 21:38 ` netdev-bot+sashiko
2026-11-01 9:27 ` [PATCH mptcp-next v14 0/6] mptcp: pm: in-kernel: retry subflows closed after an error MPTCP CI
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=sashiko-outbox-192308@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anilkaushikwireless@gmail.com \
--cc=mptcp@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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.