All of lore.kernel.org
 help / color / mirror / Atom feed
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 v2 14/36] mptcp: refactor dump_addr with id bitmap
Date: Mon, 4 Nov 2024 18:18:44 +0100	[thread overview]
Message-ID: <783c5e16-e040-4094-be19-9f64695164f3@kernel.org> (raw)
In-Reply-To: <10ff1d448f136c4f180af819762becb1beeff69b.1729588019.git.tanggeliang@kylinos.cn>

Hi Geliang,

(I only see this patch now, and better understand the reaction you had
in [1])

[1]
https://lore.kernel.org/mptcp/20241025-mptcp-pm-lookup_addr_rcu-v2-2-1478f6c4b205@kernel.org/T/#u

On 22/10/2024 11:14, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> Subject: mptcp: refactor dump_addr with id bitmap

Be careful when you use this 'refactor' word: if I'm not mistaken,
generally it means that you modified the code around to ease integration
of a new feature or the maintenance, but without changing the behaviour
or fixing anything. Here, yes you moved the code around, but to fix
something, to change the behaviour.

> With the help of get_addr(), we can refactor dump_addr() interfaces to
> reuse send_nlmsg code between the netlink PM and userspace PM.
> 
> The current dump_addr() flow looks like this:
> 
> 	lock();
> 	for_each_entry(entry)
> 		send_nlmsg(entry);
> 	unlock();
> 
> After holding the lock, get every entry by walking the address list,
> send each one looply, and finally release the lock.
> 
> This set changes the process by copying the address list to an id
> bitmap while holding the lock, then release the lock immediately.
> After that, without locking, walking the copied id bitmap to get
> every copy of entry by using get_addr(), and send each one looply.
> 
> This patch is the first part of refactoring dump_addr().
> 
> Without changing the position of the locks, the dump process is split
> into two parts: copying the ID bitmap first, and then traversing the
> ID bitmap, use lookup_addr_by_id() to get the entry, then send each
> one through nlmsg:
> 
> 	lock();
> 	for_each_entry(entry)
> 		set_bit(bitmap);
> 	for_each_bit(bitmap) {
> 		entry = lookup_addr_by_id();
> 		send_nlmsg(entry);
> 	}
> 	unlock();

After the discussions we had on [1], do you still think this
modification is needed? Do you do that for the consistency, to unify the
code, or because you require this for the BPF PM?

If it is for the consistency, please check the last question from Mat on
[1]:

> Do you see a reason that bitmap/addr_list inconsistencies would cause issues?

Also, with the modification here (mainly with the next patch), can we
not have more inconsistencies? The bitmap can point to ID that have been
freed/should not be read, no?

