From: Jiri Slaby <jirislaby@gmail.com>
To: Jiri Slaby <jslaby@suse.cz>
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [PATCH 1/1] TTY: fix PTY hangup vs close race
Date: Sun, 19 Feb 2012 22:41:49 +0100 [thread overview]
Message-ID: <4F416C9D.3030302@gmail.com> (raw)
In-Reply-To: <1329686346-16752-1-git-send-email-jslaby@suse.cz>
On 02/19/2012 10:19 PM, Jiri Slaby wrote:
> Commit d3bda5298 (TTY: get rid of BTM around devpts_*) moved
> devpts_pty_kill out of BTM, but the BTM was not protecting only
> devpts_pty_kill, but also tty->link. Hence move the function back at
> this late stage until this gets resolved properly some time later.
>
> I was confused by tty_vhangup(tty->link) outside BTM. But inside of
> tty_vhangup, there is a check for tty == NULL. But we cannot add such
> a check here. We have to have the tty and free the devpts node...
>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Reported-by: Sasha Levin <levinsasha928@gmail.com>
> ---
>
> Gee, I messed up Greg's address again...
>
> drivers/tty/pty.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
> index fa1bd2e..95037aa 100644
> --- a/drivers/tty/pty.c
> +++ b/drivers/tty/pty.c
> @@ -54,8 +54,9 @@ static void pty_close(struct tty_struct *tty, struct file *filp)
> wake_up_interruptible(&tty->link->write_wait);
> if (tty->driver->subtype == PTY_TYPE_MASTER) {
> set_bit(TTY_OTHER_CLOSED, &tty->flags);
> - tty_unlock();
> + /* BTM protects tty->link here */
> devpts_pty_kill(tty->link);
> + tty_unlock();
I'm afraid this won't help. As this is based on an assumption that
tty->link is NULL [*] and that is not just true.
Greg, please revert commit d3bda5298 completely.
[*] Your dump reveals that the code fetches tty->driver_data (mov
0x428(%rdi),%rbx) and traps at a fetch of inode->i_sbm because inode is
NULL (mov 0x28(%rbx),%rax).
Anyway I'm still interested in the tool you triggered this, because we
will need to get rid of BTM eventually.
thanks,
--
js
next prev parent reply other threads:[~2012-02-19 21:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-19 20:36 TTY: NULL dereference when closing a pty file Sasha Levin
2012-02-19 21:08 ` [PATCH 1/1] TTY: fix PTY hangup vs close race Jiri Slaby
2012-02-19 21:10 ` TTY: NULL dereference when closing a pty file Jiri Slaby
2012-02-19 23:08 ` Sasha Levin
2012-02-19 21:19 ` [PATCH 1/1] TTY: fix PTY hangup vs close race Jiri Slaby
2012-02-19 21:41 ` Jiri Slaby [this message]
2012-02-20 10:20 ` Sasha Levin
2012-02-20 11:15 ` Jiri Slaby
2012-02-24 21:57 ` Greg KH
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=4F416C9D.3030302@gmail.com \
--to=jirislaby@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=levinsasha928@gmail.com \
--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.