Re: [TRIVIAL] 2.4.19 Fix adjtimex when txc->modes == 0

[Ulrich Windl]

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" <[e-mail]>
> 
>   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" <[e-mail]>: [patch] 2.4.19 Fix adjtimex when txc->modes == 0