[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1310100322040.14436@skynet.skynet.ie>
Date: Thu, 10 Oct 2013 03:23:45 +0100 (IST)
From: Dave Airlie <airlied@...ux.ie>
To: Russell King - ARM Linux <linux@....linux.org.uk>
cc: Fengguang Wu <fengguang.wu@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
xen-devel@...ts.xenproject.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> I think David Arlie also needs a quiet talking to about how to use the
> device model:
>
> int drm_sysfs_device_add(struct drm_minor *minor)
> {
> minor->kdev.release = drm_sysfs_device_release;
> ...
> err = device_register(&minor->kdev);
> }
>
> static void drm_sysfs_device_release(struct device *dev)
> {
> memset(dev, 0, sizeof(struct device));
> return;
> }
>
> Since when has that been acceptable in a release function?
Well the commit that added it had a reason that seems to cover some other
device model abuses, so maybe someone who actually understands the device
model (all 2 people) can review usage.
Dave.
commit 77d26dc9b9805f322f5a1f6e559b18ad66205bd9
Author: Ma Ling <ling.ma@...el.com>
Date: Thu Apr 16 17:51:25 2009 +0800
drm: clean dirty memory after device release
In current code we register/unregister connector object by
drm_sysfs_connector_add/remove function.
However under some cases, we need to dynamically register or
unregister device
multiple times, so we have to go through register -> unregister
->register
routine.
Because after device_unregister function our memory is dirty, we need
to do
clean operation in order to re-register the device, otherwise the
system
will crash. The patch intends to clean device after device release.
Signed-off-by: Ma Ling <ling.ma@...el.com>
Signed-off-by: Dave Airlie <airlied@...hat.com>
--
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/
Powered by blists - more mailing lists