> 
> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> ---
>  net/mptcp/pm_netlink.c   |  6 ++++-
>  net/mptcp/pm_userspace.c | 54 +++++++++++++++++++++++++++++-----------
>  2 files changed, 45 insertions(+), 15 deletions(-)
> 
> diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
> index c030a79cd1dd..4cee5942200c 100644
> --- a/net/mptcp/pm_netlink.c
> +++ b/net/mptcp/pm_netlink.c
> @@ -1869,16 +1869,20 @@ static int mptcp_pm_nl_dump_addr(struct sk_buff *msg,
>  {
>  	struct net *net = sock_net(msg->sk);
>  	struct mptcp_pm_addr_entry *entry;
> +	struct mptcp_id_bitmap *bitmap;
>  	struct pm_nl_pernet *pernet;
>  	int id = cb->args[0];
>  	void *hdr;
>  	int i;
>  
> +	bitmap = (struct mptcp_id_bitmap *)cb->ctx;
>  	pernet = pm_nl_get_pernet(net);
>  
>  	spin_lock_bh(&pernet->lock);
> +	if (!id)
> +		bitmap_copy(bitmap->map, pernet->id_bitmap.map, MPTCP_PM_MAX_ADDR_ID + 1);
>  	for (i = id; i < MPTCP_PM_MAX_ADDR_ID + 1; i++) {
> -		if (test_bit(i, pernet->id_bitmap.map)) {
> +		if (test_bit(i, bitmap->map)) {
>  			entry = __lookup_addr_by_id(pernet, i);
>  			if (!entry)
>  				break;
> diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
> index cb4f2a174d0d..237383cfd12e 100644
> --- a/net/mptcp/pm_userspace.c
> +++ b/net/mptcp/pm_userspace.c
> @@ -583,6 +583,21 @@ int mptcp_userspace_pm_set_flags(struct sk_buff *skb, struct genl_info *info)
>  	return ret;
>  }
>  
> +static int mptcp_userspace_pm_set_bitmap(struct mptcp_sock *msk,
> +					 struct mptcp_id_bitmap *bitmap)
> +{
> +	struct mptcp_pm_addr_entry *entry;
> +
> +	mptcp_for_each_address(msk, entry) {
> +		if (test_bit(entry->addr.id, bitmap->map))
> +			continue;
> +
> +		__set_bit(entry->addr.id, bitmap->map);

It is not clear to me what you are trying to do here. Is this helper
(the name is not clear) only called the first time, then when the bitmap
is reset, no? Then why do you need the 'test_bit'?

> +	}
> +
> +	return 0;
> +}
> +
>  int mptcp_userspace_pm_dump_addr(struct sk_buff *msg,
>  				 struct netlink_callback *cb)
>  {
> @@ -590,9 +605,11 @@ int mptcp_userspace_pm_dump_addr(struct sk_buff *msg,
>  	struct mptcp_pm_addr_entry *entry;
>  	struct mptcp_id_bitmap *bitmap;
>  	struct mptcp_sock *msk;
> +	int id = cb->args[0];
>  	int ret = -EINVAL;
>  	struct sock *sk;
>  	void *hdr;
> +	int i;
>  
>  	bitmap = (struct mptcp_id_bitmap *)cb->ctx;
>  
> @@ -604,24 +621,33 @@ int mptcp_userspace_pm_dump_addr(struct sk_buff *msg,
>  
>  	lock_sock(sk);
>  	spin_lock_bh(&msk->pm.lock);
> -	mptcp_for_each_address(msk, entry) {
> -		if (test_bit(entry->addr.id, bitmap->map))
> -			continue;
> +	if (!id)
> +		ret = mptcp_userspace_pm_set_bitmap(msk, bitmap);
> +	for (i = id; i < MPTCP_PM_MAX_ADDR_ID + 1; i++) {
> +		if (test_bit(i, bitmap->map)) {
> +			entry = mptcp_userspace_pm_lookup_addr_by_id(msk, i);
> +			if (!entry)
> +				break;
> +
> +			if (id && entry->addr.id <= id)
> +				continue;
>  
> -		hdr = genlmsg_put(msg, NETLINK_CB(cb->skb).portid,
> -				  cb->nlh->nlmsg_seq, &mptcp_genl_family,
> -				  NLM_F_MULTI, MPTCP_PM_CMD_GET_ADDR);
> -		if (!hdr)
> -			break;
> +			hdr = genlmsg_put(msg, NETLINK_CB(cb->skb).portid,
> +					  cb->nlh->nlmsg_seq, &mptcp_genl_family,
> +					  NLM_F_MULTI, MPTCP_PM_CMD_GET_ADDR);
> +			if (!hdr)
> +				break;
>  
> -		if (mptcp_nl_fill_addr(msg, entry) < 0) {
> -			genlmsg_cancel(msg, hdr);
> -			break;
> -		}
> +			if (mptcp_nl_fill_addr(msg, entry) < 0) {
> +				genlmsg_cancel(msg, hdr);
> +				break;
> +			}
>  
> -		__set_bit(entry->addr.id, bitmap->map);
> -		genlmsg_end(msg, hdr);
> +			id = entry->addr.id;
> +			genlmsg_end(msg, hdr);
> +		}
>  	}
> +	cb->args[0] = id;
>  	spin_unlock_bh(&msk->pm.lock);
>  	release_sock(sk);
>  	ret = msg->len;

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


  reply	other threads:[~2024-11-04 17:18 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-22  9:14 [PATCH mptcp-next v2 00/36] BPF path manager Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 01/36] mptcp: drop else in mptcp_pm_addr_families_match Geliang Tang
2024-10-22 17:01   ` Matthieu Baerts
2024-10-23  9:53     ` Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 02/36] mptcp: use __lookup_addr in pm_netlink Geliang Tang
2024-10-22 17:09   ` Matthieu Baerts
2024-10-23  9:59     ` Geliang Tang
2024-10-23 10:03       ` Matthieu Baerts
2024-10-23 10:06         ` Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 03/36] mptcp: add mptcp_for_each_address macros Geliang Tang
2024-10-30 18:20   ` Matthieu Baerts
2024-10-31  7:55     ` Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 04/36] mptcp: use sock_kfree_s instead of kfree Geliang Tang
2024-10-30 18:21   ` Matthieu Baerts
2024-10-31  7:43     ` Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 05/36] mptcp: add lookup_addr for userspace pm Geliang Tang
2024-10-30 18:21   ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 06/36] mptcp: add mptcp_userspace_pm_get_sock helper Geliang Tang
2024-10-30 18:23   ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 07/36] mptcp: make three pm wrappers static Geliang Tang
2024-10-30 18:31   ` Matthieu Baerts
2024-10-31  7:58     ` Geliang Tang
2024-10-31 16:33       ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 08/36] mptcp: drop skb parameter of get_addr Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 09/36] mptcp: add id parameter for get_addr Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 10/36] mptcp: add addr " Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 11/36] mptcp: reuse sending nlmsg code in get_addr Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 12/36] mptcp: change info of get_addr as const Geliang Tang
2024-10-31 18:41   ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 13/36] mptcp: add struct mptcp_id_bitmap Geliang Tang
2024-10-31 18:45   ` Matthieu Baerts
2024-11-04  9:12     ` Geliang Tang
2024-11-04 10:16       ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 14/36] mptcp: refactor dump_addr with id bitmap Geliang Tang
2024-11-04 17:18   ` Matthieu Baerts [this message]
2024-10-22  9:14 ` [PATCH mptcp-next v2 15/36] mptcp: refactor dump_addr with get_addr Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 16/36] mptcp: reuse sending nlmsg code in dump_addr Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 17/36] mptcp: update local address flags when setting it Geliang Tang
2024-11-04 18:20   ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 18/36] mptcp: change rem type of set_flags Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 19/36] mptcp: drop skb parameter " Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 20/36] mptcp: add loc and rem for set_flags Geliang Tang
2024-11-04 18:36   ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 21/36] mptcp: update address type of get_local_id Geliang Tang
2024-11-04 18:48   ` Matthieu Baerts
2024-11-07  7:35     ` Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 22/36] mptcp: change is_backup interfaces as get_flags Geliang Tang
2024-11-04 18:55   ` Matthieu Baerts
2025-01-14  9:27     ` Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 23/36] mptcp: drop struct mptcp_pm_local Geliang Tang
2024-11-04 19:08   ` Matthieu Baerts
2024-11-07  7:29     ` Geliang Tang
2024-11-07 10:00       ` Matthieu Baerts
2024-11-07 10:19         ` Geliang Tang
2024-11-10  4:32           ` Geliang Tang
2024-11-27  6:17             ` Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 24/36] mptcp: drop struct mptcp_pm_add_entry Geliang Tang
2024-11-04 19:13   ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 25/36] mptcp: change local type of subflow_destroy Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 26/36] mptcp: hold pm lock when deleting entry Geliang Tang
2024-11-04 19:17   ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 27/36] mptcp: rename mptcp_pm_remove_addrs Geliang Tang
2024-11-04 19:24   ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 28/36] mptcp: drop free_list for deleting entries Geliang Tang
2024-11-04 19:27   ` Matthieu Baerts
2024-10-22  9:14 ` [PATCH mptcp-next v2 29/36] mptcp: define struct mptcp_pm_ops Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 30/36] mptcp: implement userspace pm interfaces Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 31/36] mptcp: register default userspace pm Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 32/36] bpf: Add mptcp path manager struct_ops Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 33/36] bpf: Register mptcp struct_ops kfunc set Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 34/36] Squash to "bpf: Export mptcp packet scheduler helpers" Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 35/36] selftests/bpf: Add mptcp userspace pm subtest Geliang Tang
2024-10-22  9:14 ` [PATCH mptcp-next v2 36/36] selftests/bpf: Add mptcp bpf path manager subtest Geliang Tang
2024-10-22 10:12 ` [PATCH mptcp-next v2 00/36] BPF path manager MPTCP CI
2024-10-22 10:24 ` MPTCP CI
2024-11-04 19:31 ` Matthieu Baerts
2024-11-05 10:12   ` Geliang Tang

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=783c5e16-e040-4094-be19-9f64695164f3@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.