Raising an disabled tasklet / VC/KBD initialization bug.

Raising an disabled tasklet / VC/KBD initialization bug.

[Andi Kleen]

Hallo,

I just ran into the following situation on x86-64 on 2.4.17. I think
2.5 has the same problem. 

For some reason vc_init executed in init order after kbd_init
(they are both indirectly called via __initcall so it can happen) 
vc_init does a tasklet_schedule for the keyboard tasklet in 
set_leds.  The keyboard tasklet had not been enabled yet because kbd_init
didn't execute.
Result was an raised tasklet that wasn't enabled.  schedule was called
and ran the softirqs.  tasklet_action always tried to execute it, but 
returned on the non zero count. The tasklet was still active. ksoftirqd
noticed that and executed do_softirq again -> endless loop. 

For now I just removed the set_leds() call in reset_terminal to work around
it. The real fix would be either to add an mechanism to support raising
of disabled tasklets properly or make sure kbd_init and vc_init have defined
init order and the first always executes before the second. 

Comments? 

-Andi

Re: Raising an disabled tasklet / VC/KBD initialization bug.

[James Simmons]

> For some reason vc_init executed in init order after kbd_init
> (they are both indirectly called via __initcall so it can happen) 
> vc_init does a tasklet_schedule for the keyboard tasklet in 
> set_leds.  The keyboard tasklet had not been enabled yet because kbd_init
> didn't execute.
> Result was an raised tasklet that wasn't enabled.  schedule was called
> and ran the softirqs.  tasklet_action always tried to execute it, but 
> returned on the non zero count. The tasklet was still active. ksoftirqd
> noticed that and executed do_softirq again -> endless loop. 

Really good spotting. 

> For now I just removed the set_leds() call in reset_terminal to work around
> it. The real fix would be either to add an mechanism to support raising
> of disabled tasklets properly or make sure kbd_init and vc_init have defined
> init order and the first always executes before the second. 

I'm working on a fix right now. As gor calling kbd_init before vc_init
that is a bad idea as all keyboard drivers are being moved over to the
input api. Plus the console system will soon support hotplug of devices.
The proper fix is to test the kam flag in struct vc_data. Will send a
patch to be included in the dave jones tree.

Re: Raising an disabled tasklet / VC/KBD initialization bug.

[Alan Cox]

> of disabled tasklets properly or make sure kbd_init and vc_init have defined
> init order and the first always executes before the second. 
> 
> Comments? 

Oh this explains several non x86 reports. Yes We need to fix the link order

Re: Raising an disabled tasklet / VC/KBD initialization bug.

[James Simmons]

> > of disabled tasklets properly or make sure kbd_init and vc_init have defined
> > init order and the first always executes before the second. 
> > 
> > Comments? 
> 
> Oh this explains several non x86 reports. Yes We need to fix the link order

Better fix is to test the kam flag in struct vc_data. Will send patch.