[OpenAFS-devel] Very simple patch for libafs CPU hog on signal

[Matt Peterson]

Hi,

I finally got a chance to look closer at the code to figure out why signals 
cause tight looping in the libafs-libafs-2.4.x. kernel module.

What I found was that src/afs/LINUX/osi_sleep.c is ignorant of the fact that 
the 2.4.x kernel scheduler sets tasks that have a state of TASK_INTERRUPTIBLE 
to TASK_RUNNING before "the scheduler proper" if a signal is pending. I'm 
currently looking at the line 589 of sched.c of the 2.4.17 code, but I've 
verified that the same code exists in the schedule as far back as 2.4.0.

What this means is that the signaled task will eventually (and quickly) 
return from the call to interruptible_sleep_on() line 194 of 
src/afs/LINUX/osi_sleep.c  Since evp->seq will not have been incremented the 
'while(seq == evp->seq)' will not break.  Since signals are not flushed from 
the scheduled process as part of the loop, the 'while(seq == evp->seq)' loop 
will spin tightly until another task (syscall to libafs) increments evp->seq. 

The desired behavior would be to flush the pending signals (if any) before 
the call to the Linux interruptible_sleep_on().  This will eliminate the 
tight looping.

The following is a simple patch that appears to work very well for me.  

$ diff -u osi_sleep.c.orig osi_sleep.c
--- osi_sleep.c.orig    Thu Jul 12 13:58:21 2001
+++ osi_sleep.c Mon Jan 28 15:53:40 2002
@@ -191,8 +191,12 @@
     while (seq == evp->seq) {
        AFS_ASSERT_GLOCK();
        AFS_GUNLOCK();
-       interruptible_sleep_on(&evp->cond);
-       AFS_GLOCK();
+        if(signal_pending(current))
+        {
+          flush_signals(current);
+        }
+        interruptible_sleep_on(&evp->cond);
+        AFS_GLOCK();
     }
     relevent(evp);
 }


Still, signals are not handled the way I'd like them to be, but at least with 
this fix, processes interrupted in certain libafs syscalls do not completely 
hog the CPU.

Is openafs-devel the right place to send this patch?  Please review the 
patch, let me know what you think, and tell me if I should email it to 
another mailing list.

Thanks,

-- 
Matt Peterson
Sr. Software Engineer
Caldera, Inc
matt@caldera.com