On Thu, 26 Mar 2015 07:27:30 +0100
Mike Galbraith [off-list ref] wrote:

On Thu, 2015-03-26 at 06:23 +0100, Mike Galbraith wrote:

quoted

I plan on taking a poke at getting "don't raise timer unconditionally"
working again when I get myself unburied, and see if I can come up with
a somewhat less icky way to work around take rtmutex in irq naughtiness.

Hm.. like maybe only do a fasttrylock with the wait lock already held
via trylock, and don't bother turning it loose until we're done, to keep
the sane people away.  That might work.. but may not be considered less
icky by people equipped with that mysterious "taste" thingy ;-)

You would still need to add some ownership so that all will fail the
fast path.

You mean create a spin_trylock_in_hirq() which would just lock
the waitlock and not even do the fast path with the rt_mutex.

	if (!raw_spin_trylock(waitlock))
		goto failed_lock;

	if (!try_to_take_rt_mutex()) {
		raw_spin_unlock(waitlock);
		goto failed_lock;
	}

	return success;


With the waitlock held, no slow path will get to the pi code. Then you
have a spin_unlock_in_hirq() that would go right into the slow path
assuming the waitlock is already held.

Sounds reasonable to me.

-- Steve