Re: Killing the tty lock

[Alan Cox]

> 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
--
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/