From: Danilo Krummrich <dakr@redhat.com>
To: Liviu Dudau <liviu.dudau@arm.com>
Cc: daniel@ffwll.ch, airlied@linux.ie, tzimmermann@suse.de,
mripard@kernel.org, brian.starkey@arm.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH drm-misc-next v3 4/7] drm/arm/hdlcd: use drm_dev_unplug()
Date: Fri, 14 Oct 2022 02:07:09 +0200 [thread overview]
Message-ID: <4010f21b-4478-d860-c5ba-d6680d35993b@redhat.com> (raw)
In-Reply-To: <Y0bYGjtAHbjeGJHF@e110455-lin.cambridge.arm.com>
Hi Liviu,
On 10/12/22 17:07, Liviu Dudau wrote:
> Hi Danilo,
>
> Appologies again for the delay in reviewing this as I was at XDC last week.
No worries, thanks for following up.
> Looking at the documentation for drm_dev_unplug, you can get a hint about what is going on:
>
> /*
> * [....] There is one
> * shortcoming however, drm_dev_unplug() marks the drm_device as unplugged before
> * drm_atomic_helper_shutdown() is called. This means that if the disable code
> * paths are protected, they will not run on regular driver module unload,
> * possibly leaving the hardware enabled.
> */
>
Yes, that's the issue we have and pretty unfortunate. What we'd want for
platform device drivers is to still be able to enter the sections locked
with drm_dev_{enter,exit} on driver unbind, which we can't for at the
moment.
I discussed this with Daniel Vetter on #dri-devel and for now he
suggests to just not lock access to platform device bound resources and
respin the patchset removing those parts.
Besides that I'll also work on a solution for drm_dev_unplug() /
drm_dev_{enter,exit} to overcome this issue in the future.
> I'm finally getting to a conclusion: I'm still not sure what problem you were trying
> to solve when you have started this series and if you have found a scenario where
> you've got use after free then I would like to be able to reproduce it on my setup.
> Otherwise, I think this whole series introduces a regression on the behaviour of the
> driver and I would be inclined to reject it.
The problem is that DRM modeset objects should never be allocated with
devm_*, since this can result in use-after free issues on driver unload.
They should be freed when the last reference to the object is dropped,
which DRM managed APIs take care of. As a consequence, DRM managed
objects can potentially out-live platform device bound resources, which
then should be protected from access. The first at least we can and
should do.
It's not an issue that's unique to hdlcd, it's just a known issue to be
addressed by all drivers. There's still the shortcoming concerning
protecting platform bound resources as discussed above, but "the drmm
parts should be a good idea no matter what" to cite Daniel.
I'll send a v4 without the drm_dev_{enter,exit} parts removed if that's
fine for you.
- Danilo
>
> Best regards,
> Liviu
next prev parent reply other threads:[~2022-10-14 0:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-01 1:18 [PATCH drm-misc-next v3 0/7] drm/arm/hdlcd: use drm managed resources Danilo Krummrich
2022-10-01 1:18 ` [PATCH drm-misc-next v3 1/7] drm/arm/hdlcd: use drmm_* to allocate driver structures Danilo Krummrich
2022-10-01 1:19 ` [PATCH drm-misc-next v3 2/7] drm/arm/hdlcd: replace drm->dev_private with drm_to_hdlcd_priv() Danilo Krummrich
2022-10-01 1:19 ` [PATCH drm-misc-next v3 3/7] drm/arm/hdlcd: plane: use drm managed resources Danilo Krummrich
2022-10-01 1:19 ` [PATCH drm-misc-next v3 4/7] drm/arm/hdlcd: use drm_dev_unplug() Danilo Krummrich
2022-10-12 15:07 ` Liviu Dudau
2022-10-14 0:07 ` Danilo Krummrich [this message]
2022-10-14 11:11 ` Liviu Dudau
2022-10-01 1:19 ` [PATCH drm-misc-next v3 5/7] drm/arm/hdlcd: crtc: protect device resources after removal Danilo Krummrich
2022-10-01 1:19 ` [PATCH drm-misc-next v3 6/7] drm/arm/hdlcd: debugfs: " Danilo Krummrich
2022-10-01 1:19 ` [PATCH drm-misc-next v3 7/7] drm/arm/hdlcd: remove calls to drm_mode_config_cleanup() Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4010f21b-4478-d860-c5ba-d6680d35993b@redhat.com \
--to=dakr@redhat.com \
--cc=airlied@linux.ie \
--cc=brian.starkey@arm.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=mripard@kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®