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

[Fernando Fernandez Mancera <fmancera@suse.de>]

On 2/17/26 7:58 PM, Gerd Rausch wrote:
> 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.
>

I see, I don't really have a strong opinion here. Although, the solution 
at UEK seems a bit overkill to me. As RDS do not really need all the 
information that inet_getname() provides. It just needs the source port 
and it can be used without acquiring the lock (because it was already done).

The ideal solution to me would be the patch proposed here [1] + a 
comment on the shutdown path to remember the developer that acquiring a 
lock is needed to enable fan-out. Having said that, I cannot tell if it 
would be better to keep divergence of UEK and Upstream or be more 
efficient. I am leaving this dilemma to you and Allison and any other 
maintainer that would like to chime in.

Just let me know so I can a send a v2 of my proposed patch with a more 
detailed commit message and also a comment on the mentioned path.

[1] https://lore.kernel.org/netdev/20260216120804.14840-1-fmancera@suse.de/

Thanks,
Fernando.

> Thanks,
> 
>    Gerd
> 
>