Re: [Adeos-main] do_gettimeofday in ADEOS ISR

[Philippe Gerum <rpm@xenomai.org>]

Hannes Mayer wrote:
> Hi all!
> 
> I was just wondering if calling do_gettimeofday in an ADEOS interrupt
> handler might cause any problems whatsoever ?
> 
> My ISR:
> flags = adeos_critical_enter (NULL);
> [...]
> do_gettimeofday()
> [...]
> adeos_critical_exit (flags);
> 
> I saw that the code for do_gettimeofday is different in kernel 2.4 and
> kernel 2.6:
> 
> Kernel 2.4:
> void do_gettimeofday(struct timeval *tv) {
> [...]
> read_lock_irqsave(&xtime_lock, flags);
> [...]
> read_unlock_irqrestore(&xtime_lock, flags);
> 
> Kernel 2.6:
> void do_gettimeofday(struct timeval *tv) {
> [...]
> do {
> [...]
> seq = read_seqbegin(&xtime_lock);
> [...]
> } while (read_seqretry(&xtime_lock, seq));
> 
> Well, read_lock_irqsave in 2.4 looks like a possible source for trouble,
> while read_seqbegin in 2.6 doesn't do anything with interrupts, right ?
> 

Yes, but that's not better anyway. Imagine what would happen if an 
undergoing write sequence on the xtime_lock in the Linux domain was 
preempted by an ISR from a higher priority domain which in turn calls 
do_gettimeofday(): the read sequence running over your high priority ISR 
would then loop on read_seqretry(), waiting for the undergoing write to 
end. Problem is, that the undergoing write sequence would not be allowed 
to resume until your current high priority domain running 
do_gettimeofday() relinquishes the processor. Catch 22. This could 
happen in both UP and SMP configs, not to speak of the funky behaviour 
one would get with the additional spinlock recursion issue over SMP, 
since a write sequence also grabs a spinlock.

-- 

Philippe.