Thread (6 messages) 6 messages, 2 authors, 2008-04-08

Re: Patch for oops in a grabbed evdev after disconnect

From: Pete Zaitcev <zaitcev@redhat.com>
Date: 2008-03-21 17:55:54

On Tue, 18 Mar 2008 14:54:17 -0400, Dmitry Torokhov [off-list ref] wrote:

I'm sorry, but I'm weak. I'll have to poke Greg (to cc:), although
I know he's pretty busy, but I don't grok sysfs and kobjects. So:
quoted
quoted
quoted
If a device was grabbed through evdev and then became disconnected,
we oops on close. This happens because input_release_device uses memory
which was freed.
quoted
Could you tell me what memory is freed?
The input_dev is freed. [...]
quoted
quoted
[] As far as I understand the
the input_dev structure shold be pinned in memory by the driver
core since we have this link:

	evdev->dev.parent = &input_dev->dev;

This should guarantee that input_device is not gone until we
call evdev_free which should be done way after the ungrab.
I don't think anyone checks this, unless the accompaining refcount
is set.
I dont oppose your patch, I am just trying to understand why it
is needed because driver core should pin the parent device as
far as I understand and if this does not happen there are other
issues in input core that need to be taken care of.

From what I see we should be automatically taking the reference
to parent kobject in

kobject_add_internal():
	parent = kobject_get(kobj->parent);

perent is set in kobject_add_varg():
	kobj->parent = parent;

.. which is called from kobject_add() which is called from
device_add().
Hmm, I see it now. OK.
Hmm, I wonder if obsolete sysfs links mess up proper parenting
data... I dont think I have obsolete links set up on any of my
boxes, can you see if oops goes away if you disable deprectated
sysfs? If so then instead of checking exist flag we need explicitely
take reference to the parent input_dev. []
I'll check this.

-- Pete
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help