public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Zephaniah E. Hull" <warp@aehallh.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org
Subject: Re: [patch] Crash on evdev disconnect.
Date: Mon, 7 Aug 2006 14:10:43 -0400	[thread overview]
Message-ID: <20060807181043.GA5476@aehallh.com> (raw)
In-Reply-To: <d120d5000608071035k2ec5b4ffu949a99ad4a8c3d66@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On Mon, Aug 07, 2006 at 01:35:50PM -0400, Dmitry Torokhov wrote:
> Hi,
> 
> On 8/7/06, Zephaniah E. Hull <warp@aehallh.com> wrote:
> >       if (evdev->open) {
> >               input_close_device(handle);
> >               wake_up_interruptible(&evdev->wait);
> >-               list_for_each_entry(list, &evdev->list, node)
> >+               list_for_each_entry_safe(list, next, &evdev->list, node)
> >                       kill_fasync(&list->fasync, SIGIO, POLL_HUP);
> 
> NAK. kill_fasync does not affect the list state so using _safe does
> not buy us anything.

Sorry, but you're wrong.

Immediately before the kill_fasync call list->node.next is a valid
pointer, immediately afterwords it is 0x100100, which happens to be
list_poison.  kill_fasync is triggering a close somehow, evdev_close
deletes that element of the list, which poisons the next value, which
can make us crash and burn.

I have a 100% reproducible crash case, which is fixed by the change.

If kill_fasync shouldn't be making it close that's another issue, but at
the moment it is and this is a fairly non-invasive change which fixes
it.

> 
> BTW, dtor_core@ameritech.net address is dead, please use
> dmitry.torokhov@gmail.com or dtor@mail.ru or dtor@isightbb.com.

Noted, recommend updating the entry in MAINTAINERS. :)

Zephaniah E. Hull.

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

> Is there an API or other means to determine what video
> card, namely the chipset, that the user has installed
> on his machine?

On a modern X86 machine use the PCI/AGP bus data. On a PS/2 use the MCA bus
data. On nubus use the nubus probe data. On old style ISA bus PCs done a large
pointy hat and spend several years reading arcane and forbidden scrolls

 -- Alan Cox

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2006-08-07 18:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-07 15:59 [patch] Crash on evdev disconnect Zephaniah E. Hull
2006-08-07 17:35 ` Dmitry Torokhov
2006-08-07 18:10   ` Zephaniah E. Hull [this message]
2006-08-07 19:04     ` Dmitry Torokhov
2006-08-07 19:41       ` Zephaniah E. Hull

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=20060807181043.GA5476@aehallh.com \
    --to=warp@aehallh.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.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