linux-kernel - Re: [PATCH 10/13] tty: untangle locking of wait_until

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 5 May 2010 23:31:03 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org, Greg KH <gregkh@...e.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	John Kacur <jkacur@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 10/13] tty: untangle locking of wait_until_sent

On Wednesday 05 May 2010 21:59:05 Alan Cox wrote:
> > Some wait_until_sent versions require the big
> > tty mutex, others don't and some callers of
> > wait_until_sent already hold it while other don't.
> > That leads to recursive use of the BTM in these
> > functions, which we're trying to get rid of.
> 
> I don't believe any of the currently live ones do.

Ok, that simplifies things, at least we can call
tty->ops->wait_until_sent(tty, timeout) while holding
the BTM then, even with the next patch that makes it
non-recursive.

> >  drivers/char/hvc_console.c    |    2 +-
> >  drivers/char/hvcs.c           |    2 +-
> 
> Doesn't seemn to need it

These, and most of the others in this patch call tty_wait_until_sent()
from their close() function. That contains the lines

        if (wait_event_interruptible_timeout(tty->write_wait,
                        !tty_chars_in_buffer(tty), timeout) >= 0) {

Part of what my patch does is to give up the BTM when already
holding it, to mimic the BKL behavior.
If you can confirm that this wait_event never blocks indefinitely
or has to wait for the BTM from another function, that could just
be removed. Otherwise, it probably needs to become something ugly
like

	if (tty_chars_in_buffer(tty)) {
		if (tty_locked()) {
			tty_unlock();
			wait = wait_event_interruptible_timeout(tty->write_wait,
	                        !tty_chars_in_buffer(tty), timeout) >= 0);
			tty_lock();
		} else {
			wait = wait_event_interruptible_timeout(tty->write_wait,
	                        !tty_chars_in_buffer(tty), timeout) >= 0);
		}
		if (wait && tty->ops->wait_until_sent)
			tty->ops->wait_until_sent(tty, timeout);
	}

I already had to introduce a few of these constructs to make the BTM
non-recursive, but I'd prefer to keep the number as low as possible
for obvious reasons.

> >  drivers/char/specialix.c      |    2 +-
> 
> Broken

> This makes me think that now might be a good time to consign the broken
> crap to the bitbucket unless someone stands up with hardware and who
> wants to maintain it.

Fine with me.
While I technically own a 16-port specialix card somewhere in my
parents' basement, I'm not exactly interested in maintaining the
driver.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/