[lkml]   [2008]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Roman, John

John, thanks for ADJ_OFFSET_SS_READ, which fixed my bug report

Roman, thanks for fixing John's fix ;-)

However, I'm wondering if there is a potential bug in the
implementation of this flag. Note the following definitions
from include/linux/timex.h:

#define ADJ_OFFSET 0x0001 /* time offset */
#define ADJ_OFFSET_SINGLESHOT 0x8001 /* old-fashioned adjtime */
#define ADJ_OFFSET_SS_READ 0xa001 /* read-only adjtime */

Using the the above value for ADJ_OFFSET_SS_READ, where the bits match those
in ADJ_OFFSET and ADJ_OFFSET_SINGLESHOT, seems unnecessary as far as I can
see. Why was that done?

More to the point, it looks like it creates a bug, since the "read-only
adjtime" triggers the code path for ADJ_OFFSET:

if (txc->modes) {
if (txc->modes & ADJ_OFFSET) {
if (txc->modes == ADJ_OFFSET_SINGLESHOT)
/* adjtime() is independent from ntp_adjtime() */
time_adjust = txc->offset;
ntp_update_offset(txc->offset); /*XXX*/
if (txc->modes & ADJ_TICK)
tick_usec = txc->tick;

ntp_update_frequency(); /*XXX*/

Unless I misunderstood something, ADJ_OFFSET_SS_READ causes the code marked
XXX to be executed, but I don't think that is what is desired. Is that true?



 \ /
  Last update: 2008-06-23 10:21    [W:0.102 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site