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]
Date:   Wed, 13 Sep 2023 14:59:48 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Sebastian Reichel <sre@...nel.org>,
        dri-devel@...ts.freedesktop.org, linux-omap@...r.kernel.org,
        linux-kernel@...r.kernel.org, Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...il.com>
Subject: Re: [PATCH] drm/omap: dsi: Fix deferred probe warnings

On 12/04/2023 10:39, Tony Lindgren wrote:
> We may not have dsi->dsidev initialized during probe, and that can
> lead into various dsi related warnings as omap_dsi_host_detach() gets
> called with dsi->dsidev set to NULL.
> 
> The warnings can be "Fixed dependency cycle(s)" followed by a
> WARNING: CPU: 0 PID: 787 at drivers/gpu/drm/omapdrm/dss/dsi.c:4414.
> 
> Let's fix the warnings by checking for a valid dsi->dsidev.
> 
> Signed-off-by: Tony Lindgren <tony@...mide.com>
> ---
>   drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4411,7 +4411,7 @@ static int omap_dsi_host_detach(struct mipi_dsi_host *host,
>   {
>   	struct dsi_data *dsi = host_to_omap(host);
>   
> -	if (WARN_ON(dsi->dsidev != client))
> +	if (dsi->dsidev && WARN_ON(dsi->dsidev != client))
>   		return -EINVAL;
>   
>   	cancel_delayed_work_sync(&dsi->dsi_disable_work);

Shouldn't this rather be

if (!dsi->dsidev)
	return 0;

before the if (WARN_ON(dsi->dsidev != client)) line?

If dsi->dsidev is NULL, then attach hasn't been called, and we shouldn't 
do anything in the detach callback either.

With your change we'll end up doing all the work in the detach callback, 
without ever doing their counterpart in the attach side.

  Tomi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