Attention those vendors who are shipping kernels with older versions of
perfmon2. (SiCortex, Cray, Bull, IBM, Broadcom, etc..)
There is a significant bug in perfmon_file.c in __pfm_close() that can
result in a recursive spinlock. The problem was that __pfm_fasync() was
being called inside of a spin_lock_irqsave(), which could renable
interrupts. The bug would manifest itself via a spinlock recursion when
using multiplexing and a process was forced to exit with a Control-C.
It's pretty hard to force it to happen with pfm_close() directly. The
recursion happened when you got a timer interrupt which put you into
pfm_handle_switch_timeout just as the exit path was happening...
You can't make this happen with pfmon because third party monitoring has
a slightly different control flow. It only has shown up with
multiplexing and first person monitoring.
So look at your __pfm_close(). If you see this:
if (filp->f_flags & FASYNC)
__pfm_fasync (-1, filp, ctx, 0);
spin_lock_irqsave(&ctx->lock, flags);
Then you are ok.
If it's in the other order, you are vulnerable to the bug and should update.
Thanks to Peter Watkins at SiCortex for tracking down the fix to this.
Phil
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
