All of lore.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 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.