From: Thomas Gleixner
> Sent: 05 February 2021 17:34
>
> On Wed, Jan 20 2021 at 10:51, Yejune Deng wrote:
> > In pps_fill_timex(), use memset and offsetof instead of '= 0'.
> >
> > Signed-off-by: Yejune Deng
> > ---
> > kernel/time/ntp.c | 13 +
> > 1 file changed, 5 insertions(+),
On Tue, Jan 26, 2021 at 6:48 AM Geert Uytterhoeven
wrote:
>
> The bug fixed by commit e3fab2f3de081e98 ("ntp: Fix RTC synchronization
> on 32-bit platforms") revealed an underlying issue: RTC synchronization
> may happen anytime, even while the system is partially suspended
On Wed, Jan 20 2021 at 10:51, Yejune Deng wrote:
> In pps_fill_timex(), use memset and offsetof instead of '= 0'.
>
> Signed-off-by: Yejune Deng
> ---
> kernel/time/ntp.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
Committer: Thomas Gleixner
CommitterDate: Fri, 05 Feb 2021 18:03:13 +01:00
ntp: Use freezable workqueue for RTC synchronization
The bug fixed by commit e3fab2f3de081e98 ("ntp: Fix RTC synchronization on
32-bit platforms") revealed an underlying issue: RTC synchronization may
happ
The bug fixed by commit e3fab2f3de081e98 ("ntp: Fix RTC synchronization
on 32-bit platforms") revealed an underlying issue: RTC synchronization
may happen anytime, even while the system is partially suspended.
On systems where the RTC is connected to an I2C bus, the I2C bus
controller m
Hi Yejune,
url:
https://github.com/0day-ci/linux/commits/Yejune-Deng/ntp-use-memset-and-offsetof-init/20210120-110830
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
3cabca87b329cbcbdf295be0094adbd72c7b1f67
config: i386-randconfig-m021-20210120 (attached as .config
In pps_fill_timex(), use memset and offsetof instead of '= 0'.
Signed-off-by: Yejune Deng
---
kernel/time/ntp.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 87389b9e21ab..3416c0381104 100644
--- a/kernel/time/ntp.c
Committer: Thomas Gleixner
CommitterDate: Tue, 12 Jan 2021 21:13:01 +01:00
ntp: Fix RTC synchronization on 32-bit platforms
Due to an integer overflow, RTC synchronization now happens every 2s
instead of the intended 11 minutes. Fix this by forcing 64-bit
arithmetic for the sync period
On Mon, Jan 11, 2021 at 11:40 AM Geert Uytterhoeven
wrote:
> Due to an integer overflow, RTC synchronization now happens every 2s
> instead of the intended 11 minutes. Fix this by forcing 64-bit
> arithmetic for the sync period calculation.
>
> Fixes: c9e6189fb03123a7 (&qu
Hi Thomas,
On Mon, Jan 11, 2021 at 11:12 AM Thomas Gleixner wrote:
> On Tue, Dec 29 2020 at 20:41, Geert Uytterhoeven wrote:
> >> Reported-by: Miroslav Lichvar
> >> Signed-off-by: Thomas Gleixner
> >
> > Thanks for your patch, which is now commit c9e6189
Due to an integer overflow, RTC synchronization now happens every 2s
instead of the intended 11 minutes. Fix this by forcing 64-bit
arithmetic for the sync period calculation.
Fixes: c9e6189fb03123a7 ("ntp: Make the RTC synchronization more reliable")
Signed-off-by: Geert Uy
On Tue, Dec 29 2020 at 20:41, Geert Uytterhoeven wrote:
> Hi Thomas,
>> Reported-by: Miroslav Lichvar
>> Signed-off-by: Thomas Gleixner
>
> Thanks for your patch, which is now commit c9e6189fb03123a7 ("ntp: Make
> the RTC synchronization more reliable").
Hi Thomas,
On Sun, Dec 6, 2020 at 11:10 PM Thomas Gleixner wrote:
> Miroslav reported that the periodic RTC synchronization in the NTP code
> fails more often than not to hit the specified update window.
>
> The reason is that the code uses delayed_work to schedule the update w
Committer: Ingo Molnar
CommitterDate: Sun, 13 Dec 2020 10:16:31 +01:00
ntp: Fix prototype in the !CONFIG_GENERIC_CMOS_UPDATE case
In the !CONFIG_GENERIC_CMOS_UPDATE case the update_persistent_clock64() function
gets defined as a stub in ntp.c - make the prototype in
conditional
Committer: Ingo Molnar
CommitterDate: Sat, 12 Dec 2020 18:35:12 +01:00
ntp: Fix build error
Signed-off-by: Ingo Molnar
---
include/linux/timekeeping.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 7f7e4a3..929d3f3 100644
Committer: Thomas Gleixner
CommitterDate: Fri, 11 Dec 2020 10:40:53 +01:00
ntp: Make the RTC sync offset less obscure
The current RTC set_offset_nsec value is not really intuitive to
understand.
tsched twrite(t2.tv_sec - 1) t2 (seconds increment)
The offset is calculated from
Committer: Thomas Gleixner
CommitterDate: Fri, 11 Dec 2020 10:40:53 +01:00
ntp: Consolidate the RTC update implementation
The code for the legacy RTC and the RTC class based update are pretty much
the same. Consolidate the common parts into one function and just invoke
the actual setter functions
Committer: Thomas Gleixner
CommitterDate: Fri, 11 Dec 2020 10:40:52 +01:00
ntp: Make the RTC synchronization more reliable
Miroslav reported that the periodic RTC synchronization in the NTP code
fails more often than not to hit the specified update window.
The reason is that the code uses
Committer: Thomas Gleixner
CommitterDate: Fri, 11 Dec 2020 10:40:52 +01:00
ntp, rtc: Move rtc_set_ntp_time() to ntp code
rtc_set_ntp_time() is not really RTC functionality as the code is just a
user of RTC. Move it into the NTP code which allows further cleanups.
Requested-by: Alexandre Belloni
On Mon, Dec 07 2020 at 17:05, Jason Gunthorpe wrote:
> On Sun, Dec 06, 2020 at 10:46:21PM +0100, Thomas Gleixner wrote:
>> static void sync_hw_clock(struct work_struct *work)
>> {
>> +static unsigned long offset_nsec = NSEC_PER_SEC / 2;
>
> A comment here explaining this is the default:
t; > 3) Reduce the default transport time
>> >
>> > 4) Switch the NTP periodic sync code to a hrtimer/work combo
>> >
>> > 5) Move rtc_set_npt_time() to the ntp code
>> > 6) Make the update offset more intuitive
>> > 7) Simpl
> > it. Of course there are better methods to do that and it can be
> > completely done in user space.
> >
> > Unfortunately it's not that simple as this would be a user visible
> > change, so making it at least halfways correct.
> >
> >
On 07/12/2020 16:59:52-0400, Jason Gunthorpe wrote:
> On Sun, Dec 06, 2020 at 10:46:19PM +0100, Thomas Gleixner wrote:
> > rtc_set_ntp_time() is not really RTC functionality as the code is just a
> > user of RTC. Move it into the NTP code which allows further cleanups.
>
rtunately it's not that simple as this would be a user visible
> change, so making it at least halfways correct.
>
> 3) Alexandre requested to move that code into the NTP code as this is not
> really RTC functionality and just usage of the RTC API.
>
> 4) The up
On Sun, Dec 06, 2020 at 10:46:21PM +0100, Thomas Gleixner wrote:
> /*
> * If we have an externally synchronized Linux clock, then update RTC clock
> * accordingly every ~11 minutes. Generally RTCs can only store second
> @@ -686,6 +621,10 @@ static bool sync_cmos_clock(void)
> */
> static
On Sun, Dec 06, 2020 at 10:46:19PM +0100, Thomas Gleixner wrote:
> rtc_set_ntp_time() is not really RTC functionality as the code is just a
> user of RTC. Move it into the NTP code which allows further cleanups.
>
> Requested-by: Alexandre Belloni
> Signed-off-by:
On Sun, Dec 06, 2020 at 10:46:18PM +0100, Thomas Gleixner wrote:
> Miroslav reported that the periodic RTC synchronization in the NTP code
> fails more often than not to hit the specified update window.
>
> The reason is that the code uses delayed_work to schedule the update w
On Sun, Dec 06, 2020 at 10:46:18PM +0100, Thomas Gleixner wrote:
> Switch it to an hrtimer instead which schedules the actual update work. The
> hrtimer will expire precisely (max 1 jiffie delay when high resolution
> timers are not available). The actual scheduling delay of the work is the
> same
Miroslav reported that the periodic RTC synchronization in the NTP code
fails more often than not to hit the specified update window.
The reason is that the code uses delayed_work to schedule the update which
needs to be in thread context as the underlying RTC might be connected via
a slow bus
.tv_nsec = set_offset_nsec};
*to_set = timespec64_add(*now, delay);
@@ -557,11 +568,11 @@ static inline bool rtc_tv_nsec_ok(long s
/*
* rtc_set_ntp_time - Save NTP synchronized time to the RTC
*/
-static int rtc_set_ntp_time(struct timespec64 now, unsign
+int __weak update_persistent_clock64(struct timespec64 now64)
+{
+ return -ENODEV;
+}
+#else
+static inline int update_persistent_clock64(struct timespec64 now64)
+{
+ return -ENODEV;
+}
+#endif
+
#ifdef CONFIG_RTC_SYSTOHC
-/*
- * rtc_set_ntp_time - Save NTP synchronized time
rtc_set_ntp_time() is not really RTC functionality as the code is just a
user of RTC. Move it into the NTP code which allows further cleanups.
Requested-by: Alexandre Belloni
Signed-off-by: Thomas Gleixner
---
drivers/rtc/Makefile |1
drivers/rtc/systohc.c | 61
that code into the NTP code as this is not
really RTC functionality and just usage of the RTC API.
4) The update offset itself was questioned, but the time between the
write and the next seconds increment in the RTC is fundamentaly a
hardware property. The transport time, which
was massive - I have to force a difference of around 8000ns/10ms
to see similar behaviour.
The only explanation I can guess at is that it was subject
to NTP's maximum slew rate of 0.5ms/sec (1/2000) while NTP
was aligning CLOCK_REALTIME.
While the NTP adjustments for clock frequency drift aren't
ld=2453141035832 new=2372389610455 [49926.567273] audit: type=1333
> > > audit(1569253317.638:225): op=freq old=-2413071187316 new=-2403561671476
> > >
> > > This gets emitted every time ntp makes an adjustment, which is apparently
> > > very frequent on some host
=2372389610455
[49926.567273] audit: type=1333 audit(1569253317.638:225): op=freq
old=-2413071187316 new=-2403561671476
This gets emitted every time ntp makes an adjustment, which is apparently very
frequent on some hosts.
Audit isn't even enabled on these machines.
# auditctl -l
No rules
# auditctl -s
3.16.74-rc1 review patch. If anyone has any objections, please let me know.
--
From: Miroslav Lichvar
commit fdc6bae940ee9eb869e493990540098b8c0fd6ab upstream.
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting too far ahead of the
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting too far ahead of the
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting too far ahead of the
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting too far ahead of the
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting too far ahead of the
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting too far ahead of the
From: Miroslav Lichvar
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting
From: Miroslav Lichvar
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting
From: Miroslav Lichvar
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting
From: Miroslav Lichvar
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting
From: Miroslav Lichvar
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting
From: Miroslav Lichvar
[ Upstream commit d897a4ab11dc8a9fda50d2eccc081a96a6385998 ]
Don't allow the TAI-UTC offset of the system clock to be set by adjtimex()
to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the CLOCK_TAI
clock from getting
Commit-ID: d897a4ab11dc8a9fda50d2eccc081a96a6385998
Gitweb: https://git.kernel.org/tip/d897a4ab11dc8a9fda50d2eccc081a96a6385998
Author: Miroslav Lichvar
AuthorDate: Tue, 18 Jun 2019 17:47:13 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 22 Jun 2019 11:28:53 +0200
ntp: Limit TAI
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero (which
applications may
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero (which
applications may
Don't allow the TAI-UTC offset of the system clock to be set by
adjtimex() to a value larger than 10 seconds.
This prevents an overflow in the conversion to int, prevents the
CLOCK_TAI clock from getting too far ahead of the CLOCK_REALTIME clock,
and it is still large enough to allow leap
Miroslav,
On Mon, 17 Jun 2019, Miroslav Lichvar wrote:
> On Mon, Jun 17, 2019 at 02:14:57PM +0200, Thomas Gleixner wrote:
> > On Mon, 17 Jun 2019, 维康石 wrote:
> > > Yes,the >UINT_MAX value can be passed by
> > > syscall adjtimex->do_adjtimex->__do_adjtimex->process_adjtimex_modes by
> > > the
>
On Mon, Jun 17, 2019 at 02:14:57PM +0200, Thomas Gleixner wrote:
> On Mon, 17 Jun 2019, 维康石 wrote:
> > Yes,the >UINT_MAX value can be passed by
> > syscall adjtimex->do_adjtimex->__do_adjtimex->process_adjtimex_modes by the
> > proper arugments.
>
> So there is clearly some sanity check missing,
On Mon, 17 Jun 2019, 维康石 wrote:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
On Mon, 22 Apr 2019, Weikang shi wrote:
> From: swkhack
>
> It is meanless to check a 64bit(txc->constant) value is postive
> when the value has to be assigned to a 32 bit variable(*time_tai).
> So I make a temp type conversion before the compare.
What? Casting it to int makes it more
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero (which
applications may
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero (which
applications may
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero (which
applications may
From: Miroslav Lichvar
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero
From: Miroslav Lichvar
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero
From: Miroslav Lichvar
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero
From: Miroslav Lichvar
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero
From: Miroslav Lichvar
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero
From: Miroslav Lichvar
[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero
Commit-ID: fdc6bae940ee9eb869e493990540098b8c0fd6ab
Gitweb: https://git.kernel.org/tip/fdc6bae940ee9eb869e493990540098b8c0fd6ab
Author: Miroslav Lichvar
AuthorDate: Wed, 17 Apr 2019 10:48:33 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 9 May 2019 10:46:58 +0200
ntp: Allow TAI-UTC
On Mon, 22 Apr 2019, Weikang shi wrote:
> From: swkhack
>
> It is meanless to check a 64bit(txc->constant) value is postive
> when the value has to be assigned to a 32 bit variable(*time_tai).
> So I make a temp type conversion before the compare.
Errm no. This is missing a proper range check
From: swkhack
It is meanless to check a 64bit(txc->constant) value is postive
when the value has to be assigned to a 32 bit variable(*time_tai).
So I make a temp type conversion before the compare.
Signed-off-by: swkhack
---
kernel/time/ntp.c | 2 +-
1 file changed, 1 insertion(+), 1
Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in
> > > > order to allow setting it back to the initial value.
> >
> > > Thanks for sending the patch! Maybe you (or the committer) could
> > > consider adding:
> > >
> > > Fixes
t; order to allow setting it back to the initial value.
>
> > Thanks for sending the patch! Maybe you (or the committer) could
> > consider adding:
> >
> > Fixes: 153b5d054ac2 ("ntp: support for TAI")
>
> To me the change looks more like an extension of the A
e patch! Maybe you (or the committer) could
> consider adding:
>
> Fixes: 153b5d054ac2 ("ntp: support for TAI")
To me the change looks more like an extension of the API, rather than
a bug fix, so I'd leave that up to the committer.
--
Miroslav Lichvar
On Wed, Apr 17, 2019 at 10:48 AM Miroslav Lichvar wrote:
> The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
> It is typically set by NTP/PTP implementations and it is automatically
> updated by the kernel on leap seconds. The initial value is zero (which
> appl
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
It is typically set by NTP/PTP implementations and it is automatically
updated by the kernel on leap seconds. The initial value is zero (which
applications may interpret as unknown), but this value cannot be set by
adjtimex
On Tue, 9 Apr 2019, Ondrej Mosnacek wrote:
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 2c62c046..1c372ad7ebe9 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -86,6 +86,26 @@ struct audit_field {
> u32 op;
> };
es a few unnecessary writes into memory under
> CONFIG_AUDIT=n, but if that is an issue I can boost the abstraction or
> just add some #ifdefs to avoid that.
No ifdefs please. Aside of that, why do you need all those details of the
ntp internals in the first place? The changelog does not give me an answer
to that.
Thanks,
tglx
On Thu, Mar 28, 2019 at 1:02 AM Thomas Gleixner wrote:
> On Thu, 7 Mar 2019, Ondrej Mosnacek wrote:
>
> > Emit an audit record every time selected NTP parameters are modified
> > from userspace (via adjtimex(2) or clock_adjtime(2)).
> >
> > Such events wil
On Thursday, March 7, 2019 7:32:54 AM EST Ondrej Mosnacek wrote:
> Emit an audit record every time selected NTP parameters are modified
> from userspace (via adjtimex(2) or clock_adjtime(2)).
>
> Such events will now generate records of type AUDIT_TIME_ADJNTPVAL
> containing the f
Emit an audit record every time selected NTP parameters are modified
from userspace (via adjtimex(2) or clock_adjtime(2)).
Such events will now generate records of type AUDIT_TIME_ADJNTPVAL
containing the following fields:
- op -- which value was adjusted:
- offset -- corresponding
On Wed, Mar 06, 2019 at 02:37:21PM +0100, Arnd Bergmann wrote:
>
> There is also y2070 (many RTCs), y2100 (some other RTCs, especially
> those that assume it's a leap year), and y2106.
That's okay, Arnd. When the time comes you can come out of retirement
and cash in, doing Y2.07, Y2.1, and
On Wed, Mar 6, 2019 at 1:29 PM Thomas Gleixner wrote:
> On Wed, 6 Mar 2019, Miroslav Lichvar wrote:
> > On Tue, Mar 05, 2019 at 05:42:25PM -0800, John Stultz wrote:
> So once Arnd is done with y2038, we'll ask him to look into y2262 :)
There is also y2070 (many RTCs), y2100 (some other RTCs,
On Wed, 6 Mar 2019, Miroslav Lichvar wrote:
> On Tue, Mar 05, 2019 at 05:42:25PM -0800, John Stultz wrote:
> > > --- a/kernel/time/ntp.c
> > > +++ b/kernel/time/ntp.c
> > > @@ -677,6 +677,8 @@ static inline void process_adjtimex_modes(const
> > > struct timex *txc, s32 *time_tai
> > >
> > >
On Tue, Mar 05, 2019 at 05:42:25PM -0800, John Stultz wrote:
> > --- a/kernel/time/ntp.c
> > +++ b/kernel/time/ntp.c
> > @@ -677,6 +677,8 @@ static inline void process_adjtimex_modes(const struct
> > timex *txc, s32 *time_tai
> >
> > if (txc->modes & ADJ_MAXERROR)
> >
On Tue, Mar 5, 2019 at 5:29 PM Xiongfeng Wang wrote:
>
> When I ran Syzkaller testsuite, I got the following call trace.
>
> UBSAN: Undefined behaviour in kernel/time/ntp.c:457:16
> signed integer overflow:
>
When I ran Syzkaller testsuite, I got the following call trace.
UBSAN: Undefined behaviour in kernel/time/ntp.c:457:16
signed integer overflow:
9223372036854775807 + 500 cannot be represented in type 'long int'
CPU: 3
Commit-ID: 07daef8b41e0d9e7802a448f6766504e7641a234
Gitweb: https://git.kernel.org/tip/07daef8b41e0d9e7802a448f6766504e7641a234
Author: YueHaibing
AuthorDate: Sun, 9 Dec 2018 14:22:25 +0800
Committer: Thomas Gleixner
CommitDate: Tue, 18 Dec 2018 12:59:33 +0100
ntp: Remove duplicated
Remove duplicated include.
Signed-off-by: YueHaibing
---
kernel/time/ntp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index c5e0cba..bc3a3c3 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -17,7 +17,6 @@
#include
#include
#include
No luck on linuxppc-dev, trying LKML ...
Forwarded Message
From: Joakim Tjernlund
To: linuxppc-dev linuxppc-dev
Subject: 11 minute NTP hw clock update racy?
Date: Mon, 27 Aug 2018 10:01:12 +0200
We see corrupt HW clock time every now and then(really hard to reproduce)
Our RTC
No luck on linuxppc-dev, trying LKML ...
Forwarded Message
From: Joakim Tjernlund
To: linuxppc-dev linuxppc-dev
Subject: 11 minute NTP hw clock update racy?
Date: Mon, 27 Aug 2018 10:01:12 +0200
We see corrupt HW clock time every now and then(really hard to reproduce)
Our RTC
From: Sebastian Andrzej Siewior
4.9.115-rt94-rc1 stable review patch.
If you have any objection to the inclusion of this patch, let me know.
--- 8< --- 8< --- 8< ---
I've been looking at this in v3.10-RT where it got in. The patch
description says
|The ntp code for notify_c
From: Sebastian Andrzej Siewior
4.9.115-rt94-rc1 stable review patch.
If you have any objection to the inclusion of this patch, let me know.
--- 8< --- 8< --- 8< ---
I've been looking at this in v3.10-RT where it got in. The patch
description says
|The ntp code for notify_c
(void)
/*
* Propagate a new txc->status value into the NTP state:
*/
-static inline void process_adj_status(struct timex *txc)
+static inline void process_adj_status(const struct timex *txc)
{
if ((time_status & STA_PLL) && !(txc->status & STA_PLL)) {
From: Ondrej Mosnacek
...instead of kstrtol with a dirty cast.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Signed-off-by: Ondrej Mosnacek
Signed-off-by: John Stultz
---
kernel/time/ntp.c | 5 ++---
1 file changed, 2
(void)
/*
* Propagate a new txc->status value into the NTP state:
*/
-static inline void process_adj_status(struct timex *txc)
+static inline void process_adj_status(const struct timex *txc)
{
if ((time_status & STA_PLL) && !(txc->status & STA_PLL)) {
From: Ondrej Mosnacek
...instead of kstrtol with a dirty cast.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Signed-off-by: Ondrej Mosnacek
Signed-off-by: John Stultz
---
kernel/time/ntp.c | 5 ++---
1 file changed, 2
)
/*
* Propagate a new txc->status value into the NTP state:
*/
-static inline void process_adj_status(struct timex *txc, struct timespec64 *ts)
+static inline void process_adj_status(struct timex *txc)
{
if ((time_status & STA_PLL) && !(txc->status & STA_PLL)) {
)
/*
* Propagate a new txc->status value into the NTP state:
*/
-static inline void process_adj_status(struct timex *txc, struct timespec64 *ts)
+static inline void process_adj_status(struct timex *txc)
{
if ((time_status & STA_PLL) && !(txc->status & STA_PLL)) {
On Fri, Jul 13, 2018 at 5:06 AM, Ondrej Mosnacek wrote:
> The 'ts' argument of process_adj_status() and process_adjtimex_modes()
> is unused and can be safely removed.
>
> Signed-off-by: Ondrej Mosnacek
Thanks for sending this set along. I'll queue them up for closer
review and testing.
thanks
On Fri, Jul 13, 2018 at 5:06 AM, Ondrej Mosnacek wrote:
> The 'ts' argument of process_adj_status() and process_adjtimex_modes()
> is unused and can be safely removed.
>
> Signed-off-by: Ondrej Mosnacek
Thanks for sending this set along. I'll queue them up for closer
review and testing.
thanks
...instead of kstrtol with a dirty cast.
Signed-off-by: Ondrej Mosnacek
---
kernel/time/ntp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 25031ffb5d25..6c764addef3e 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@
1 - 100 of 966 matches
Mail list logo
