From: Arjan van de Ven <arjan@linux.intel.com>
To: "Björn Steinbrink" <B.Steinbrink@gmx.de>
Cc: Greg KH <greg@kroah.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Johannes Berg <johannes@sipsolutions.net>,
Jiri Kosina <jkosina@suse.cz>
Subject: Re: [PATCH] evdev: Release eventual input device grabs when getting disconnected
Date: Sun, 30 Mar 2008 16:19:16 -0700 [thread overview]
Message-ID: <47F01FF4.2010307@linux.intel.com> (raw)
In-Reply-To: <20080330224203.GA22498@atjola.homenet>
Björn Steinbrink wrote:
> On 2008.03.30 15:22:28 -0700, Greg KH wrote:
>> On Sun, Mar 30, 2008 at 02:51:02PM -0700, 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?
>> Earlier? No, not that I know of at all, as long as the reference
>> counting logic was correct originally. All of the problems we have been
>> fixing were ones where we accidentally were grabbing too many references
>> and then wondering why things were not getting cleaned up properly as
>> the kobject rework exposed these problems making them more obvious.
>
> Not freeing the input device at all would of course also hide any
> access-after-free problems :-) So if that's the case, that might explain
> the sudden exposure of the problem. IMHO, my patch is the right thing to
> do anyway, because releasing a grab on the underlying input device from
> within evdev clearly needs to happen before we release that device. So
> AFAICT we're really just looking for "why do we see that bug now?" and
> "is there another bug?"
>
>> I haven't heard of the opposite happening. Anything that I can try to
>> test for here, I have a lot of removable input devices to test with.
>
> Sorry, forgot to set the In-Reply-To header when sending the patch. The
> original thread, with a reproducing recipe is here:
> http://lkml.org/lkml/2008/3/28/442
> Message-Id: <1206742499.22530.90.camel@johannes.berg>
>
one note.. you do want to enable slab poison, just to catch the bug right away...
next prev parent reply other threads:[~2008-03-30 23:24 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 [this message]
2008-03-31 20:46 ` Dmitry Torokhov
2008-03-31 6:15 ` Dmitry Torokhov
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=47F01FF4.2010307@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=B.Steinbrink@gmx.de \
--cc=dmitry.torokhov@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.