Re: frequent slab corruption (since a long time)

From: David Miller
Date: Wed Aug 02 2006 - 18:47:50 EST

From: Dave Jones <davej@xxxxxxxxxx>
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

* 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().

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at