[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rhgb freezing computer



Alan Cox wrote:
On Tue, Sep 26, 2006 at 04:43:26PM -0400, Adam Jackson wrote:
rhgb X				gdm X
				VT_ACTIVATE 7
VT_ACTIVATE 1
				VT_WAITACTIVE 7


Some variant where both do VT_ACTIVATE may mean one of them never
gets its screen

Woo. So on the way up I could spin the activate/waitactive pair inside an alarm loop that interrupts the waitactive until it succeeds. That feels unbelievably dirty but I can't see much of a way around it. Also X server rebuilds take way less time than kernel rebuilds so in the interest of fixing this soon...

Also does this ever occur without selinux ?
It doesn't appear to happen with selinux=0. Suspect that's more timing than policy though.

That may not be - there is a signal failure path that is specifically
different and can only happen in the SELinux case if SELinux decides
the person doing the switch isn't allowed to signal the current graphical vt owner.

A VT switch triggered by one suid root process isn't allowed to generate a signal to another suid root process? Madness.

It wouldn't matter though, the server on its way up hasn't told the kernel what signal to use yet, you can't call VT_SETMODE until after you own the VT, so there's no way we could be signaling gdm's X server yet. If you mean signaling rhgb's server, it still doesn't matter, we're going to VT_ACTIVATE on the way down no matter what.

(I've also been told that rhdb itself will throw lots of VT_ACTIVATE around. Thanks, rhgb!)

- ajax


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]