Skip to contentSkip to conversation

2.4.19 Fix adjtimex when txc->modes == 0

TRIVIAL Ulrich Windl 2 participants 2 messages Nov 8, 2002 – Nov 10, 2002 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Ulrich Windl

author
#1 lore raw

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

Quoted 43 lines · Rusty Trivial Russell

Ulrich, does this look good to you?

From: "Michael Kerrisk" <[email protected]>

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

kernel/time.c renamed from kernel/time.c.orig +3 -1
@@ -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)
Signature · 2 lines
  Don't blame me: the Monkey is driving
  File: "Michael Kerrisk" <[email protected]>: [patch] 2.4.19 Fix adjtimex when txc->modes == 0
#2 lore raw
Quoted 4 lines · On Fri, 08 Nov 2002 10:57:08 +0100 "Ulrich Windl"…

Rusty,

your EMail address (Rusty Trivial Russell <@rustcorp.com.au>) is broken. I'm replying to linux-kernel instead.

Samba.org seems to bounce my mails intermittantly. I don't suppose you kept the bounce message?

Quoted 3 lines

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.

OK, I'll drop this patch. It'd be nice to have a solution for 2.6 though.

Cheers,
Rusty.

Signature · 2 lines
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy