* [PATCH] time: fix a assignment error in ntp module
@ 2019-04-22 9:34 Weikang shi
2019-04-24 20:22 ` Thomas Gleixner
2019-06-17 7:21 ` Thomas Gleixner
0 siblings, 2 replies; 6+ messages in thread
From: Weikang shi @ 2019-04-22 9:34 UTC (permalink / raw)
To: john.stultz; +Cc: tglx, sboyd, linux-kernel, swkhack, swkhack
From: swkhack <swkhack@gmail.com>
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 <swkhack@gmail.com>
---
kernel/time/ntp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 92a90014a..6b454eafc 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -690,7 +690,7 @@ static inline void process_adjtimex_modes(const struct __kernel_timex *txc,
time_constant = max(time_constant, 0l);
}
- if (txc->modes & ADJ_TAI && txc->constant > 0)
+ if (txc->modes & ADJ_TAI && (int)txc->constant > 0)
*time_tai = txc->constant;
if (txc->modes & ADJ_OFFSET)
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] time: fix a assignment error in ntp module
2019-04-22 9:34 [PATCH] time: fix a assignment error in ntp module Weikang shi
@ 2019-04-24 20:22 ` Thomas Gleixner
2019-06-17 7:21 ` Thomas Gleixner
1 sibling, 0 replies; 6+ messages in thread
From: Thomas Gleixner @ 2019-04-24 20:22 UTC (permalink / raw)
To: Weikang shi; +Cc: John Stultz, sboyd, LKML, swkhack, Miroslav Lichvar
On Mon, 22 Apr 2019, Weikang shi wrote:
> From: swkhack <swkhack@gmail.com>
>
> 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 in the first place.
> Signed-off-by: swkhack <swkhack@gmail.com>
> ---
> kernel/time/ntp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
> index 92a90014a..6b454eafc 100644
> --- a/kernel/time/ntp.c
> +++ b/kernel/time/ntp.c
> @@ -690,7 +690,7 @@ static inline void process_adjtimex_modes(const struct __kernel_timex *txc,
> time_constant = max(time_constant, 0l);
> }
>
> - if (txc->modes & ADJ_TAI && txc->constant > 0)
> + if (txc->modes & ADJ_TAI && (int)txc->constant > 0)
> *time_tai = txc->constant;
>
> if (txc->modes & ADJ_OFFSET)
> --
> 2.17.1
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] time: fix a assignment error in ntp module
2019-04-22 9:34 [PATCH] time: fix a assignment error in ntp module Weikang shi
2019-04-24 20:22 ` Thomas Gleixner
@ 2019-06-17 7:21 ` Thomas Gleixner
[not found] ` <CAObeVcdBDbSiyQCX7C_G3p6TpB9yjRyrWwsvPgh11V8v+BNaqQ@mail.gmail.com>
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Gleixner @ 2019-06-17 7:21 UTC (permalink / raw)
To: Weikang shi; +Cc: John Stultz, sboyd, LKML, swkhack, Miroslav Lichvar
On Mon, 22 Apr 2019, Weikang shi wrote:
> From: swkhack <swkhack@gmail.com>
>
> 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 negative, right?
That's just wrong:
long long x = 0xFFFFFFFF00000000;
int y = (int) x;
x is obviously negative, but y not. C type casting 101.
> Signed-off-by: swkhack <swkhack@gmail.com>
> ---
> kernel/time/ntp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
> index 92a90014a..6b454eafc 100644
> --- a/kernel/time/ntp.c
> +++ b/kernel/time/ntp.c
> @@ -690,7 +690,7 @@ static inline void process_adjtimex_modes(const struct __kernel_timex *txc,
> time_constant = max(time_constant, 0l);
> }
>
> - if (txc->modes & ADJ_TAI && txc->constant > 0)
> + if (txc->modes & ADJ_TAI && (int)txc->constant > 0)
> *time_tai = txc->constant;
The way more interesting question is whether txc->constant can be >
UINT_MAX. In that case the txc->constant would be truncated.
Miroslav?
Thanks,
tglx
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] time: fix a assignment error in ntp module
[not found] ` <CAObeVcdBDbSiyQCX7C_G3p6TpB9yjRyrWwsvPgh11V8v+BNaqQ@mail.gmail.com>
@ 2019-06-17 12:14 ` Thomas Gleixner
2019-06-17 13:21 ` Miroslav Lichvar
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Gleixner @ 2019-06-17 12:14 UTC (permalink / raw)
To: 维康石
Cc: John Stultz, sboyd, LKML, swkhack, Miroslav Lichvar
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
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?
http://daringfireball.net/2007/07/on_top
> 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, but surely not that
type cast.
> > > - if (txc->modes & ADJ_TAI && txc->constant > 0)
> > > + if (txc->modes & ADJ_TAI && (int)txc->constant > 0)
> > > *time_tai = txc->constant;
> >
> > The way more interesting question is whether txc->constant can be >
> > UINT_MAX. In that case the txc->constant would be truncated.
> >
> > Miroslav?
Thanks,
tglx
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] time: fix a assignment error in ntp module
2019-06-17 12:14 ` Thomas Gleixner
@ 2019-06-17 13:21 ` Miroslav Lichvar
2019-06-17 15:06 ` Thomas Gleixner
0 siblings, 1 reply; 6+ messages in thread
From: Miroslav Lichvar @ 2019-06-17 13:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: 维康石, John Stultz, sboyd, LKML, swkhack
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, but surely not that
> type cast.
As the offset is saved in an int (and returned via adjtimex() in the
tai field), should be the maximum INT_MAX?
We probably also want to avoid overflow in the offset on a leap second
and the CLOCK_TAI clock itself, so maybe it would make sense to
specify a much smaller maximum like 1000000?
Even 1000 should be good enough for near future. Negative values are
not allowed anyway. If the Earth's rotation changed significantly
(e.g. hitting a very large asteroid), there probably wouldn't be
anyone left to care about TAI.
--
Miroslav Lichvar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] time: fix a assignment error in ntp module
2019-06-17 13:21 ` Miroslav Lichvar
@ 2019-06-17 15:06 ` Thomas Gleixner
0 siblings, 0 replies; 6+ messages in thread
From: Thomas Gleixner @ 2019-06-17 15:06 UTC (permalink / raw)
To: Miroslav Lichvar
Cc: 维康石, John Stultz, sboyd, LKML, swkhack
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
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
> > > proper arugments.
> >
> > So there is clearly some sanity check missing, but surely not that
> > type cast.
>
> As the offset is saved in an int (and returned via adjtimex() in the
> tai field), should be the maximum INT_MAX?
Right.
> We probably also want to avoid overflow in the offset on a leap second
> and the CLOCK_TAI clock itself, so maybe it would make sense to
> specify a much smaller maximum like 1000000?
>
> Even 1000 should be good enough for near future. Negative values are
> not allowed anyway. If the Earth's rotation changed significantly
> (e.g. hitting a very large asteroid), there probably wouldn't be
> anyone left to care about TAI.
Hehehe. I leave it to you to find a sane limit taking all the possible
events into account :)
Thanks,
tglx
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-06-17 15:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-22 9:34 [PATCH] time: fix a assignment error in ntp module Weikang shi
2019-04-24 20:22 ` Thomas Gleixner
2019-06-17 7:21 ` Thomas Gleixner
[not found] ` <CAObeVcdBDbSiyQCX7C_G3p6TpB9yjRyrWwsvPgh11V8v+BNaqQ@mail.gmail.com>
2019-06-17 12:14 ` Thomas Gleixner
2019-06-17 13:21 ` Miroslav Lichvar
2019-06-17 15:06 ` Thomas Gleixner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.