linux-kernel - Re: [PATCH] locking/rtmutex: Flush the plug before entering the slowpath.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87sfct11u7.ffs@tglx>
Date:   Fri, 21 Apr 2023 21:18:08 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        linux-kernel@...r.kernel.org
Cc:     Crystal Wood <swood@...hat.com>, John Keeping <john@...anate.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Waiman Long <longman@...hat.com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH] locking/rtmutex: Flush the plug before entering the
 slowpath.

On Wed, Mar 22 2023 at 17:27, Sebastian Andrzej Siewior wrote:
>> This still leaves the problem vs. io_wq_worker_sleeping() and it's
>> running() counterpart after schedule().
>
> io_wq_worker_sleeping() has a kfree() so it probably should be moved,
> too.
> io_wq_worker_running() is a OR and INC and is fine.

Why is io_wq_worker_sleeping() not cured in the same way? Just because
it did not yet result in a splat?

Why not just expose sched_submit_work()?

> --- a/kernel/locking/rwbase_rt.c
> +++ b/kernel/locking/rwbase_rt.c
> @@ -143,6 +143,14 @@ static __always_inline int rwbase_read_lock(struct rwbase_rt *rwb,
>  	if (rwbase_read_trylock(rwb))
>  		return 0;
>  
> +	if (state != TASK_RTLOCK_WAIT) {

Bah. That code has explicit rwbase_foo() helpers which are filled in by
rwsem and rwlock. Making this conditional on state is creative at best.

> +		/*
> +		 * If we are going to sleep and we have plugged IO queued,
> +		 * make sure to submit it to avoid deadlocks.
> +		 */
> +		blk_flush_plug(current->plug, true);
> +	}
> +
>  	return __rwbase_read_lock(rwb, state);
>  }
>  
> diff --git a/kernel/locking/ww_rt_mutex.c b/kernel/locking/ww_rt_mutex.c
> index d1473c624105c..472e3622abf09 100644
> --- a/kernel/locking/ww_rt_mutex.c
> +++ b/kernel/locking/ww_rt_mutex.c
> @@ -67,6 +67,11 @@ __ww_rt_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ww_ctx,
>  			ww_mutex_set_context_fastpath(lock, ww_ctx);
>  		return 0;
>  	}
> +	/*
> +	 * If we are going to sleep and we have plugged IO queued, make sure to
> +	 * submit it to avoid deadlocks.
> +	 */
> +	blk_flush_plug(current->plug, true);
>  
>  	ret = rt_mutex_slowlock(&rtm->rtmutex, ww_ctx, state);

This hunk can be avoided by moving the submit work invocation to
rt_mutex_slowlock().

Thanks,

        tglx