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

[Allison Henderson]

On Tue, 2026-02-17 at 21:26 +0100, Fernando Fernandez Mancera wrote:
> 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://urldefense.com/v3/__https://github.com/oracle/linux-uek/commit/a94abc444c487__;!!ACWV5N9M2RV99hQ!IpOznnWqw_v-wi4Ns7OEC3SCjCoKB-QhIWR5lVP4pEWqzy8lj4TQveGITLmDWUwVeiILCQoO5CfEn8NZL-GEx9w$ 
> > 
> > The commit under discussion here originally came from:
> > https://urldefense.com/v3/__https://github.com/oracle/linux-uek/commit/ebf71f5b6c29c__;!!ACWV5N9M2RV99hQ!IpOznnWqw_v-wi4Ns7OEC3SCjCoKB-QhIWR5lVP4pEWqzy8lj4TQveGITLmDWUwVeiILCQoO5CfEn8NZXhL1owk$ 
> > 
> > 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://urldefense.com/v3/__https://lore.kernel.org/netdev/20260216120804.14840-1-fmancera@xxxxxxx/__;!!ACWV5N9M2RV99hQ!IpOznnWqw_v-wi4Ns7OEC3SCjCoKB-QhIWR5lVP4pEWqzy8lj4TQveGITLmDWUwVeiILCQoO5CfEn8NZpQsJl9A$ 
> 
> Thanks,
> Fernando.

Hi all,

Lets move forward with Fernandos fix here.  I will withdraw "net/rds: Use proper peer port number even when not
connected" from the fan out improvement series since it conflicts.  It looks like "fix recursive lock in
rds_tcp_conn_slots_available" eliminates the recursive lock issue entirely, so that will take care of the syzbot issue
for now and then I can move forward with the rest of the fan out patches in the next merge window.

Fernando, please go ahead and send your v2 with the extra comment details.

Thanks all,
Allison

> 
> > Thanks,
> > 
> >    Gerd
> > 
> > 
>