Messages in this thread | | | Date | Wed, 2 May 2012 11:45:15 +0100 | From | Alan Cox <> | Subject | Re: Killing the tty lock |
| |
> 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?
We need to take locks on a pair of tty devices at the same time in some cases (pty/tty pairs).
> 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?
You don't need to. The point is that we must lock any arbitrary pair of tty structs in a defined order. Pointer comparisons work just fine for this. The fs layer uses similar logic for inode locking. We only care that for any given pair of objects the lock ordering is consistent.
Alan
| |