Thread (5 messages) read the whole thread 5 messages, 2 authors, 2012-03-06

Re: [PATCH RT] seqlock/rt: Prevent livelocks with seqlocks in RT

From: Thomas Gleixner <hidden>
Date: 2012-03-06 08:18:57
Also in: lkml

On Mon, 5 Mar 2012, Steven Rostedt wrote:
Thomas,

I was running my cpu hotplug stress test along with a kernel compile and
after about 40 minutes of running it locked up. It happened in the
read_seqcount_begin() that is called by d_lookup().

ksoftirqd was caught here:

static __always_inline unsigned read_seqbegin(const seqlock_t *sl)
{
	unsigned ret;

repeat:
	ret = ACCESS_ONCE(sl->sequence);
	if (unlikely(ret & 1)) {
		cpu_relax();
		goto repeat;
	}
	smp_rmb();

	return ret;
}

It preempted the holder of the seqlock that was held for write, and as
that holder had migrate disabled, it couldn't be scheduled. Then
ksoftirqd went into this infinite loop and the system locked up.

This patch fixes the issue by grabbing and releasing the write lock when
it detects contention. It only works with seqlocks and not seqcounts
that have their own locking. But we could add an api to include those
too if needed.
Errm. rt15 has 

/*
 * Starvation safe read side for RT
 */
static inline unsigned read_seqbegin(seqlock_t *sl)
{
        unsigned ret;

repeat:
        ret = sl->seqcount.sequence;
        if (unlikely(ret & 1)) {
                /*
                 * Take the lock and let the writer proceed (i.e. evtl
                 * boost it), otherwise we could loop here forever.
                 */
                spin_lock(&sl->lock);
                spin_unlock(&sl->lock);
                goto repeat;
        }
        return ret;
}
#endif
Because read_seqlocks are used in the VDSO area, a raw_read_seqcount_begin()
was created to allow userspace tasks to access read_seqcount().
As the grabbing of the write_lock() is not allowed in VDSO, nor
is even referencing it.
This is completely bogus. The VDSO update write side runs with
interrupts disabled, so it cannot be preempted at all.
Note, a live lock can still happen if the userspace task that
does the read_seqlock is of higher priority than a user doing
the write_lock, so userspace needs to be careful.
What the hell are you smoking?
 
Thanks,

	tglx
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help