muller@sdcc10.ucsd.edu (Keith Muller) (05/09/91)
There are two different problems with ttys being discussed wrt Dan. Not all the problems can be traced back to poor implementations of the controlling tty device. For a moment stop thinking of ways that exploit THAT bug and have an open mind. This all started when I pointed out that blocking access to a a tty because there is a valid reference to it is an overkill in solving a specific type of problem. To quote from that first posting: "In simple terms a major problem with ttys has always been the semantics of the revocation of access rights to a tty (pseudo or real). The difficulty is created by both "valid" processes and "revoked" processes sharing access to common data structures (inode and device tty structures) and the routines which implement tty semantics." The problem being addressed here are sleeping processes which still retain access rights when they are down in the tty routines. They do NOT HAVE TO OPEN THE CONTROLLING TTY to get these rights. Log onto two ports open a few file descriptors, stop a few processes, log off a tty... and you get the idea (the setting of the controlling tty is not an issue here, processes BLOCKED before completing the operation and after the access checks are made IS THE PROBLEM). The result is that sleepers when they resume execution get to complete the operation they were blocked on regardless of any change done in access to the actual device while they were sleeping. Processes (including the bad guy) can directly reference the same device (going indirectly through the controlling tty device is not needed). In several postings I have described two methods directed at THIS problem: a vhangup() based approach for machines that use that and a generation based approach which is what is used in 4.3 reno and later to address THIS problem. Several vendors have (or are) addressed the controlling tty bug by sessions access (such as revoking session access to the controlling tty as done by one vendor). However the vendor techniques we have seen here (so far) for fixing controlling ttys have not yet solved the sleeper issue. So it still needs to be considered, which is why I brought it up. (as dan points out the machines I use have fixed much of the controlling tty bug, but we did have to address those sleepers). Yes dan's solution avoids the sleepers problem by never using that tty until the sleepers go away (which may be never). I would rather use a direct approach which allows tty reuse (FOR THIS PROBLEM). ------- flame on ---- I didn't say "all" problems, but "a" major problem (note the singular). I didn't say "do this and all you tty problems are solved". "I didn't say don't run Dans package as this is all you have to do". I did say here is a problem with "sharing common data structures (inode and device)" that can be simply solved DIRECTLY (to allow reuse of the device for a specific shared access problem) without the potential for blocking access to the device forever. I do feel that dans method requires way too complexity in the user process, and the kernel should be doing that. But that is an opinion. I also do not want to force hardware ports through ptys in order to use them (a poor 1 mip box can handle 32 hardwired ports but add 32 active ptys and you have one slow machine). Dan complained I was too vague for him to implement a fix. It is a fine line between giving out information without creating complaints about posting code on how to attack some phase of the system. The vendors I talked to knew exactly what was going on and went off to fix it. I had hoped that describing a technique with words like "sleepers resume execution.." would be enough. I do worry that I may have said too much in this posting. I really suspect that this is an old problem, but when it kept cropping up even after the controlling tty bug was being addressed it wasn't clear what was happening. When Dan went on about ttys operation not going through the open file table and checks "are not done". I did not immediately equate this to the controlling tty bug. I focused on the "does not go through the open file table" statement which is technically misleading (when looking at the path a system call makes on a fd at entry to the kernel the open file table (in the source we have here) is always gone through. I suspect dan was referring to later jumps into the tty by the controlling tty device after testing the access to the controlling tty device). Yes I looked at too much source and got the names of the variables used for the controlling terminal confused but until I realized we were talking apples and oranges, the significance wasn't there. For this slowness I do apologize to the net. In retrospect had the statement been a bit more direct like: "that this fails to handle the case where f_data does not point at the tty inode but points at the the controlling tty device inode which makes your technique miss clearing f_flags.....", I would have seen we were talking about different (but very similar in effect) bugs. My error. Of course when much of a persons objection consists of "ad hominem" attacks, listening does becomes difficult :-). Oh well. In the interest of stopping this (instead of posting rebuttals to all of Dans attacks etc; it has already gotten blown way out proportion), lets take further comments and attacks on this topic offline to e-mail. Keith Muller University Of California