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 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:   Tue, 07 Jul 2020 20:56:41 +0300
From:   Sergey Organov <sorganov@...il.com>
To:     Vladimir Oltean <olteanv@...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

Vladimir Oltean <olteanv@...il.com> writes:

> 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?

It won't. Supposedly it'd force clock (that doesn't tick by default and
stays at 0) to start ticking.

If the ability to stop the clock is in fact useful (I don't immediately
see how it could), and how to do it if it is, is a separate issue. I'd
then expect clock_stop(clkid), or clock_settime(clkid, NULL) to do the
job.

Thanks,
-- Sergey