Unexpected lockups in scheduler with 2.5.60-2.5.69
PATCH 1/1 Unexpected lockups in scheduler with 2.5.60-2.5.69
Hi Linus,
there is problem with send_sig_info. This function can be invoked from
timer interrupt (timer_interrpt -> do_timer -> update_process_times -> -> update_one_process -> ( do_process_times, do_it_prof, do_it_virt ) -> -> send_sig -> send_sig_info) but it uses spin_unlock_irq instead of correct spin_unlock_irqrestore.
This enables interrupts, and later scheduler_tick() locks runqueue
(without disabling interrupts). And if we are unlucky, new interrupt comes at this point. And if this interrupt tries to do wake_up() (like RTC interrupt does), we deadlock on runqueue lock :-( And it is bad...
Problem was introduced by signal-fixes-2.5.59-A4, which spilt
original send_sig_info into two functions, and in one branch it started using these unsafe spinlock variants (while group variant uses irqsave/restore correctly).
Best regards,
Petr Vandrovec
kernel/signal.c +3 -2
@@ -1145,6 +1145,7 @@int send_sig_info (int sig,struct siginfo *info,struct task_struct *p) { +unsigned long flags;int ret;/*
@@ -1154,9 +1155,9 @@* going away or changing from under us. */ read_lock (&tasklist_lock); -spin_lock_irq (&p->sighand->siglock); +spin_lock_irqsave (&p->sighand->siglock, flags); ret =specific_send_sig_info (sig, info, p); -spin_unlock_irq (&p->sighand->siglock); +spin_unlock_irqrestore (&p->sighand->siglock, flags);read_unlock (&tasklist_lock);return ret; }