Re: [PATCH mptcp-next v3 1/3] mptcp: propagate RECVERR sockopts to subflows

[Matthieu Baerts <matttbe@kernel.org>]

Hi Paolo,

Thank you for the review!

On 22/04/2026 10:05, Paolo Abeni wrote:
> On 4/22/26 12:33 AM, David Carlier wrote:
>> Propagate IP_RECVERR/IP_RECVERR_RFC4884 and
>> IPV6_RECVERR/IPV6_RECVERR_RFC4884 from the MPTCP socket to
>> existing and future subflows.
>>
>> Apply the matching sockopt according to the subflow family so mixed-
>> family subflows stay aligned with the parent socket configuration,
>> including disable-time errqueue purge semantics.

(...)

>> +static int mptcp_setsockopt_v6_recverr(struct mptcp_sock *msk, int optname,
>> +				       sockptr_t optval, unsigned int optlen)
>> +{
>> +	struct mptcp_subflow_context *subflow;
>> +	struct sock *sk = (struct sock *)msk;
>> +	int ret;
>> +
>> +	ret = ipv6_setsockopt(sk, SOL_IPV6, optname, optval, optlen);
>> +	if (ret)
>> +		return ret;
>> +
>> +	lock_sock(sk);
>> +	sockopt_seq_inc(msk);
>> +	mptcp_for_each_subflow(msk, subflow) {
>> +		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
>> +		bool rfc4884 = optname == IPV6_RECVERR_RFC4884;
>> +
>> +		ret = mptcp_subflow_set_recverr(sk, ssk, rfc4884);
> 
> The above looks a bit overcomplicated?!? It looks like you could
> leverage mptcp_setsockopt_all_sf() in  and drop the
> mptcp_subflow_set_recverr() and mptcp_recverr_enabled() helpers.
> 
> @Mattbe: it's not clear to me why mptcp_setsockopt_all_sf() does not
> call sockopt_seq_inc(msk) or sync the setsockopt_seq, possibly an
> unrelated bug?

Oh yes, good catch! And a lock of the sk (msk) before iterating the
subflows, no? Same in __mptcp_setsockopt_set_val()?

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