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

[Gerd Rausch]

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