From: Peter Hurley <peter@hurleysoftware.com>
To: David Miller <davem@davemloft.net>
Cc: sasha.levin@oracle.com, samuel@sortiz.org,
gregkh@linuxfoundation.org, jslaby@suse.cz,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ircomm: release tty before sleeping potentially indefintely
Date: Sun, 03 Mar 2013 20:06:18 -0500 [thread overview]
Message-ID: <1362359178.3221.118.camel@thor.lan> (raw)
In-Reply-To: <20130303.193313.408641189137321065.davem@davemloft.net>
On Sun, 2013-03-03 at 19:33 -0500, David Miller wrote:
> From: Peter Hurley <peter@hurleysoftware.com>
> Date: Sun, 03 Mar 2013 19:04:25 -0500
>
> > All these are re-tested in the loop. What state test isn't repeated?
>
> One that rechecks the non-blocking filp flag, the
> TTY_IO_ERROR tty flag and the termios settings.
>
> Like I said, all of the state tests performed at the beginning of
> this function, before enterring the loop.
How is O_NONBLOCK going to change? This function is sitting on the
user-space open.
The filp parameter is only on this task stack. It hasn't been linked in
anywhere else. Because of course the file isn't open yet because this
function hasn't returned success.
The TTY_IO_ERROR flag is used by drivers (this one included) to turn
away concurrent reads and writes when shutting down. The tty core does
not set this. Now this driver might set this, if commanded to hangup via
ircomm_tty_hangup, but like I said that's already handled in the loop
by testing tty_hung_up_p.
The initial termios setting cflag settings are set by the driver open().
In this driver, its here:
driver->init_termios = tty_std_termios;
driver->init_termios.c_cflag = B9600 | CS8 | CREAD | HUPCL | CLOCAL;
Now, it's possible that one could construct an imaginary race, where the
tty has already been opened and that task now sets the termios without
CLOCAL and meanwhile a second task is racing this termios setting with
an open() of its own, but since there is no expectation from userspace
that those operations are serialized, there's no reason to serialize
them here.
But regardless, this function __cannot__ sleep holding the tty_lock().
Regards,
Peter Hurley
next prev parent reply other threads:[~2013-03-04 1:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-03 22:35 [PATCH] ircomm: release tty before sleeping potentially indefintely Sasha Levin
2013-03-03 22:47 ` David Miller
2013-03-03 23:17 ` Sasha Levin
2013-03-04 0:31 ` David Miller
2013-03-04 0:04 ` Peter Hurley
2013-03-04 0:33 ` David Miller
2013-03-04 1:06 ` Peter Hurley [this message]
2013-03-04 2:36 ` David Miller
2013-03-04 4:24 ` Peter Hurley
2013-03-05 16:09 ` [PATCH 0/4] other ircomm_tty fixes (was Re: [PATCH] ircomm: release tty before sleeping potentially indefintely) Peter Hurley
2013-03-05 16:09 ` [PATCH 1/4] net/irda: Fix port open counts Peter Hurley
2013-03-05 16:09 ` [PATCH 2/4] net/irda: Hold port lock while bumping blocked_open Peter Hurley
2013-03-05 16:09 ` [PATCH 3/4] net/irda: Use barrier to set task state Peter Hurley
2013-03-05 16:09 ` [PATCH 4/4] net/irda: Raise dtr in non-blocking open Peter Hurley
2013-03-06 4:44 ` [PATCH 0/4] other ircomm_tty fixes David Miller
2013-03-04 4:30 ` [PATCH] ircomm: release tty before sleeping potentially indefintely Peter Hurley
2013-03-04 2:23 ` Peter Hurley
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=1362359178.3221.118.camel@thor.lan \
--to=peter@hurleysoftware.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=samuel@sortiz.org \
--cc=sasha.levin@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox