Re: frequent slab corruption (since a long time)

[David Miller]

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
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/