Re: [syzbot] [net?] possible deadlock in inet6_getname

[Gerd Rausch <gerd.rausch@oracle.com>]

Hi,

+Allison

On 2026-02-17 09:28, Gerd Rausch wrote:
> On 2026-02-17 09:19, Fernando Fernandez Mancera wrote:
>> On 2/17/26 6:13 PM, Gerd Rausch wrote:
>>> If someone were to change the code to pass in "fan_out == true"
>>> from a context not already holding a socket lock,
>>> would they remember to change rds_tcp_conn_slots_available()
>>> to acquire that lock?
>>>
>>
>> Usually kernel requires the developer to understand when do they need to acquire a lock or not.
>> Anyway, what would you suggest? To check whether we have acquired the lock or not and do it conditionally?> 
> 
> Something along those lines.
> 
> Either a "_locked" version of "conn_slots_available" function pointer,
> a parameter, or a check.
> 
> What you suggested is fine though for the immediate syzbot need.
> 

FWIW, in UEK (the modified Linux kernel that Oracle uses),
this issue reported by syzbot was addressed differently:

https://github.com/oracle/linux-uek/commit/a94abc444c487

The commit under discussion here originally came from:
https://github.com/oracle/linux-uek/commit/ebf71f5b6c29c

and pre-dates:
9dfc685e0262 ("inet: remove races in inet{6}_getname()")

which is why UEK didn't have this deadlock issue reported by syszbot.

If the objective is to keep divergence of UEK and Upstream to a minimum,
it may be worthwhile to consider adopting the same fix we carry in UEK.

Thanks,

   Gerd