Alan Cox wrote:
On Tue, Sep 26, 2006 at 04:08:40PM -0400, Adam Jackson wrote:
VT_WAITACTIVE only ever gets called from xf86OpenConsole, which is in
the server generation path (and _not_ in normal EnterVT, which is sort
of disturbing). This appears to only be possible to trigger during
server init, and specifically in the handoff from rhgb's X server to
gdm's.
That makes sense if the timing is ugly
Can this occur
rhgb X server -> decides to go away
gdm X server starts
gdm X server issues switch to screen
rhgb X server cleanup issues switch back to text mode screen
gdm X server waits for its screen
I think it can. I'm fairly sure gdm launches X while rhgb's server is
still active, since otherwise we wouldn't have to make sure rhgb got DRI
disabled (old unrelated bug where only one X server can have working DRI
at a time). And xf86CloseConsole will do:
1: KDSETMODE to KD_TEXT
2: VT_GETMODE
3: VT_SETMODE to VT_AUTO
4: VT_ACTIVATE to the VT that was current when the server started
So would the race look like:
rhgb X gdm X
VT_ACTIVATE 7
VT_ACTIVATE 1
VT_WAITACTIVE 7
?
Also does this ever occur without selinux ?
It doesn't appear to happen with selinux=0. Suspect that's more timing
than policy though.
- ajax
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list