From: Peter Hurley <peter@hurleysoftware.com>
To: Alexander Holler <holler@ahsoftware.de>
Cc: linux-kernel@vger.kernel.org, Jiri Slaby <jslaby@suse.cz>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Marcel Holtmann <marcel@holtmann.org>,
Gustavo Padovan <gustavo@padovan.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
linux-bluetooth@vger.kernel.org
Subject: Re: BUG: tty: memory corruption through tty_release/tty_ldisc_release
Date: Thu, 16 May 2013 09:47:44 -0400 [thread overview]
Message-ID: <5194E380.1030109@hurleysoftware.com> (raw)
In-Reply-To: <519480A1.6030909@ahsoftware.de>
On 05/16/2013 02:45 AM, Alexander Holler wrote:
> Hello,
>
> after some pain because the "big step" (ecbbfd4) happened while the support for my AMD CPU was broken and thus git bisect hit a series of kernels which didn't boot, I've finally found the cause for a memory corruption: tty_ldisc_release().
>
> What happens is the following:
>
> tty_port is self-destructing, that means it destroys itself in tty_port.c:tty_port_destructor() when the last reference is gone. E.g. in case of rfcomm this happens with the call to tty->ops->close() in tty_io.c:tty_release().
>
> The problem here is that tty_io.c:tty_release() calls tty_ldisc.c:tty_ldisc_release() which uses the tty_port to flush the ldisc work queues.
>
> In the best case this hits a BUG() in cancel_work_sync() but often it just causes a memory corruption without a BUG() got hit before.
Hi Alexander,
Actually, the problem is that tty->ops->close() shouldn't be
the last kref on the port.
It doesn't look to me like device removal is being handled
properly.
Regards,
Peter Hurley
next prev parent reply other threads:[~2013-05-16 13:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-16 6:45 BUG: tty: memory corruption through tty_release/tty_ldisc_release Alexander Holler
2013-05-16 13:15 ` Alexander Holler
2013-05-16 13:47 ` Peter Hurley [this message]
2013-05-16 13:59 ` Alexander Holler
2013-05-16 21:53 ` Peter Hurley
2013-05-17 4:43 ` Alexander Holler
2013-05-17 7:12 ` [PATCH] tty: make sure a BUG is hit if tty_port will be destroyed before tty Alexander Holler
2013-05-17 15:31 ` Greg Kroah-Hartman
2013-05-17 16:41 ` Alexander Holler
2013-05-17 18:06 ` Peter Hurley
2013-05-17 19:22 ` Alexander Holler
2013-05-17 19:43 ` Alexander Holler
2013-05-17 22:51 ` Peter Hurley
2013-05-17 23:41 ` Alexander Holler
2013-06-25 14:18 ` BUG: tty: memory corruption through tty_release/tty_ldisc_release Dean Jenkins
2013-06-26 7:23 ` Alexander Holler
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=5194E380.1030109@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo@padovan.org \
--cc=holler@ahsoftware.de \
--cc=johan.hedberg@gmail.com \
--cc=jslaby@suse.cz \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.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.