rhgb freezing computer

[Adam Jackson]

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