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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20131106101632.GG14082@phenom.ffwll.local>
Date:	Wed, 6 Nov 2013 11:16:32 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Dave Airlie <airlied@...il.com>
Cc:	Wang YanQing <udknight@...il.com>, Dave Airlie <airlied@...ux.ie>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [PATCH 0/5] drm: fix resources leak in error handle code path

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@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/