On 6/3/26 04:16, Oleg Sevostyanov wrote:
Thank you for the comments.
You are right about the reproducer. I mistakenly included it despite
saying
that I was not including it. I apologize for the inconsistency.
I also agree that taking lock_sock(sk) earlier in tls_sk_proto_close()
looks
like the natural mitigation direction, given that the function takes it
unconditionally anyway. I will bring this point to the kernel/networking
maintainers when discussing a fix.
The pattern of deferring a lock that will be unconditionally acquired
would be a good target for a broader locking audit.
Having the lock functions return a dummy value so that acquiring a lock
can be the first executable step, as part of local variable
initialization, is a more radical solution to this category of problem.
The "unused variable" problem could be resolved by making that return
value a "lock cookie" that will be later passed to the corresponding
unlock function.
-- Jacob
