Message-ID: <20110223000958.7c18fdef@lxorguk.ukuu.org.uk>
Date:	Wed, 23 Feb 2011 00:09:58 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Greg KH <greg@...ah.com>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Lennart Poettering <lennart@...ttering.net>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] tty: add TIOCVHANGUP: time for revoke() in f_ops ?

> You could do that already today with the vhangup() syscall, right?

Yes - hence the permission checks are excessive right now.

> > You would still need to be very careful how you used it from the admin
> > side because the parallel
> > 
> > 	CPU1					CPU2
> > 	vhangup()				chmod()
> > 	process vhangup
> > 	return
> > 	chown to user1
> > 						chmod to 777
> > 						syscall ends (fd
> > 						revocation takes effect)
> > 
> > 	Oops, 0wned
> > 
> > case is not handled by the paths you are using. So to actually do this
> > you need rather more infrastructure work to ensure the existing calls
> > have completed before returning.
> 
> But wouldn't this race still happen no matter if vhangup() is in the mix
> or not?  I don't see how adding this ioctl changes anything here, what
> am I missing?

The current users actually handle this - mostly by accident partly by
their nature.

> It's not a "real" revoke, more like vhangup(file_descriptor) only.
> revoke() involves a lot more than just this.

Real revoke is no different. General purpose real revoke for arbitary
objects is a nightmare - but guess what *NO* Unixalike implements that.
 
> > I'd guess you need to add a counter to the tty f_ops entry/exit points to
> > know when that occurs, and wake_up the revoke path when ready
> > (remembering two revokes in parallel shouldn't deadlock! so need
> > counting too)
> 
> Again, I'm confused, how does the locking differ from vhangup() today?

Our vhangup users are not under the delusion that the interface is race
free. Really it wants fixing anyway, but exposing the race with an
inviting new way to screw up isn't good - and the usage model of
vhangup(fd) is such that you can't actually use the ABI for anything
interesting without fixing it.

Also vhangup(fd) with the bug fixed *IS* revoke() so lets stop pretending
it isn't. It's far better to add revoke to the VFS at this point and wire
that to the vhangup + race fixes code that has to be done anyway. In fact
I think it has to be done at that level ultimately to make sure any open
versus hangup races are caught.

It's a new file op to which everyone else (for now) says NULL = no can
do. Really for desktop switching we also want it for some other devices,
so the infrastructure is needed anyway.

revoke is hard, vhangup(fd) is revoke, the rest inevitably follows, but
once it's done then you can add it to a few other cdevs and do all the
nice desktop switching stuff right as well.

It's basically 3 things
- Lennarts bits for vhangup on an fd
- A revoke vfs op
- Counting people in and out of the tty syscalls - which is a hit but its
  not gigabit stuff so won't hurt. Again very easy to implement, and if
  it causes performance corner cases on 4000 CPU boxes smart people can
  fix it later for that. We should do this one anyway
- Ideally dealing with parallel open/revoke paths, which needs the cdev
  code involved

Its not a quick patch - that's why its not happened yet, vhangup(fd)
quickfix Lennart style is unfortunately a useless bodge job which like
most bodge jobs is simply going to spring leaks and need fixing again.

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

Powered by blists - more mailing lists