[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41ca529d-ad0c-40e7-b68c-c90297815bbc@web.de>
Date: Tue, 20 Feb 2024 09:25:44 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Johan Hovold <johan+linaro@...nel.org>, freedreno@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, linux-phy@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, kernel-janitors@...r.kernel.org,
Andrzej Hajda <andrzej.hajda@...el.com>,
Bjorn Andersson <andersson@...nel.org>, Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, Vinod Koul <vkoul@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Jernej Skrabec <jernej.skrabec@...il.com>, Jonas Karlman <jonas@...boo.se>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Kuogee Hsieh <quic_khsieh@...cinc.com>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Rob Clark <robdclark@...il.com>, stable@...r.kernel.org
Subject: Re: [PATCH 3/6] soc: qcom: pmic_glink_altmode: fix drm bridge
use-after-free
…
> Specifically, the dp-hpd bridge is currently registered before all
> resources have been acquired which means that it can also be
> deregistered on probe deferrals.
>
> In the meantime there is a race window where the new aux bridge driver
> (or PHY driver previously) may have looked up the dp-hpd bridge and
> stored a (non-reference-counted) pointer to the bridge which is about to
> be deallocated.
…
I got the impression that the change description can be improved another bit.
1. Will any additional imperative wordings become helpful?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.8-rc5#n94
…
> +++ b/drivers/soc/qcom/pmic_glink_altmode.c
> @@ -76,7 +76,7 @@ struct pmic_glink_altmode_port {
>
> struct work_struct work;
>
> - struct device *bridge;
> + struct auxiliary_device *bridge;
>
> enum typec_orientation orientation;
> u16 svid;
…
2. How do you think about to stress such a data type adjustment?
Regards,
Markus
Powered by blists - more mailing lists