From: Matthieu Baerts <matttbe@kernel.org>
To: Geliang Tang <geliang@kernel.org>, mptcp@lists.linux.dev
Cc: Geliang Tang <tanggeliang@kylinos.cn>
Subject: Re: [PATCH mptcp-next v8 06/12] mptcp: pm: in-kernel: register mptcp_pm_kernel
Date: Wed, 5 Mar 2025 12:51:13 +0100 [thread overview]
Message-ID: <02398941-0bb7-4156-a286-536db728c411@kernel.org> (raw)
In-Reply-To: <818c00e2242d2f76604c6d70176ab6fa94d7eaa5.1741088339.git.tanggeliang@kylinos.cn>
Hi Geliang,
On 04/03/2025 12:40, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
>
> This patch defines the original in-kernel netlink path manager as a
> new struct mptcp_pm_ops named "mptcp_pm_kernel", and register it in
> mptcp_pm_kernel_register().
>
> This mptcp_pm_ops will be skipped in mptcp_pm_unregister().
>
> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> ---
> net/mptcp/pm.c | 4 ++++
> net/mptcp/pm_kernel.c | 26 ++++++++++++++++++++++++++
> net/mptcp/protocol.h | 3 +++
> 3 files changed, 33 insertions(+)
>
> diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
> index a2b210873b23..28ea8bdaa8b0 100644
> --- a/net/mptcp/pm.c
> +++ b/net/mptcp/pm.c
> @@ -1076,6 +1076,10 @@ int mptcp_pm_register(struct mptcp_pm_ops *pm)
>
> void mptcp_pm_unregister(struct mptcp_pm_ops *pm)
> {
> + /* skip unregistering the default path manager */
Please see my questions from v7: why this skip?
When looking at this, I can understand that we don't want to unregister
built-in modules and the default one, but:
- When are we going to that? mptcp_pm_unregister() is still unused in
this series.
- Why would we want to unregister the userspace PM as well?
It makes sense to have an exception for the default one, but it feels
like we should simply not try to unregister the in-kernel ones. In other
words, there is probably no need to have such exceptions because
mptcp_pm_unregister() should never be called with the built-in PMs. In
this case, maybe we could add a WARN_ON_ONCE()?
if (WARN_ON_ONCE(pm == &mptcp_pm_kernel))
return;
(or something else if we need to catch the userspace PM as well, e.g.
pm->built_in, but that should not be needed)
> + if (pm == &mptcp_pm_kernel)
> + return;
> +
> spin_lock(&mptcp_pm_list_lock);
> list_del_rcu(&pm->list);
> spin_unlock(&mptcp_pm_list_lock);
> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
> index 806a9b5b3c07..e6a1aef738a8 100644
> --- a/net/mptcp/pm_kernel.c
> +++ b/net/mptcp/pm_kernel.c
> @@ -1398,8 +1398,34 @@ static struct pernet_operations mptcp_pm_pernet_ops = {
> .size = sizeof(struct pm_nl_pernet),
> };
>
> +static void mptcp_pm_nl_initialize(struct mptcp_sock *msk)
> +{
> + bool subflows_allowed = !!mptcp_pm_get_subflows_max(msk);
> + struct mptcp_pm_data *pm = &msk->pm;
> +
> + /* pm->work_pending must be only be set to 'true' when
> + * pm is the default path manager
> + */
> + WRITE_ONCE(pm->work_pending,
> + (!!mptcp_pm_get_local_addr_max(msk) &&
> + subflows_allowed) ||
> + !!mptcp_pm_get_add_addr_signal_max(msk));
> + WRITE_ONCE(pm->accept_addr,
> + !!mptcp_pm_get_add_addr_accept_max(msk) &&
> + subflows_allowed);
> + WRITE_ONCE(pm->accept_subflow, subflows_allowed);
It might feel clearer to add this helper in patch 8 ("mptcp: pm:
initialize and release mptcp_pm_ops"), to understand you are moving
existing code here.
If you do that, then maybe better to squash the existing patches 6
("mptcp: pm: in-kernel: register mptcp_pm_kernel") and 7 ("mptcp: pm:
userspace: register mptcp_pm_userspace"), no?
mptcp: pm: register in-kernel and userspace PM
> +}
> +
> +struct mptcp_pm_ops mptcp_pm_kernel = {
> + .init = mptcp_pm_nl_initialize,
> + .name = "kernel",
> + .owner = THIS_MODULE,
> +};
> +
> void __init mptcp_pm_kernel_register(void)
> {
> if (register_pernet_subsys(&mptcp_pm_pernet_ops) < 0)
> panic("Failed to register MPTCP PM pernet subsystem.\n");
> +
> + mptcp_pm_register(&mptcp_pm_kernel);
> }
> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> index 246b44db9775..f700cb55bf49 100644
> --- a/net/mptcp/protocol.h
> +++ b/net/mptcp/protocol.h
> @@ -1050,6 +1050,9 @@ int mptcp_pm_remove_addr(struct mptcp_sock *msk, const struct mptcp_rm_list *rm_
> void mptcp_pm_remove_addr_entry(struct mptcp_sock *msk,
> struct mptcp_pm_addr_entry *entry);
>
> +/* the default path manager, used in mptcp_pm_unregister */
(to be adapted if it is no longer used there. Or: mptcp_pm_initialize)
Or maybe better: it could be exported in patch 8 ("mptcp: pm: initialize
and release mptcp_pm_ops").
> +extern struct mptcp_pm_ops mptcp_pm_kernel;
> +
> struct mptcp_pm_ops *mptcp_pm_find(const char *name);
> int mptcp_pm_validate(struct mptcp_pm_ops *pm);
> int mptcp_pm_register(struct mptcp_pm_ops *pm);
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
next prev parent reply other threads:[~2025-03-05 11:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 11:40 [PATCH mptcp-next v8 00/12] BPF path manager, part 5 Geliang Tang
2025-03-04 11:40 ` [PATCH mptcp-next v8 01/12] mptcp: pm: define struct mptcp_pm_ops Geliang Tang
2025-03-05 11:42 ` Matthieu Baerts
2025-03-04 11:40 ` [PATCH mptcp-next v8 02/12] mptcp: sysctl: new sysctl to set path manager by name Geliang Tang
2025-03-04 11:40 ` [PATCH mptcp-next v8 03/12] mptcp: sysctl: map pm_type to path_manager Geliang Tang
2025-03-05 11:45 ` Matthieu Baerts
2025-03-04 11:40 ` [PATCH mptcp-next v8 04/12] mptcp: sysctl: map path_manager to pm_type Geliang Tang
2025-03-05 11:48 ` Matthieu Baerts
2025-03-04 11:40 ` [PATCH mptcp-next v8 05/12] mptcp: sysctl: add available_path_managers Geliang Tang
2025-03-04 11:40 ` [PATCH mptcp-next v8 06/12] mptcp: pm: in-kernel: register mptcp_pm_kernel Geliang Tang
2025-03-05 1:35 ` Geliang Tang
2025-03-05 9:11 ` Matthieu Baerts
2025-03-05 9:14 ` Geliang Tang
2025-03-05 9:22 ` Matthieu Baerts
2025-03-05 9:29 ` Geliang Tang
2025-03-05 11:51 ` Matthieu Baerts [this message]
2025-03-06 11:09 ` Geliang Tang
2025-03-06 11:27 ` Matthieu Baerts
2025-03-04 11:40 ` [PATCH mptcp-next v8 07/12] mptcp: pm: userspace: register mptcp_pm_userspace Geliang Tang
2025-03-05 11:53 ` Matthieu Baerts
2025-03-04 11:40 ` [PATCH mptcp-next v8 08/12] mptcp: pm: initialize and release mptcp_pm_ops Geliang Tang
2025-03-05 11:57 ` Matthieu Baerts
2025-03-04 11:40 ` [PATCH mptcp-next v8 09/12] mptcp: pm: add get_local_id() interface Geliang Tang
2025-03-04 11:40 ` [PATCH mptcp-next v8 10/12] mptcp: pm: add get_priority() interface Geliang Tang
2025-03-04 11:40 ` [PATCH mptcp-next v8 11/12] selftests: mptcp: add pm_type mapping tests Geliang Tang
2025-03-05 11:58 ` Matthieu Baerts
2025-03-04 11:40 ` [PATCH mptcp-next v8 12/12] selftests: mptcp: add path_manager sysctl test Geliang Tang
2025-03-05 11:59 ` Matthieu Baerts
2025-03-05 11:41 ` [PATCH mptcp-next v8 00/12] BPF path manager, part 5 Matthieu Baerts
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=02398941-0bb7-4156-a286-536db728c411@kernel.org \
--to=matttbe@kernel.org \
--cc=geliang@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=tanggeliang@kylinos.cn \
/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.