Re: [ANNOUNCE] 3.14-rt1

From: Steven Rostedt
Date: Mon Apr 28 2014 - 10:18:23 EST


On Mon, 28 Apr 2014 11:09:46 +0200
Mike Galbraith <umgwanakikbuti@xxxxxxxxx> wrote:

> migrate_disable-pushd-down-in-atomic_dec_and_spin_lo.patch
>
> bug: migrate_disable() after blocking is too late.
>
> @@ -1028,12 +1028,12 @@ int atomic_dec_and_spin_lock(atomic_t *a
> /* Subtract 1 from counter unless that drops it to 0 (ie. it was 1) */
> if (atomic_add_unless(atomic, -1, 1))
> return 0;
> - migrate_disable();
> rt_spin_lock(lock);
> - if (atomic_dec_and_test(atomic))
> + if (atomic_dec_and_test(atomic)){
> + migrate_disable();

Makes sense, as the CPU can go offline right after the lock is grabbed
and before the migrate_disable() is called.

Seems that migrate_disable() must be called before taking the lock as
it is done in every other location.

-- Steve


> return 1;
> + }
> rt_spin_unlock(lock);
> - migrate_enable();
> return 0;
> }
> EXPORT_SYMBOL(atomic_dec_and_spin_lock);
>
> read_lock-migrate_disable-pushdown-to-rt_read_lock.patch
>
> bug: ditto.
>
> @@ -244,8 +246,10 @@ void __lockfunc rt_read_lock(rwlock_t *r
> /*
> * recursive read locks succeed when current owns the lock
> */
> - if (rt_mutex_owner(lock) != current)
> + if (rt_mutex_owner(lock) != current) {
> __rt_spin_lock(lock);
> + migrate_disable();
> + }
> rwlock->read_depth++;
> }
>
> Moving that migrate_disable() up will likely fix my hotplug troubles.
> I'll find out when I get back from physical torture (therapy) session.
>
> -Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/