On Thu, Dec 19, 2019 at 11:03 AM John Garry <john.garry@xxxxxxxxxx> wrote: > > On 19/12/2019 09:54, Daniel Vetter wrote: > > On Wed, Dec 18, 2019 at 7:08 PM John Garry <john.garry@xxxxxxxxxx> wrote: > >> > >> + > >> > >> So the v5.4 kernel does not have this issue. > >> > >> I have bisected the initial occurrence to: > >> > >> commit 37a48adfba6cf6e87df9ba8b75ab85d514ed86d8 > >> Author: Thomas Zimmermann <tzimmermann@xxxxxxx> > >> Date: Fri Sep 6 14:20:53 2019 +0200 > >> > >> drm/vram: Add kmap ref-counting to GEM VRAM objects > >> > >> The kmap and kunmap operations of GEM VRAM buffers can now be called > >> in interleaving pairs. The first call to drm_gem_vram_kmap() maps the > >> buffer's memory to kernel address space and the final call to > >> drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these > >> functions increment or decrement a reference counter. > >> > >> So this either exposes or creates the issue. > > > > Yeah that's just shooting the messenger. > > OK, so it exposes it. > > Like I said, for most drivers > > you can pretty much assume that their unload sequence has been broken > > since forever. It's not often tested, and especially the hotunbind > > from a device (as opposed to driver unload) stuff wasn't even possible > > to get right until just recently. > > Do you think it's worth trying to fix this for 5.5 and earlier, or just > switch to the device-managed interface for 5.6 and forget about 5.5 and > earlier? I suspect it's going to be quite some trickery to fix this properly and everywhere, even for just one driver. Lots of drm drivers unfortunately use anti-patterns with wrong lifetimes (e.g. you can't use devm_kmalloc for anything that hangs of a drm_device, like plane/crtc/connector). Except when it's for a real hotunpluggable device (usb) we've never bothered backporting these fixes. Too much broken stuff unfortunately. -Daniel > > Thanks, > John -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
