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

[Derek Atkins]

Question: what happens if you really DO want to interrupt the
process?  Wont this cause it to fail to interrupt even when the
process returns from the AFS Syscall?

-derek

Matt Peterson <matt@caldera.com> writes:

> 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
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available