[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4jsnhbf2sjzdwdg6i3nzdp7skpcdpuujxr2ggt5dcaqwufh3bf@urvrkhaulgsy>
Date: Fri, 28 Feb 2025 12:49:49 +0800
From: Jiayuan Chen <jiayuan.chen@...ux.dev>
To: Martin KaFai Lau <martin.lau@...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 Thu, Feb 27, 2025 at 03:04:26PM -0800, Martin KaFai Lau wrote:
> 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?
Thanks, Martin.
It seems that this issue has existed since sockmap supported unix.
I'll find the corresponding commit as the Fixes tag.
Powered by blists - more mailing lists