All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>, mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-net v2 2/3] mptcp: pm: lockless list traversal
Date: Tue, 5 Nov 2024 19:21:46 +0100	[thread overview]
Message-ID: <053267b3-a22e-4c3d-833b-55edda46ba25@redhat.com> (raw)
In-Reply-To: <20241025-mptcp-pm-lookup_addr_rcu-v2-2-1478f6c4b205@kernel.org>

On 10/25/24 11:32, Matthieu Baerts (NGI0) wrote:
> @@ -2060,17 +2062,17 @@ int mptcp_pm_nl_set_flags(struct sk_buff *skb, struct genl_info *info)
>  	if (addr.flags & MPTCP_PM_ADDR_FLAG_BACKUP)
>  		bkup = 1;
>  
> -	spin_lock_bh(&pernet->lock);
> -	entry = lookup_by_id ? __lookup_addr_by_id(pernet, addr.addr.id) :
> -			       __lookup_addr(pernet, &addr.addr);
> +	rcu_read_lock();
> +	entry = lookup_by_id ? __lookup_addr_by_id_rcu(pernet, addr.addr.id) :
> +			       __lookup_addr_rcu(pernet, &addr.addr);
>  	if (!entry) {
> -		spin_unlock_bh(&pernet->lock);
> +		rcu_read_unlock();
>  		GENL_SET_ERR_MSG(info, "address not found");
>  		return -EINVAL;
>  	}
>  	if ((addr.flags & MPTCP_PM_ADDR_FLAG_FULLMESH) &&
>  	    (entry->flags & MPTCP_PM_ADDR_FLAG_SIGNAL)) {
> -		spin_unlock_bh(&pernet->lock);
> +		rcu_read_unlock();
>  		GENL_SET_ERR_MSG(info, "invalid addr flags");
>  		return -EINVAL;
>  	}
> @@ -2078,7 +2080,7 @@ int mptcp_pm_nl_set_flags(struct sk_buff *skb, struct genl_info *info)
>  	changed = (addr.flags ^ entry->flags) & mask;
>  	entry->flags = (entry->flags & ~mask) | (addr.flags & mask);
>  	addr = *entry;
> -	spin_unlock_bh(&pernet->lock);
> +	rcu_read_unlock();
>  
>  	mptcp_nl_set_flags(net, &addr.addr, bkup, changed);
>  	return 0;
> 

I think we must retain the lock in this function, otherwise we could
end-up with an unexpected flag combination.

i.e. set_flag(MPTCP_PM_ADDR_FLAG_FULLMESH) and
set_flag(MPTCP_PM_ADDR_FLAG_SIGNAL) run concurrently on CPU1 and CPU2.
entry->flags could end-up having a single bit set instead of both, if
both CPUs read the entry before the other would store the new value.

I don't think _ONCE() annotations will be enough to avoid such thing
without a lock.

Cheers,

Paolo


  parent reply	other threads:[~2024-11-05 18:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25  9:32 [PATCH mptcp-net v2 0/3] mptcp: pm: use _rcu variant under rcu_read_lock Matthieu Baerts (NGI0)
2024-10-25  9:32 ` [PATCH mptcp-net v2 1/3] " Matthieu Baerts (NGI0)
2024-10-25  9:32 ` [PATCH mptcp-net v2 2/3] mptcp: pm: lockless list traversal Matthieu Baerts (NGI0)
2024-10-25 14:25   ` Geliang Tang
2024-10-25 15:26     ` Matthieu Baerts
2024-10-28  2:08       ` Geliang Tang
2024-10-28 11:48         ` Matthieu Baerts
2024-10-29  8:43           ` Geliang Tang
2024-10-31 23:24             ` Mat Martineau
2024-11-06 16:03               ` Matthieu Baerts
2024-10-25 15:17   ` Matthieu Baerts
2024-10-31 22:14     ` Mat Martineau
2024-11-05 18:21   ` Paolo Abeni [this message]
2024-11-06 16:23     ` Matthieu Baerts
2024-10-25  9:32 ` [PATCH mptcp-net v2 3/3] mptcp: pm: avoid code duplication to lookup endp Matthieu Baerts (NGI0)
2024-10-25 10:37   ` Geliang Tang
2024-10-25 10:44     ` Matthieu Baerts
2024-10-25 10:47     ` Geliang Tang
2024-10-25 10:49 ` [PATCH mptcp-net v2 0/3] mptcp: pm: use _rcu variant under rcu_read_lock 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=053267b3-a22e-4c3d-833b-55edda46ba25@redhat.com \
    --to=pabeni@redhat.com \
    --cc=matttbe@kernel.org \
    --cc=mptcp@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.