Re: [PATCH net] bonding: only set speed/duplex to unknown, if getting speed failed

[Nikolay Aleksandrov]

On 30/01/2026 17:38, Jay Vosburgh wrote:
> Hangbin Liu <liuhangbin@xxxxxxxxx> wrote:
>
> > On Fri, Jan 30, 2026 at 12:19:04PM +0100, Thomas Bogendoerfer wrote:
> > > bond_update_speed_duplex() first set speed/duplex to unknown and
> > > then asks slave driver for current speed/duplex. Since getting
> > > speed/duplex might take longer there is a race, where this false state
> > > is visible by /proc/net/bonding. With commit 691b2bf14946 ("bonding:
> >
> > The patch looks good to me. But based on your description, I don't think
> > the fixes tag is correct.
>
> 	Agreed on both points; I suspect the origin of the race window
> is:
>
> commit e9fe8efeeae11f19bb6fafd6153ec77deaeb4b83
> Author: Nikolay Aleksandrov <razor@xxxxxxxxxxxxx>
> Date:   Tue Sep 9 23:17:01 2014 +0200
>
>      bonding: procfs: clean bond->lock usage and use RCU
>
> 	as this patch converted some locking in the procfs logic to be
> solely RCU.
>
> 	-J

I don't think so. :-)
bond_update_speed_duplex() can sleep and has never been called with the write_lock.
See for example:
 commit 876254ae2758
 Author: Veaceslav Falico <vfalico@xxxxxxxxxx>
 Date:   Tue Mar 12 06:31:32 2013 +0000

    bonding: don't call update_speed_duplex() under spinlocks

It seems to me that behaviour has always been there, regardless of having a
read_lock in procfs or not.

Cheers,
 Nik