From: Martin KaFai Lau <martin.lau@linux.dev>
To: Michal Luczaj <mhal@rbox.co>
Cc: Kuniyuki Iwashima <kuniyu@google.com>,
John Fastabend <john.fastabend@gmail.com>,
Jakub Sitnicki <jakub@cloudflare.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Willem de Bruijn <willemb@google.com>,
Cong Wang <cong.wang@bytedance.com>,
Alexei Starovoitov <ast@kernel.org>, Yonghong Song <yhs@fb.com>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf v2 3/4] bpf, sockmap: Adapt for the af_unix-specific lock
Date: Mon, 2 Mar 2026 17:51:18 -0800 [thread overview]
Message-ID: <f38608e1-4e85-4bc4-8872-c9ecf38e5d7e@linux.dev> (raw)
In-Reply-To: <1022fcaf-ca38-43d2-84cb-f66a504335e1@rbox.co>
On 2/24/26 7:28 AM, Michal Luczaj wrote:
> On 2/23/26 22:43, Martin KaFai Lau wrote:
>>
>> On 2/11/26 2:02 AM, Michal Luczaj wrote:
>>>> It should also be helpful to be consistent with tcp/udp iter and use
>>>> lock_sock() instead of lock_sock_fast() in bpf_iter_unix_seq_show().
>>> OK, I'll tweak that in v3.
>>
>> Hi, Michal. Are you planning to send v3 soon? I don't think the
>> sock_owned_by_user for the non-tracing prog needs to be addressed in the
>> same set.
>
> Yes, I'm working on it. Sorry for the delay, I'm taking my sweet time to
> come up with a selftest.
>
> I think I can neatly fit the sock_owned_by_user()-related stuff in this
> series, but let me know if you'd rather have it separately. Whichever way,
> I don't mind.
I think sock_owned_by_user() is not related to the AF_UNIX's sockmap
fix. If it is not, it's better to separate it. I think one thing at a
time is easier to review.
If they are related somewhat or it's easier to review them together, see
if it makes sense to structure them in a way such that the AF_UNIX's
sockmap-related fixes and tests are at the beginning of the patch set so
that they can be applied first if others need more discussion.
Regarding the "Keeping sparse annotations in
sock_map_sk_{acquire,release}() required some
hackery...". Maybe just remove the annotations?
[ btw, from commit 5b63d0ae94cc, the sparse support is removed and it
depends solely on clang now (?). If it is the case, what does clang do
on the "sock_or_unix_lock"? ]
next prev parent reply other threads:[~2026-03-03 1:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-07 14:34 [PATCH bpf v2 0/4] bpf, sockmap: Fix af_unix null-ptr-deref in proto update Michal Luczaj
2026-02-07 14:34 ` [PATCH bpf v2 1/4] bpf, sockmap: Annotate af_unix sock::sk_state data-races Michal Luczaj
2026-02-07 14:34 ` [PATCH bpf v2 2/4] bpf, sockmap: Use sock_map_sk_{acquire,release}() where open-coded Michal Luczaj
2026-02-07 14:34 ` [PATCH bpf v2 3/4] bpf, sockmap: Adapt for the af_unix-specific lock Michal Luczaj
2026-02-07 22:00 ` Kuniyuki Iwashima
2026-02-08 17:14 ` Michal Luczaj
2026-02-09 20:17 ` Martin KaFai Lau
2026-02-11 10:02 ` Michal Luczaj
2026-02-11 13:24 ` Michal Luczaj
2026-02-23 21:43 ` Martin KaFai Lau
2026-02-24 15:28 ` Michal Luczaj
2026-03-03 1:51 ` Martin KaFai Lau [this message]
2026-03-05 23:35 ` Michal Luczaj
2026-02-07 14:34 ` [PATCH bpf v2 4/4] selftests/bpf: Extend bpf_iter_unix to attempt deadlocking Michal Luczaj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f38608e1-4e85-4bc4-8872-c9ecf38e5d7e@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cong.wang@bytedance.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=horms@kernel.org \
--cc=jakub@cloudflare.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mhal@rbox.co \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=willemb@google.com \
--cc=yhs@fb.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox