You want to be able to compile the X-server on machines where the
VT_SETMODE call has extra elements in the structure that the X-server
doesn't know about. (TC_GETATTR is a better example of this mode of
operation - there are lots of flags that applications don't, and
shouldn't, know about, so they get the structure, change the flags
that they know about, and write the result back.)
A second reason for wanting it is simply that VT_GETMODE might be used
for other reasons (eg. to for the superuser to find out what's
controlling each console). VT_GETMODE cannot be used safely and it's
easy to fix.
> > Are you indending to address the reliable VT_ACTIVATE issue?
> > At the moment, VT_WAITACTIVE sits inside a loop in vt.c until the
> > right VT is selected.
>
> Do you see any problem with it? It seems to me that current
> implementation is pretty much ok. Yes, you are right, it is possible
> to get few unneccessary wakeups each time console is toggled, so you
> have unneccessary overhead of 4 or so schedules [worst case]. Does it
> looks like problem to you?
The problem is not the number of context switches; the problem is that
VT_ACTIVATE gets lost, so VT_WAITACTIVE never returns (or at least not
until the user changes VT manually).
What I'm asking for is a function like vt_waitactive, but that in the
loop you have:
a) test for the correct VT being selected and return 0,
b) test for signals, and return EINTR,
c) check that the VT is still allocated, and reallocate it if neccessary,
d) call set_console to reselect that VT, and
e) go back to sleep.
This way, if the VT_ACTIVATE gets lost, it doesn't matter because you
reselect that VT again when you are next scheduled.
> > (IMHO, VT_WAITACTIVE should return 0 if fg_console==arg, even if
> > vt_waitactive returns -1 since it has acheived its goal of changing VT.)
Sorry, my mistake - when I wrote the above, I must have been reading
the 2.0 source - 2.1 gets it right.
> vt_waitactive could return -1 only because there is signal
> pendig.
No - you return -1 if there is a signal pending *and* you are on the
wrong console.
Re: your security patch
It can be improved by changing kill_proc to send_sig_info (since
you've already found the process from the pid), and by moving it into
the section with the tasklist locked, but...
Since you are recording the pid associated with the VT anyway, you can
reset the VT mode back to VT_AUTO in do_exit - that way you never have
the situation where the VT can send a signal to a pid that doesn't
exist and you've removed the race condition altogether.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu