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

[Peter Zijlstra]

On Tue, Mar 08, 2016 at 02:05:39PM -0800, Davidlohr Bueso wrote:
> The very nature of rt_mutex_handle_deadlock() implies that this
> patch is merely a formality, as in practice the saved barrier
> is of little use. That said, we can relax setting the task state
> and be done with it; blocking unconditionally... this is a deadlock!
> 
> Signed-off-by: Davidlohr Bueso <dbueso@xxxxxxx>
> ---
>  kernel/locking/rtmutex.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 8eb99b7f1ac8..c3d3c8e8ea5c 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -1216,7 +1216,7 @@ static void rt_mutex_handle_deadlock(int res, int detect_deadlock,
>  	 */
>  	rt_mutex_print_deadlock(w);
>  	while (1) {
> -		set_current_state(TASK_INTERRUPTIBLE);
> +		__set_current_state(TASK_INTERRUPTIBLE);
>  		schedule();

So you're right that it doesn't matter here, however for that very
reason I would suggest not using __set_current_state() before schedule()
unless there is a _really_ good reason, and then with an extensive
comment to go with.

Otherwise people will manage to pick this as an example to copy and who
all knows what kind of borkage will result from that.