public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor@insightbb.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Bj?rn Steinbrink <B.Steinbrink@gmx.de>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Jiri Kosina <jkosina@suse.cz>, Greg KH <greg@kroah.com>
Subject: Re: [PATCH] evdev: Release eventual input device grabs when getting disconnected
Date: Mon, 31 Mar 2008 02:15:39 -0400	[thread overview]
Message-ID: <200803310215.39414.dtor@insightbb.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0803301448190.14670@woody.linux-foundation.org>

Hi Linus,

On Sunday 30 March 2008, Linus Torvalds wrote:
> 
> On Sun, 30 Mar 2008, Bj?rn Steinbrink wrote:
> >
> > I can't reproduce the bug on my UP box and currently can't afford
> > crashing my SMP box (all the oopses seem to come from SMP kernels, so I
> > guess it needs SMP to crash), so while this doesn't show any new
> > problems, I can't tell whether it actually fixes anything. Testers
> > welcome!
> 
> Ok, I applied this because I will do an -rc8 today or tomorrow, but I 
> really really hope somebody can figure out what made this all start to 
> trigger. It does smell like some core device layer change, because we do 
> not seem to have a lot of changes since 2.6.24 in evdev.c and input.c that 
> seem relevant.
> 
> Greg, are there any refcounting changes that would cause the input devices 
> to be free'd earlier or something?
> 

The following commit changed lifetime runes on kobjects breaking input:

commit 0f4dafc0563c6c49e17fe14b3f5f356e4c4b8806
Author: Kay Sievers <kay.sievers@vrfy.org>
Date:   Wed Dec 19 01:40:42 2007 +0100

    Kobject: auto-cleanup on final unref

    We save the current state in the object itself, so we can do proper
    cleanup when the last reference is dropped.

    If the initial reference is dropped, the object will be removed from
    sysfs if needed, if an "add" event was sent, "remove" will be send, and
    the allocated resources are released.

    This allows us to clean up some driver core usage as well as allowing us
    to do other such changes to the rest of the kernel.

    Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Before we dropped reference to kobject's parent only when child kobject
was released (in kobject_cleanup). The changeset above moves the release
to kobject_del() which is way too early in my opinion. The kobject is only
marked for deletion at that time, not really deleted.

I will look how to properly fix evdev and the rest of input interfaces
tomorrow.

-- 
Dmitry

  parent reply	other threads:[~2008-03-31  6:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-30 18:42 [PATCH] evdev: Release eventual input device grabs when getting disconnected Björn Steinbrink
2008-03-30 21:51 ` Linus Torvalds
2008-03-30 22:22   ` Greg KH
2008-03-30 22:35     ` Linus Torvalds
2008-03-30 22:42     ` Björn Steinbrink
2008-03-30 23:19       ` Arjan van de Ven
2008-03-31 20:46       ` Dmitry Torokhov
2008-03-31  6:15   ` Dmitry Torokhov [this message]
2008-03-31 17:28     ` Greg KH
2008-03-31 18:01       ` Dmitry Torokhov
2008-03-31 18:24         ` Linus Torvalds
2008-03-31 23:12           ` Benjamin Herrenschmidt
2008-03-31 23:51             ` Greg KH
2008-04-01  1:01               ` Benjamin Herrenschmidt
2008-03-31 20:42         ` Greg KH
2008-03-31 20:57           ` Dmitry Torokhov
2008-03-31 22:09             ` Greg KH
2008-04-01  3:30               ` Dmitry Torokhov
2008-03-31 21:27           ` Jiri Kosina
2008-03-31 22:46             ` Kay Sievers
2008-03-31 20:21   ` Johannes Berg
2008-03-31 19:05 ` Björn Steinbrink
2008-04-01 11:51   ` Johannes Berg
2008-04-01 15:20     ` Björn Steinbrink
2008-04-02  9:17       ` Johannes Berg
2008-03-31 21:02 ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200803310215.39414.dtor@insightbb.com \
    --to=dtor@insightbb.com \
    --cc=B.Steinbrink@gmx.de \
    --cc=arjan@linux.intel.com \
    --cc=greg@kroah.com \
    --cc=jkosina@suse.cz \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox