Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock

[Heiko Carstens <heiko.carstens@de.ibm.com>]

On Tue, Mar 22, 2016 at 01:20:50PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 12:32:21PM +0100, Heiko Carstens wrote:
> > On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
> 
> > > And s390 does something entirely vile, no idea what.
> > 
> > For the two s390 usages tsk equals current. So it could be easily replaced
> > with set_current_state().
> 
> Hmm indeed, I only saw tsk = find_task_by_pid_ns() and didn't look
> further, but you do indeed have an assertion later that ensures task ==
> current.
> 
> I still don't get that code though; why would you set the current task
> state to UNINTERRUPTIBLE, also set need_resched, but then not call
> schedule() at all.
> 
> Clearly something magical is going on and its not clear.

The mechanism of our pfault code: if Linux is running as guest, runs a user
space process and the user space process accesses a page that the host has
paged out we get a pfault interrupt.

This allows us, within the guest, to schedule a different process. Without
this mechanism the host would have to suspend the whole virtual CPU until
the page has been paged in.

So when we get such an interrupt then we set the state of the current task
to uninterruptible and also set the need_resched flag. Both happens within
interrupt context(!). If we later on want to return to user space we
recognize the need_resched flag and then call schedule().
It's not very obvious how this works...

Of course we have a lot of additional fun with the completion interrupt (->
host signals that a page of a process has been paged in and the process can
continue to run). This interrupt can arrive on any cpu and, since we have
virtual cpus, actually appear before the interrupt that signals that a page
is missing.