-----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 driversGah, 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