netdev - Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if

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: <alpine.DEB.2.21.1803211605350.3754@nanos.tec.linutronix.de>
Date:   Wed, 21 Mar 2018 16:11:36 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Richard Cochran <richardcochran@...il.com>
cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Jesus Sanchez-Palencia <jesus.sanchez-palencia@...el.com>,
        netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
        jiri@...nulli.us, vinicius.gomes@...el.com,
        anna-maria@...utronix.de, henrik@...tad.us,
        John Stultz <john.stultz@...aro.org>, levi.pearson@...man.com,
        edumazet@...gle.com, willemb@...gle.com, mlichvar@...hat.com
Subject: Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late
 params

On Wed, 21 Mar 2018, Richard Cochran wrote:

@Intel: I removed intel-wired-lan@ as I have absolutely zero interest in
	the moderation spam from that list. Can you please either get rid
	of this moderation nonsense or stop CC'ing that list when posting
	to lkml/netdev?

> On Wed, Mar 21, 2018 at 01:58:51PM +0100, Thomas Gleixner wrote:
> > Errm. No. There is no way to support fd based clocks or one of the CPU
> > time/process time based clocks for this.
> 
> Why not?
>  
> If the we have HW offloading, then the transmit time had better be
> expressed in terms of the MAC's internal clock.  Otherwise we would
> need to translate between a kernel clock and the MAC clock, but that
> is expensive (eg over PCIe) and silly (because in a typical use case
> the MAC will already be synchronized to the network time).

Sure, but you CANNOT use a clockid for that because there is NONE.

The mac clock is exposed via a dynamic posix clock and can only be
referenced via a file descriptor.

The qdisc setup does fd = open(...) and hands that in as clockid. Later the
application does fd = open(...) and uses that as clockid for tagging the
messages.

What the heck guarantees that both the setup and the application will get
the same fd number?

Exactly nothing. So any attempt to use the filedescriptor number as clockid
is broken by definition.

Thanks,

	tglx