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]

Date:   Fri, 3 Dec 2021 10:55:04 +0800
From:   Hangbin Liu <liuhangbin@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
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, Dec 02, 2021 at 06:59:23AM -0800, Jakub Kicinski wrote:
> 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.

Thanks for the explanation. I understand what you mean now.
> 
> 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?

Yes, this makes sense for me. I check this and try post a patch next week.

Thanks
Hangbin