From: Jiri Slaby <jirislaby@gmail.com>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Jiri Slaby <jslaby@suse.cz>,
gregkh@suse.de, linux-kernel@vger.kernel.org,
Sukadev Bhattiprolu <sukadev@us.ibm.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
hpa@zytor.com
Subject: Re: [PATCH 4/4] TTY: call tty_driver_lookup_tty unconditionally
Date: Sun, 16 Oct 2011 21:37:46 +0200 [thread overview]
Message-ID: <4E9B328A.3030508@gmail.com> (raw)
In-Reply-To: <20111016192057.GB14883@us.ibm.com>
Fixing Alan's address. Somehow I put there a RH (defunct) one.
On 10/16/2011 09:20 PM, Sukadev Bhattiprolu wrote:
> Jiri Slaby [jirislaby@gmail.com] wrote:
> | On 10/12/2011 11:32 AM, Jiri Slaby wrote:
> | > Commit 4a2b5fddd5 (Move tty lookup/reopen to caller) made the call to
> | > tty_driver_lookup_tty conditional in tty_open. It doesn't look like it
> | > was an intention. Or if it was, it was not documented in the changelog
> | > and the code now looks weird. For example there would be no need to
> | > remember the tty driver and tty index. Further the condition depends
> | > on a tty which we drop a reference of already.
> | >
> | > If I'm looking correctly, this should not matter thanks to the locking
> | > currently done there. Thus, tty_driver->ttys[idx] cannot change under
> | > our hands. But anyway, it makes sense to change that to the old
> | > behaviour.
> |
> | Well, this doesn't work for ptys. devpts lookup code expects an inode to
> | be one of devpts filesystem (/dev/pts/*), not something on tmpfs like
> | /dev/tty. So it looks like the change was intentional, but very
> | undocumented and leaving there some unused code.
>
> Yes this was intentional - even though the tty_driver_lookup() was
> unconditional in tty_init_dev() I believe it did not do anything useful
> when called from ptmx_open(). ptmx_open() would be setting up a new pty and
> the lookup would not find a tty.
Yes, I'm not arguing against moving the code from tty_init_dev to
tty_open change. That is perfectly OK.
What I mind is that now we do:
=====
tty = get_current_tty();
if (!tty)
return -ENXIO;
driver = tty_driver_kref_get(tty->driver); /* ZZZ */
index = tty->index; /* ZZZ */
...
tty_kref_put(tty); /* XXX */
goto got_driver;
...
got_driver:
if (!tty) { /* YYY */
}
=====
But at the point of YYY, the tty may be invalid due to reference drop at
XXX. I *hope* it is not the case thanks to the current locking there
(namely BTM) but I'm really *not sure*. And if it is the case, there
should definitely be a note. (Or better the reference should be held
while necessary.)
> Would the following change to tty_open() help ?
No, it doesn't matter now. I would prefer a description of the change to
be a part of the commit log. And it missed such a notice.
> I am not sure about the unused code you refer to above. Can you please
> clarify ?
It is index and driver assigned in the branch above (see ZZZ). When we
have a live tty (which I'm not sure we have -- see above), it is
guaranteed that the driver is reff'ed. And we need neither driver nor
index when we have such a tty.
thanks,
--
js
next prev parent reply other threads:[~2011-10-16 19:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-04 20:05 NULL dereference in tty_open() Dan Carpenter
2011-10-05 14:22 ` NULL dereference in tty_open() [and other bugs there] Jiri Slaby
2011-10-12 9:32 ` [PATCH 1/4] TTY: drop driver reference in tty_open fail path Jiri Slaby
2011-10-12 9:32 ` [PATCH 2/4] TTY: make tty_add_file non-failing Jiri Slaby
2011-10-12 9:32 ` [PATCH 3/4] TTY: pty, release tty in all ptmx_open fail paths Jiri Slaby
2011-10-12 13:23 ` Arnd Bergmann
2011-10-12 9:32 ` [PATCH 4/4] TTY: call tty_driver_lookup_tty unconditionally Jiri Slaby
2011-10-12 20:59 ` Jiri Slaby
2011-10-16 19:20 ` Sukadev Bhattiprolu
2011-10-16 19:37 ` Jiri Slaby [this message]
2011-10-16 18:28 ` [PATCH 1/4] TTY: drop driver reference in tty_open fail path Sukadev Bhattiprolu
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=4E9B328A.3030508@gmail.com \
--to=jirislaby@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=gregkh@suse.de \
--cc=hpa@zytor.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=sukadev@linux.vnet.ibm.com \
--cc=sukadev@us.ibm.com \
/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.