From: Grant Edwards <grant.b.edwards@gmail.com>
To: linux-serial@vger.kernel.org
Subject: Are calls to open()/close() serialized by tty layer?
Date: Wed, 16 Jan 2013 20:07:49 +0000 (UTC) [thread overview]
Message-ID: <kd71al$c78$1@ger.gmane.org> (raw)
Are calls to a tty driver's open()/close() methods serialized by the
tty layer? If so, has this always been the case?
I'm working on converting an old tty driver over to using the "new"
tty_port_* functions and the standard "struct tty_port" port data
structure.
[I thought about converting it to a uart driver for serial_core, but
AFAICT, that API doesn't provide any way to return errors for
userspace open() and write() calls and would therefore break my
user-land API.]
>From looking at example tty drivers in the 3.7.2 source tree, it
appears that they assume calls to open()/close() are serialized.
The old driver I'm working on had its own internal locking to protect
race conditiions when incrementing and decrementing of a port's open
count. That counter is being prelaced by tty->port->count, and in
existing in-kernel tty drivers it doesn't look like there is any
locking when that count is incremented during an open().
For example, from rocket.c:
891 static int rp_open(struct tty_struct *tty, struct file *filp)
892 {
[...]
924 tty->driver_data = info;
925 tty_port_tty_set(port, tty);
926
927 if (port->count++ == 0) {
928 atomic_inc(&rp_num_ports_open);
929
930 #ifdef ROCKET_DEBUG_OPEN
931 printk(KERN_INFO "rocket mod++ = %d...\n",
932 atomic_read(&rp_num_ports_open));
933 #endif
934 }
If calls to open()/close() aren't serialized, then line 927 would
cause a race condition...
--
Grant Edwards grant.b.edwards Yow! Everybody gets free
at BORSCHT!
gmail.com
next reply other threads:[~2013-01-16 20:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-16 20:07 Grant Edwards [this message]
2013-01-16 22:44 ` Are calls to open()/close() serialized by tty layer? Alan Cox
2013-01-16 23:07 ` Grant Edwards
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='kd71al$c78$1@ger.gmane.org' \
--to=grant.b.edwards@gmail.com \
--cc=linux-serial@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.