Why need IRQ-safe version of seqlock for read access?

Question

When write accessing a shared resource protected by a seqlock, a writer must obtain an exclusive lock before entering the critical section. So, as with spinlocks, it makes sense for write accessing with seqlock to have common variants like *_irqsave and *_bh. But LDD3 (on page 128) says:

If your seqlock might be accessed from an interrupt handler, you should use the IRQ-safe versions instead:
unsigned int read_seqbegin_irqsave(seqlock_t *lock,
                                   unsigned long flags);
int read_seqretry_irqrestore(seqlock_t *lock, unsigned int seq,
                             unsigned long flags);

In my understanding, since it's designed for readers to be able to freely access the shared resource (only check consistencies at the end and retry if needed), it's perfectly OK for a read access to be interrupted by the scheduler or an hardware interrupt. Am I missing something? Thanks.

score 1 · Accepted Answer · answered Dec 04 '19 at 17:22

Since 3.9 kernel there are no such functions.
In general you're right: seqlock readers should be able to work with inconsistent data.
So if we read the counter, then some interrupt arrives, then we make sure that data is in inconsistent state - just do re-reading.

P.S. LDD3 - this tutorial is quite good, but not so relevant.

In such cases you can do some git investigation. Here it that commit.

Why need IRQ-safe version of seqlock for read access?

1 Answers1