Re: [PATCH net-next v2] net: add SO_BYPASS_RFS to exclude a socket from RFS and aRFS

[Vitaly Zuevsky <vitaly.zuevsky@gcore.com>]

On 09/11/2026 20:45, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue to consider:
> - [Medium] net: race in sk_setsockopt() deleting RFS flow before setting
>    sk_bypass_rfs
> It also noticed 1 related pre-existing issue this patch does not
> introduce:
> - [Medium] net: file descriptor leak in sk_getsockopt() [1]
> --
> 
> commit 0bb55ec9420355430d450dec603d8adf895ff281
> Author: Vitaly Zuevsky <vitaly.zuevsky@gcore.com>
> 
> net: add SO_BYPASS_RFS to exclude a socket from RFS and aRFS
> 
> This commit adds the SO_BYPASS_RFS boolean socket option and a skc_bypass_rfs
> bit in struct sock_common to exclude a socket from RFS and aRFS flow recording
> and deletion.
> 
>> diff --git a/net/core/sock.c b/net/core/sock.c
>> index e2401d735c5a7..00808217aebf1 100644
>> --- a/net/core/sock.c
>> +++ b/net/core/sock.c
> [ ... ]
>> @@ -1597,6 +1598,14 @@ int sk_setsockopt(struct sock *sk, int level, int optname,
>>   		reuseport_update_incoming_cpu(sk, val);
>>   		break;
>>   
>> +#ifdef CONFIG_RPS
>> +	case SO_BYPASS_RFS:
>> +		if (valbool)
>> +			sock_rps_delete_flow(sk);
>> +		sk->sk_bypass_rfs = valbool;
>> +		break;
>> +#endif
>> +
>>   	case SO_CNX_ADVICE:
>>   		if (val == 1)
>>   			dst_negative_advice(sk);
> 
> [Severity: Medium]
> Can a concurrent receive or send re-record the flow between
> sock_rps_delete_flow() and setting sk->sk_bypass_rfs?
> 
> Callers such as inet_recvmsg() invoke sock_rps_record_flow() without
> holding the socket lock:
> 
> CPU0                              CPU1
> sk_setsockopt(SO_BYPASS_RFS, 1)
>    sock_rps_delete_flow(sk)
>      _sock_rps_delete_flow(sk)
>                                    inet_recvmsg()
>                                      sock_rps_record_flow(sk)
>                                        /* sk->sk_bypass_rfs is still 0 */
>                                        _sock_rps_record_flow(sk)  <-- re-records flow
>    sk->sk_bypass_rfs = 1;
> 
> Once sk->sk_bypass_rfs is set, sock_rps_delete_flow() returns early, so
> the re-recorded entry stays in rps_sock_flow_table while SO_BYPASS_RFS is
> enabled and is not cleared when the socket closes.  Setting
> sk->sk_bypass_rfs before calling _sock_rps_delete_flow() would avoid
> leaving a stale entry if a concurrent reader races with setsockopt().

The record path is lockless by design and the table holds hints; a 
recvmsg() racing with the setsockopt() can leave one, which is tolerated 
like any other stale entry. Reordering narrows race-window at a cost of 
dropping the wrapper, consider:

sk->sk_bypass_rfs = valbool;
if (valbool) _sock_rps_delete_flow(sk);

|CPU0: setsockopt       |CPU1: recvmsg
                         |CPU1: test bit -> 0
|CPU0: bit = 1          |CPU1: preemted
|CPU0: delete slot      |CPU1: preemted
                         |CPU1: record   -> hint written