On Tue, Dec 29, 2009 at 09:15:32AM -0500, Robert P. J. Day wrote:
>
> from kernel/timer.c:
>
> /*
> * The 64-bit jiffies value is not atomic - you MUST NOT read it
> * without sampling the sequence number in xtime_lock.
> * jiffies is defined in the linker script...
> */
>
> void do_timer(unsigned long ticks)
> {
> jiffies_64 += ticks;
> update_wall_time();
> calc_global_load();
> }
>
> i'm not sure how to interpret that comment since it clearly suggests
> that you can't simply access jiffies_64, but that's exactly what
> do_timer() is doing in that first line by incrementing it by a certain
> value. can anyone clarify whether the above makes any sense?
>
> rday
It is not suggesting that you can't manipulate jiffies_64, it suggests
that you shouldn't do it without holding xtime_lock.
Look here:
static void tick_periodic(int cpu)
{
if (tick_do_timer_cpu == cpu) {
write_seqlock(&xtime_lock);
/* Keep track of the next tick event */
tick_next_period = ktime_add(tick_next_period, tick_period);
do_timer(1);
write_sequnlock(&xtime_lock);
}
update_process_times(user_mode(get_irq_regs()));
profile_tick(CPU_PROFILING);
}
do_timer() is called under xtime_lock (write lock) so
its fine to modify jiffies_64 from it as it won't be
concurrently accessed.
If you just need to read it, you need to read_seqlock
xtime_lock, especially on a 32 bits arch where a read
access on a 64 bits var is not atomic.
Say you have jiffies_64 = 0x00000000ffffffff
It is racy if you have, say:
writer: reader:
movl jiffies_64, eax ; take low part
inc jiffies_64
movl jiffies_64 + 4, edx ; take high part
jnz done
inc jiffies_64 + 4 ; need to update high part
As a result, the reader will get 0x00000001ffffffff
while it should get either the old result
or the new one 0x0000000100000000
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [email protected]
Please read the FAQ at http://kernelnewbies.org/FAQ
