Re: [tip: locking/urgent] futex: Handle transient "ownerless" rtmutex state correctly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2020-11-06 at 21:26 +0000, tip-bot2 for Mike Galbraith wrote:
>
> ---
>  kernel/futex.c | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index f8614ef..7406914 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2380,10 +2380,22 @@ retry:
>  		}
>
>  		/*
> -		 * Since we just failed the trylock; there must be an owner.
> +		 * The trylock just failed, so either there is an owner or
> +		 * there is a higher priority waiter than this one.
>  		 */
>  		newowner = rt_mutex_owner(&pi_state->pi_mutex);
> -		BUG_ON(!newowner);
> +		/*
> +		 * If the higher priority waiter has not yet taken over the
> +		 * rtmutex then newowner is NULL. We can't return here with
> +		 * that state because it's inconsistent vs. the user space
> +		 * state. So drop the locks and try again. It's a valid
> +		 * situation and not any different from the other retry
> +		 * conditions.
> +		 */
> +		if (unlikely(!newowner)) {
> +			ret = -EAGAIN;
                        ^^^

My box just discovered an unnoticed typo.  That 'ret' should read 'err'
so we goto retry, else fbomb_v2 proggy will trigger gripeage.

[   44.089233] fuse: init (API version 7.32)
[   78.485163] ------------[ cut here ]------------
[   78.485171] WARNING: CPU: 1 PID: 4557 at kernel/futex.c:2482 fixup_pi_state_owner.isra.17+0x125/0x350
[   78.485171] ------------[ cut here ]------------
[   78.485174] WARNING: CPU: 2 PID: 4559 at kernel/futex.c:1486 do_futex+0x920/0xaf0
<snip>

	-Mike





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux