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

[Fernando Fernandez Mancera]

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@xxxxxxx/

Thanks,
Fernando.

> Thanks,
>
>    Gerd