March 20, 2025 at 08:34, "Cong Wang" xiyou.wangcong@gmail.com wrote:
On Mon, Mar 17, 2025 at 05:22:55PM +0800, Jiayuan Chen wrote:
There are potential concurrency issues, as shown below.
'''
CPU0 CPU1
sk_psock_verdict_data_ready:
socket *sock = sk->sk_socket
if (!sock) return
close(fd):
...
ops->release()
if (!sock->ops) return
sock->ops = NULL
rcu_call(sock)
free(sock)
READ_ONCE(sock->ops)
^
use 'sock' after free
'''
RCU is not applicable to Unix sockets read path, because the Unix socket
implementation itself assumes it's always in process context and heavily
uses mutex_lock, so, we can't call read_skb within rcu lock.
Hm, I guess the RCU work in sk_psock_drop() does not work for Unix
domain sockets either?
Thanks.
Although the Unix domain socket framework does not use RCU locks, the entire sockmap process protects access to psock via RCU: ''' rcu_read_lock(); psock = sk_psock(sk_other); if (psock) { ... } rcu_read_unlock(); // `sk_psock_drop` will not execute until the unlock '''
Therefore, I believe there are no issues with the psock operations here.
Thanks~