linux-kernel - Re: [PATCH v2 4/9] media: qcom: camss: Fix VFE-17x vfe_disable

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: <20230828171541.GY14596@pendragon.ideasonboard.com>
Date:   Mon, 28 Aug 2023 20:15:41 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc:     rfoss@...nel.org, todor.too@...il.com, agross@...nel.org,
        andersson@...nel.org, konrad.dybcio@...aro.org, mchehab@...nel.org,
        hverkuil-cisco@...all.nl, sakari.ailus@...ux.intel.com,
        andrey.konovalov@...aro.org, linux-media@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH v2 4/9] media: qcom: camss: Fix VFE-17x
 vfe_disable_output()

Hi Bryan,

Thank you for the patch.

On Tue, Aug 22, 2023 at 09:06:21PM +0100, Bryan O'Donoghue wrote:
> There are two problems with the current vfe_disable_output() routine.
> 
> Firstly we rightly use a spinlock to protect output->gen2.active_num
> everywhere except for in the IDLE timeout path of vfe_disable_output().
> Even if that is not racy "in practice" somehow it is by happenstance not
> by design.
> 
> Secondly we do not get consistent behaviour from this routine. On
> sc8280xp 50% of the time I get "VFE idle timeout - resetting". In this
> case the subsequent capture will succeed. The other 50% of the time, we
> don't hit the idle timeout, never do the VFE reset and subsequent
> captures stall indefinitely.
> 
> Rewrite the vfe_disable_output() routine to
> 
> - Quiesce write masters with vfe_wm_stop()
> - Set active_num = 0
> 
> remembering to hold the spinlock when we do so followed by
> 
> - Reset the VFE
> 
> Testing on sc8280xp and sdm845 shows this to be a valid fix.
> 
> Fixes: 7319cdf189bb ("media: camss: Add support for VFE hardware version Titan 170")
> Cc: stable@...r.kernel.org
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>

I can't comment on the validity of the fix, but nothing shocks me in the
patch, so I'm fine with it.

> ---
>  .../media/platform/qcom/camss/camss-vfe-170.c | 19 +++----------------
>  1 file changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-170.c b/drivers/media/platform/qcom/camss/camss-vfe-170.c
> index 02494c89da91c..ae9137633c301 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe-170.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-170.c
> @@ -500,28 +500,15 @@ static int vfe_disable_output(struct vfe_line *line)
>  	struct vfe_output *output = &line->output;
>  	unsigned long flags;
>  	unsigned int i;
> -	bool done;
> -	int timeout = 0;
> -
> -	do {
> -		spin_lock_irqsave(&vfe->output_lock, flags);
> -		done = !output->gen2.active_num;
> -		spin_unlock_irqrestore(&vfe->output_lock, flags);
> -		usleep_range(10000, 20000);

Now that you don't sleep anymore, I think you can drop the inclusion of
linux/delay.h.

> -
> -		if (timeout++ == 100) {
> -			dev_err(vfe->camss->dev, "VFE idle timeout - resetting\n");
> -			vfe_reset(vfe);
> -			output->gen2.active_num = 0;
> -			return 0;
> -		}
> -	} while (!done);
>  
>  	spin_lock_irqsave(&vfe->output_lock, flags);
>  	for (i = 0; i < output->wm_num; i++)
>  		vfe_wm_stop(vfe, output->wm_idx[i]);
> +	output->gen2.active_num = 0;
>  	spin_unlock_irqrestore(&vfe->output_lock, flags);
>  
> +	vfe_reset(vfe);
> +
>  	return 0;

This function could become void, especially given that its only caller
doesn't check the return value.

>  }
>  
> -- 
> 2.41.0
> 

-- 
Regards,

Laurent Pinchart