lkml.org 
[lkml]   [2005]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] remove input_call_hotplug (Take#2)
On Thu, 20 Jan 2005 08:55:57 +0100, Hannes Reinecke <hare@suse.de> wrote:
> Greg KH wrote:
> > On Wed, Jan 19, 2005 at 02:48:14PM +0100, Hannes Reinecke wrote:
> >
> >>Hi Dmitry,
> >>
> >>attached is the reworked patch for removing the call to
> >>call_usermodehelper from input.c
> >>I've used the 'phys' attribute to generate the device names, this way we
> >>don't need to touch all drivers and the patch itself is nice and small.
> >
> >
> > The main problem of this is the input_dev structures are created
> > statically, right? Because of this, the release function really doesn't
> > work out correctly I think....
> >
> That depends on the driver. input_dev is in general a static entry in
> the driver-dependend structure, which in turn may be statically or
> dynamically allocated (depending on whether the driver allows for more
> than one instance of the device to be connected).
> Would dynamic allocation be of any help here?

The concern is the following: you are using class_simple and
class_device structure is embedded into input_dev structure. When you
unregister input_dev class_simple_release will attempt to kfree()
memory occupied by class_device which is bad because it was never
kalloc()ated.

For now, if you continue using class_simple (which is I believe right
solution for now, we have issues with lifetime rules there and it will
take time to resolve everything), you need to dynamically allocate
class_device for input_dev (change cdev to *cdev).

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.033 / U:4.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site