From: "Tang, CQ" <cq.tang@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel@ffwll.ch>,
Dave Airlie <airlied@redhat.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
stable <stable@vger.kernel.org>,
"Vetter, Daniel" <daniel.vetter@intel.com>
Subject: RE: [PATCH 1/3] drm: Restore driver.preclose() for all to use
Date: Wed, 29 Jul 2020 15:09:42 +0000 [thread overview]
Message-ID: <0118a278832d4dde8d8d71e3db635869@intel.com> (raw)
In-Reply-To: <159595365380.28639.1774414370144556112@build.alporthouse.com>
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Tuesday, July 28, 2020 9:28 AM
> To: Daniel Vetter <daniel@ffwll.ch>; Dave Airlie <airlied@redhat.com>
> Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; stable
> <stable@vger.kernel.org>; Gustavo Padovan
> <gustavo.padovan@collabora.com>; Tang, CQ <cq.tang@intel.com>; dri-
> devel <dri-devel@lists.freedesktop.org>; Vetter, Daniel
> <daniel.vetter@intel.com>
> Subject: Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
>
> Quoting Daniel Vetter (2020-07-27 20:32:45)
> > On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson <chris@chris-wilson.co.uk>
> wrote:
> > >
> > > An unfortunate sequence of events, but it turns out there is a valid
> > > usecase for being able to free/decouple the driver objects before
> > > they are freed by the DRM core. In particular, if we have a pointer
> > > into a drm core object from inside a driver object, that pointer
> > > needs to be nerfed *before* it is freed so that concurrent access
> > > (e.g. debugfs) does not following the dangling pointer.
> > >
> > > The legacy marker was adding in the code movement from drp_fops.c to
> > > drm_file.c
> >
> > I might fumble a lot, but not this one:
> >
> > commit 45c3d213a400c952ab7119f394c5293bb6877e6b
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date: Mon May 8 10:26:33 2017 +0200
> >
> > drm: Nerf the preclose callback for modern drivers
>
> Gah, when I going through the history it looked like it appeared out of
> nowhere.
>
> > Also looking at the debugfs hook that has some rather adventurous
> > stuff going on I think, feels a bit like a kitchensink with batteries
> > included. If that's really all needed I'd say iterate the contexts by
> > first going over files, then the ctx (which arent shared anyway) and
> > the problem should also be gone.
>
> Or we could cut out the middlelayer and put the release under the driver
> control with a call to the drm_release() when the driver is ready.
Chiris, can explain this idea, or post a patch ?
--CQ
> -Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Tang, CQ" <cq.tang@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel@ffwll.ch>,
Dave Airlie <airlied@redhat.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
stable <stable@vger.kernel.org>,
"Vetter, Daniel" <daniel.vetter@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/3] drm: Restore driver.preclose() for all to use
Date: Wed, 29 Jul 2020 15:09:42 +0000 [thread overview]
Message-ID: <0118a278832d4dde8d8d71e3db635869@intel.com> (raw)
In-Reply-To: <159595365380.28639.1774414370144556112@build.alporthouse.com>
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Tuesday, July 28, 2020 9:28 AM
> To: Daniel Vetter <daniel@ffwll.ch>; Dave Airlie <airlied@redhat.com>
> Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; stable
> <stable@vger.kernel.org>; Gustavo Padovan
> <gustavo.padovan@collabora.com>; Tang, CQ <cq.tang@intel.com>; dri-
> devel <dri-devel@lists.freedesktop.org>; Vetter, Daniel
> <daniel.vetter@intel.com>
> Subject: Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
>
> Quoting Daniel Vetter (2020-07-27 20:32:45)
> > On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson <chris@chris-wilson.co.uk>
> wrote:
> > >
> > > An unfortunate sequence of events, but it turns out there is a valid
> > > usecase for being able to free/decouple the driver objects before
> > > they are freed by the DRM core. In particular, if we have a pointer
> > > into a drm core object from inside a driver object, that pointer
> > > needs to be nerfed *before* it is freed so that concurrent access
> > > (e.g. debugfs) does not following the dangling pointer.
> > >
> > > The legacy marker was adding in the code movement from drp_fops.c to
> > > drm_file.c
> >
> > I might fumble a lot, but not this one:
> >
> > commit 45c3d213a400c952ab7119f394c5293bb6877e6b
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date: Mon May 8 10:26:33 2017 +0200
> >
> > drm: Nerf the preclose callback for modern drivers
>
> Gah, when I going through the history it looked like it appeared out of
> nowhere.
>
> > Also looking at the debugfs hook that has some rather adventurous
> > stuff going on I think, feels a bit like a kitchensink with batteries
> > included. If that's really all needed I'd say iterate the contexts by
> > first going over files, then the ctx (which arent shared anyway) and
> > the problem should also be gone.
>
> Or we could cut out the middlelayer and put the release under the driver
> control with a call to the drm_release() when the driver is ready.
Chiris, can explain this idea, or post a patch ?
--CQ
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: "Tang, CQ" <cq.tang@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel@ffwll.ch>, Dave Airlie <airlied@redhat.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
stable <stable@vger.kernel.org>,
Gustavo Padovan <gustavo.padovan@collabora.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Vetter, Daniel" <daniel.vetter@intel.com>
Subject: RE: [PATCH 1/3] drm: Restore driver.preclose() for all to use
Date: Wed, 29 Jul 2020 15:09:42 +0000 [thread overview]
Message-ID: <0118a278832d4dde8d8d71e3db635869@intel.com> (raw)
In-Reply-To: <159595365380.28639.1774414370144556112@build.alporthouse.com>
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Tuesday, July 28, 2020 9:28 AM
> To: Daniel Vetter <daniel@ffwll.ch>; Dave Airlie <airlied@redhat.com>
> Cc: intel-gfx <intel-gfx@lists.freedesktop.org>; stable
> <stable@vger.kernel.org>; Gustavo Padovan
> <gustavo.padovan@collabora.com>; Tang, CQ <cq.tang@intel.com>; dri-
> devel <dri-devel@lists.freedesktop.org>; Vetter, Daniel
> <daniel.vetter@intel.com>
> Subject: Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
>
> Quoting Daniel Vetter (2020-07-27 20:32:45)
> > On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson <chris@chris-wilson.co.uk>
> wrote:
> > >
> > > An unfortunate sequence of events, but it turns out there is a valid
> > > usecase for being able to free/decouple the driver objects before
> > > they are freed by the DRM core. In particular, if we have a pointer
> > > into a drm core object from inside a driver object, that pointer
> > > needs to be nerfed *before* it is freed so that concurrent access
> > > (e.g. debugfs) does not following the dangling pointer.
> > >
> > > The legacy marker was adding in the code movement from drp_fops.c to
> > > drm_file.c
> >
> > I might fumble a lot, but not this one:
> >
> > commit 45c3d213a400c952ab7119f394c5293bb6877e6b
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date: Mon May 8 10:26:33 2017 +0200
> >
> > drm: Nerf the preclose callback for modern drivers
>
> Gah, when I going through the history it looked like it appeared out of
> nowhere.
>
> > Also looking at the debugfs hook that has some rather adventurous
> > stuff going on I think, feels a bit like a kitchensink with batteries
> > included. If that's really all needed I'd say iterate the contexts by
> > first going over files, then the ctx (which arent shared anyway) and
> > the problem should also be gone.
>
> Or we could cut out the middlelayer and put the release under the driver
> control with a call to the drm_release() when the driver is ready.
Chiris, can explain this idea, or post a patch ?
--CQ
> -Chris
next prev parent reply other threads:[~2020-07-29 15:09 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 17:21 [PATCH 1/3] drm: Restore driver.preclose() for all to use Chris Wilson
2020-07-23 17:21 ` Chris Wilson
2020-07-23 17:21 ` [Intel-gfx] " Chris Wilson
2020-07-23 17:21 ` [PATCH 2/3] drm/i915/gem: Move context decoupling from postclose to preclose Chris Wilson
2020-07-23 17:21 ` Chris Wilson
2020-07-23 17:21 ` [Intel-gfx] " Chris Wilson
2020-07-23 17:44 ` Tang, CQ
2020-07-23 17:44 ` Tang, CQ
2020-07-23 17:44 ` [Intel-gfx] " Tang, CQ
2020-07-23 17:48 ` Chris Wilson
2020-07-23 17:48 ` [Intel-gfx] " Chris Wilson
2020-07-23 17:21 ` [PATCH 3/3] drm/i915/gem: Serialise debugfs i915_gem_objects with ctx->mutex Chris Wilson
2020-07-23 17:21 ` Chris Wilson
2020-07-23 17:21 ` [Intel-gfx] " Chris Wilson
2020-07-27 21:24 ` Sasha Levin
2020-07-27 21:24 ` Sasha Levin
2020-07-27 21:24 ` [Intel-gfx] " Sasha Levin
2020-09-14 16:45 ` Tvrtko Ursulin
2020-09-14 16:45 ` Tvrtko Ursulin
2020-09-14 16:45 ` Tvrtko Ursulin
2020-09-16 7:42 ` Daniel Vetter
2020-09-16 7:42 ` Daniel Vetter
2020-09-16 7:42 ` Daniel Vetter
2020-09-16 8:27 ` Tvrtko Ursulin
2020-09-16 8:27 ` Tvrtko Ursulin
2020-09-16 8:27 ` Tvrtko Ursulin
2020-07-23 17:31 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm: Restore driver.preclose() for all to use Patchwork
2020-07-23 17:31 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-07-23 17:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-07-23 20:37 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-07-27 19:32 ` [PATCH 1/3] " Daniel Vetter
2020-07-27 19:32 ` Daniel Vetter
2020-07-27 19:32 ` [Intel-gfx] " Daniel Vetter
2020-07-27 20:11 ` Tang, CQ
2020-07-27 20:11 ` Tang, CQ
2020-07-27 20:11 ` [Intel-gfx] " Tang, CQ
2020-07-28 16:27 ` Chris Wilson
2020-07-28 16:27 ` Chris Wilson
2020-07-28 16:27 ` [Intel-gfx] " Chris Wilson
2020-07-29 15:09 ` Tang, CQ [this message]
2020-07-29 15:09 ` Tang, CQ
2020-07-29 15:09 ` [Intel-gfx] " Tang, CQ
2020-07-27 21:24 ` Sasha Levin
2020-07-27 21:24 ` Sasha Levin
2020-07-27 21:24 ` [Intel-gfx] " Sasha Levin
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=0118a278832d4dde8d8d71e3db635869@intel.com \
--to=cq.tang@intel.com \
--cc=airlied@redhat.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo.padovan@collabora.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.