lkml.org 
[lkml]   [2012]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Killing the tty lock
On Tue, May 01, 2012 at 05:37:39PM +0100, Alan Cox wrote:
> This is a first stab at it by making the lock per tty and using tty_mutex
> to cover the lookup for now. We ought to move to the lookup handing back
> ttys with a ref but thats a further step.
>
> It seems to mostly work but not quite reliably, so coul do with some more
> eyes and review for ideas.

It's mostly pretty "sane", but what is this:

> +/*
> + * Getting the big tty mutex for a pair of ttys with lock ordering
> + * On a non pty/tty pair tty2 can be NULL which is just fine.
> + */
> +void __lockfunc tty_lock_pair(struct tty_struct *tty,
> + struct tty_struct *tty2)
> +{
> + if (tty < tty2) {
> + tty_lock(tty);
> + tty_lock(tty2);
> + } else {
> + if (tty2 && tty2 != tty)
> + tty_lock(tty2);
> + tty_lock(tty);
> + }
> +}
> +EXPORT_SYMBOL(tty_lock_pair);
> +
> +void __lockfunc tty_unlock_pair(struct tty_struct *tty,
> + struct tty_struct *tty2)
> +{
> + tty_unlock(tty);
> + if (tty2 && tty2 != tty)
> + tty_unlock(tty2);
> +}
> +EXPORT_SYMBOL(tty_unlock_pair);

for?

And what's with the comparing of pointers as "<"? How portable is that
really, and how are we supposed to control the memory location of these
structures?

thanks,

greg k-h


\
 
 \ /
  Last update: 2012-05-02 09:21    [from the cache]
©2003-2011 Jasper Spaans