ADJ_OFFSET_SS_READ bug?

[Michael Kerrisk]

Roman, John

John, thanks for ADJ_OFFSET_SS_READ, which fixed my bug report
(http://sourceware.org/bugzilla/show_bug?id=2449,
http://bugzilla.kernel.org/show_bug.cgi?id=6761)

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;
                        else
                                ntp_update_offset(txc->offset); /*XXX*/
                }
                if (txc->modes & ADJ_TICK)
                        tick_usec = txc->tick;

                if (txc->modes & (ADJ_TICK|ADJ_FREQUENCY|ADJ_OFFSET))
                        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?

Cheers,

Michael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/