[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84f25c32-1aa6-42d6-a5b1-efce822bfcd6@linux.dev>
Date: Thu, 27 Feb 2025 15:04:26 -0800
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: cong.wang@...edance.com, john.fastabend@...il.com, jakub@...udflare.com,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, horms@...nel.org, andrii@...nel.org, eddyz87@...il.com,
mykolal@...com, ast@...nel.org, daniel@...earbox.net, song@...nel.org,
yonghong.song@...ux.dev, kpsingh@...nel.org, sdf@...ichev.me,
haoluo@...gle.com, jolsa@...nel.org, shuah@...nel.org, mhal@...x.co,
sgarzare@...hat.com, netdev@...r.kernel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
mrpre@....com, syzbot+dd90a702f518e0eac072@...kaller.appspotmail.com
Subject: Re: [PATCH bpf-next v1 1/3] bpf, sockmap: avoid using sk_socket after
free
On 2/26/25 5:22 AM, Jiayuan Chen wrote:
> Use RCU lock to protect sk_socket, preventing concurrent close and release
> by another thread.
>
> Because TCP/UDP are already within a relatively large critical section:
> '''
> ip_local_deliver_finish
> rcu_read_lock
> ip_protocol_deliver_rcu
> tcp_rcv/udp_rcv
> rcu_read_unlock
> '''
>
> Adding rcu_read_{un}lock() at the entrance and exit of sk_data_ready
> will not increase performance overhead.
Can it use a Fixes tag?
Powered by blists - more mailing lists