netdev - Re: [PATCH net-next] bond: pass get_ts_info and SIOC[SG]HWTSTAMP ioctl to active device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211202065923.7fc5aa8f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 2 Dec 2021 06:59:23 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Hangbin Liu <liuhangbin@...il.com>
Cc:     netdev@...r.kernel.org, Jay Vosburgh <j.vosburgh@...il.com>,
        Veaceslav Falico <vfalico@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>, davem@...emloft.net,
        Richard Cochran <richardcochran@...il.com>,
        Miroslav Lichvar <mlichvar@...hat.com>
Subject: Re: [PATCH net-next] bond: pass get_ts_info and SIOC[SG]HWTSTAMP
 ioctl to active device

On Thu, 2 Dec 2021 11:04:40 +0800 Hangbin Liu wrote:
> > Yeah, there should be some form of well understood indication in the
> > uAPI telling the user space daemon that the PHC may get swapped on the
> > interface, and a reliable notification which indicates PHC change.
> > There is a number of user space daemons out there, fixing linuxptp does
> > not mean other user space won't be broken/surprised/angry.  
> 
> This is a RFE, I don't think this patch will affect the current user space as
> the new topology is not supported before. i.e. no user space tool will configure
> PTP based on bond or vlan over bond. And even the user space use other ways to
> get bond's active interface, e.g. via netlink message. It still not affected
> and could keep using the old way. So I think this patch should be safe.
> 
> Did I miss any thing?

User can point their PTP daemon at any interface. Since bond now
supports the uAPI the user will be blissfully unaware that their
configuration will break if failover happens.

We can't expect every user and every PTP daemon to magically understand
the implicit quirks of the drivers. Quirks which are not even
documented.

What I'm saying is that we should have a new bit in the uAPI that
tells us that the user space can deal with unstable PHC idx and reject
the request forwarding in bond if that bit is not set. We have a flags
field in hwtstamp_config which should fit the bill. Make sense?

> > What notification is linuxptp listening on, SETLINK?  
> 
> Currently, I send RTM_GETLINK message on bond and listening on
> RTM_NEWLINK message to get IFLA_LINKINFO info.
> 
> But for the new VLAN over bond topology. I haven't figure out a good solution.
> Maybe I can just check the active interface status. When it get down,
> do get_ts_info once again to get the new active interface on the VLAN over
> bond interface. I need some testing.