linux-kernel - Re: [PATCH 3/5] net: fec: initialize clock with 0 rather than current kernel time

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 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:   Tue, 7 Jul 2020 20:12:33 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Sergey Organov <sorganov@...il.com>
Cc:     richardcochran@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Fugang Duan <fugang.duan@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH  3/5] net: fec: initialize clock with 0 rather than
 current kernel time

On Tue, Jul 07, 2020 at 08:09:07PM +0300, Sergey Organov wrote:
> Vladimir Oltean <olteanv@...il.com> writes:
> 
> > On Tue, Jul 07, 2020 at 07:07:08PM +0300, Sergey Organov wrote:
> >> Vladimir Oltean <olteanv@...il.com> writes:
> >> >
> >> > What do you mean 'no ticking', and what do you mean by 'non-initialized
> >> > clock' exactly? I don't know if the fec driver is special in any way, do
> >> > you mean that multiple runs of $(phc_ctl /dev/ptp0 get) from user space
> >> > all return 0? That is not at all what is to be expected, I think. The
> >> > PHC is always ticking. Its time is increasing.
> >> 
> >> That's how it is right now. My point is that it likely shouldn't. Why is
> >> it ticking when nobody needs it? Does it draw more power due to that?
> >> 
> >> > What would be that initialization procedure that makes it tick, and
> >> > who is doing it (and when)?
> >> 
> >> The user space code that cares, obviously. Most probably some PTP stack
> >> daemon. I'd say that any set clock time ioctl() should start the clock,
> >> or yet another ioctl() that enables/disables the clock, whatever.
> >> 
> >
> > That ioctl doesn't exist, at least not in PTP land. This also addresses
> > your previous point.
> 
> struct timespec ts;
> ...
> clock_settime(clkid, &ts)
> 
> That's the starting point of my own code, and I bet it's there in PTP
> for Linux, as well as in PTPD, as I fail to see how it could possibly
> work without it.
> 

This won't stop it from ticking, which is what we were talking about,
will it?

Thanks,
-Vladimir