Subject: Re: [PATCH bpf v2 3/4] bpf, sockmap: Adapt for the af_unix-specific lock

From: Martin KaFai Lau <[email-masked]>
Date: Mon, 2 Mar 2026 17:51:18 -0800

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"? ]