lkml.org 
[lkml]   [2012]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RT] seqlock/rt: Prevent livelocks with seqlocks in RT
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


\
 
 \ /
  Last update: 2012-03-06 09:21    [W:0.044 / U:0.104 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site