* Daniel Walker ([EMAIL PROTECTED]) wrote: > On Mon, 2007-02-26 at 22:54 -0500, Mathieu Desnoyers wrote: > > If an NMI nests over the spinlock, we have a deadlock. > > Maybe not completely safe ... > > > In addition, clock->cycle_last is a cycle_t, defined as a 64 bits on > > x86. If is therefore not updated atomically by change_clocksource, > > timekeeping_init, timekeeping_resume and update_wall_time. If an NMI > > fires right on top of the update, especially around the 32 bits wrap > > around, the time will be really fuzzy. > > I'm not sure that is particularly significant considering that it's just > a possible bad timestamp, and the probability of that happening seems > rather low .. You could also modify NMI calls so they use a different > time stamping method, like reading the clocksource directly . >
Since you do not disable interrupts around the clocksource read, the same problem applies to interrupt handlers of higher priority than the cycle_last updating code. A bad timestamp can make a trace quite hard to follow and more error-prone. When someone is looking for _the_ failing case in a system, the infrastructure used to debug must be reliable. Sometimes error cases takes days before showing up : we can't afford to be unsure about the precision of the tracer. Also, the goal is to have a generic monotonic timestamp readable from everywhere. Excluding execution contexts doesn't seem like such a great idea (it just replicates the same problem somewhere else). > The pit clocksource could be dropped pretty easy with my clocksource > update patches, which I'm still working on but you could easily drop > clock sources that aren't atomic like the pit .. Also the pit is > generally undesirable, so it's not going to be missed. > Still important for old architectures where PIT is the only available clock source I guess. However, the clocksource struct should at least tell if the time can be read atomically and offer a different API for atomic vs non atomic read of time source, returning an error if no atomic time source is available. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
