Re: [PATCH 0/5] drm: fix resources leak in error handle code path

[Daniel Vetter]

On Wed, Nov 06, 2013 at 01:45:31PM +1000, Dave Airlie wrote:
> On Thu, Oct 31, 2013 at 9:04 AM, Wang YanQing <udknight@xxxxxxxxx> wrote:
> > This series patches fix resource leak
> > issue in error handle code path I meet
> > with drm, vmalloc leak, etc.
> 
> Daniel this seems to cross over a bit with your cleanups,

Oops, missed this, thanks for the poking. This indeed conflicts rather
badly - my master plan will completely abolish drm_platform.c and
drm_usb.c. drm_pci.c needs to stick around for legacy drivers, I'm not
going to touch that (and imo also totally not worth the pain).

All modern (non-shadow-attach drivers) should eventually move to a driver
controlled load sequence. Once that's possible imo the best approach would
be to use devres.c for resource cleanups, everything else seems to be a
giant game of whack-a-mole.

One thing I haven't yet figured out how to combine the devres.c stuff with
legacy shadow attach mode in i915. Maybe I need to split out ums first ...

Oh, obligatory link to my current wip stuff:

http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-init-cleanup

Atm doesn't work for tegra since I haven't finished the rebase yet, some
trivial stuff to fix up.

> I also am not sure that the drm_cleanup_in_dev isn't going to cause
> issues as it reorders the unload operation with respect to other
> operations, and I wonder if legacy drivers might start crashing in
> this situation.

Agreed, whacking the cleanup code for legacy drivers is imo pointless.
Better to hide this all in a dark corner somewhere and forget about it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/