* Re: [TRIVIAL] 2.4.19 Fix adjtimex when txc->modes == 0
[not found] <20021108081529.559392C3AF@lists.samba.org>
@ 2002-11-08 9:57 ` Ulrich Windl
2002-11-09 8:01 ` Rusty Russell
0 siblings, 1 reply; 2+ messages in thread
From: Ulrich Windl @ 2002-11-08 9:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Michael Kerrisk
Rusty,
your EMail address (Rusty Trivial Russell <@rustcorp.com.au>)
is broken. I'm replying to linux-kernel instead.
I had reported this problem a long time (over a year at least)
to the list. I found no 100% solution that is compatible with
the old kernel version.
Best solution would be to separate the NTP functionality
(ntp_adjtime, ntp_gettime) from adjtime() in the kernel.
I wonder how adjtime(NULL, non_null) is implemented:
If "modes == 0" adjtimex() will emulate ntp_gettime()
if "modes & ADJ_OFFSET_SINGLESHOT" is set with "txc->offset ==
0", the current correction will be stopped.
You must distinguish it from a call to adjtime(non_null,
non_null) with an offset of 0 that will terminate the current
correction.
(Manual says: "The second call to adjtime() stops the first
call to adjtime() if delta is non-NULL, but does not undo the
effects of the previous call. If delta is NULL, then no time
correction will be done.")
If adjtimex() still should implement both library styles
(ntp_*, and adjtime()), the clean solution would be a new flag
like ADJ_OFFSET_QUERY (or ADJ_OFFSET_NO_SHOT or
ADJ_OFFSET_PEACE). [Well I'm beginning to like the last one ;-
)]
If adjtime(NULL, any) is used in Clib, adjtimex would have to
be called with the ADJ_OFFSET_PEACE flag, avoiding to disturb
the adjustment. If `any' is non-NULL, the offset would be
returned to user land.
Rehards,
Ulrich
On 8 Nov 2002 at 18:51, Rusty Trivial Russell wrote:
> Ulrich, does this look good to you?
>
> From: "Michael Kerrisk" <m.kerrisk@gmx.net>
>
> Hello Marcelo (or Rusty does this belong you as TPM?),
>
> I did try submitting it against 2.4.18pre10 but this patch
> didn't seem to make it. The problem still exists in 2.4.19.
>
> The glibc implementation of adjtime(delta, old_delta) should return
> the remaining time adjustment value from adjtimex() in old_delta if that
> argument is non-NULL.
>
> This is broken in the case that delta is NULL (i.e., we don't want
> a change, but just to find out the current time_adjust). The breakage
> occurs because adjtime specifies txc->modes as 0 (so that no change
> is made to the current offset) and in this case do_adjtimex() does not
> correctly return the required information in txc->offset.
>
> The patch below (against 2.4.19) seems to me the best way to
> fix the problem.
>
> Cheers,
>
> Michael
>
>
> --- trivial-2.5-bk/kernel/time.c.orig 2002-11-08 18:46:34.000000000 +1100
> +++ trivial-2.5-bk/kernel/time.c 2002-11-08 18:46:34.000000000 +1100
> @@ -361,7 +361,9 @@
> /* p. 24, (d) */
> result = TIME_ERROR;
>
> - if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
> + if (!txc->modes)
> + txc->offset = time_adjust;
> + else if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
> txc->offset = save_adjust;
> else {
> if (time_offset < 0)
> --
> Don't blame me: the Monkey is driving
> File: "Michael Kerrisk" <m.kerrisk@gmx.net>: [patch] 2.4.19 Fix adjtimex when txc->modes == 0
^ permalink raw reply [flat|nested] 2+ messages in thread