Bug 92481 - Recent patches to ntp.c and time.c prevent correction by ptpd2
Summary: Recent patches to ntp.c and time.c prevent correction by ptpd2
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Timers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: ARM Linux
: P1 high
Assignee: john stultz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-02 04:10 UTC by George Joseph
Modified: 2016-08-17 17:49 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.18.5
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Patch to fix false positives on 32bit systems (1.51 KB, patch)
2015-02-02 19:08 UTC, john stultz
Details | Diff

Description George Joseph 2015-02-02 04:10:07 UTC
Hardware: imx6q-cubox-i  ( 6 units )

After upgrading from 3.18.4 to 3.18.5, ptpd2 in slave mode was pegging at -500ppm slew rate (the max) while trying to keep the system clock in sync.  On 3.18.4, the drift correction was always about -50ppm.

With the following 2 commits reverted, ptpd2 is back to about a 50ppm drift correction.

time: settimeofday: Validate the values of tv from usercommit 5e5aeb4367b450a28f447f6d5ab57d8f2ab16a5f upstream.
Verify that the frequency value from userspace is valid and makes sense.

time: adjtimex: Validate the ADJ_FREQUENCY values
commit 5e5aeb4367b450a28f447f6d5ab57d8f2ab16a5f upstream.
Verify that the frequency value from userspace is valid and makes sense.
Comment 1 john stultz 2015-02-02 17:50:20 UTC
Thanks for the report!

Could you confirm that it is only the "time: adjtimex: Validate the ADJ_FREQUENCY values" patch that needs to be reverted?

thanks
-john
Comment 2 john stultz 2015-02-02 19:08:29 UTC
Created attachment 165631 [details]
Patch to fix false positives on 32bit systems

Can you try this patch ontop of the affected kernel to validate it resolves the issue for you?
Comment 3 George Joseph 2015-02-02 19:17:59 UTC
(In reply to john stultz from comment #2)
> Created attachment 165631 [details]
> Patch to fix false positives on 32bit systems
> 
> Can you try this patch ontop of the affected kernel to validate it resolves
> the issue for you?

Funny, I was just checking the value of (LONG_MIN / PPM_SCALE) and (LONG_MIN / PPM_SCALE) and they were evaluating to -32 and 32. :)

So, yep... using LLONG gives the correct -140737488355 to 140737488355 range.

Thanks for looking at this so quickly!
Comment 4 George Joseph 2015-02-02 19:18:38 UTC
Oh, and just to confirm the unstated...  ptpd is now able to maintain the clock.
Comment 5 john stultz 2015-02-02 20:07:20 UTC
Willing to provide a Tested-by: tag?
Comment 6 George Joseph 2015-02-02 20:34:15 UTC
(In reply to john stultz from comment #5)
> Willing to provide a Tested-by: tag?
Sure...

Tested-by: George Joseph <george.joseph@fairview5.com>
Comment 7 john stultz 2015-02-02 20:43:37 UTC
Thanks! I'll be sending the patch out later today.
Comment 8 john stultz 2015-02-19 18:02:11 UTC
Apologies for this being a bit slow to make it upstream. The patch has made it to the -tip tree, and hopefully will be submitted to Linus soon.
Comment 9 embedded 2015-02-28 22:57:46 UTC
Backporting the patch into 3.10.67 and above solves the "adjtime: invalid argument" problem with openntpd.
Comment 10 john stultz 2015-08-31 18:35:42 UTC
Patch has been merged for awhile. Closing this out. Let me know if there are any continued issues.

Note You need to log in before you can comment on or make changes to this bug.