From: Dave Jones <[email protected]>
Date: Wed, 2 Aug 2006 18:23:21 -0400
> None of the code manipulating tty->count seems to be under
> the tty_mutex. Should it be ?
> Or is this protected through some other means?
It is in the primary code paths at least, all callers of init_dev()
(which increments tty->count) grab the mutex and also release_dev()
grabs the mutex around tty->count manipulations.
I'm surprised that when this triggers we don't get one of these
two messages:
if (pty_master) {
if (--o_tty->count < 0) {
printk(KERN_WARNING "release_dev: bad pty slave count "
"(%d) for %s\n",
o_tty->count, tty_name(o_tty, buf));
o_tty->count = 0;
}
}
if (--tty->count < 0) {
printk(KERN_WARNING "release_dev: bad tty->count (%d) for %s\n",
tty->count, tty_name(tty, buf));
tty->count = 0;
}
However, there seems to be some kind of dependency of TTY opennings
holding the BKL, as least as far as this comment on con_close() is
concerned:
/*
* tty_mutex is released, but we still hold BKL, so there is
* still exclusion against init_dev()
*/
But it is not clear to me that tty_open() and ptmx_open() always run
with the BKL held. chrdev_open() wraps the ->open call with the BKL
held, but then it plugs in the device's fops which should allow a
direct filp->fops->open() call from the VFS layer without the BKL
grabbing right?
chrdev_open() should catch /dev/foo char device opens, but what about
the sysfs instances? They might bypass this path too somehow, thus
another case where the BKL won't be held on open().
Hmmm...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
