The issue is that the int3 handler uses a per CPU debug stack, and calls do_traps() with interrupts enabled but preemption disabled. Then a signal is sent to the current process, and the code that handles the signal grabs a spinlock. This spinlock becomes a mutex (sleeping lock) when CONFIG_PREEMPT_RT_FULL is enabled.
If there is contention on this lock then the task may schedule out. As the task is using a per CPU stack, and another task may come in and use the same stack, the stack can become corrupted and cause the kernel to panic.
This issue has been addressed in following products:
MRG for RHEL-6 v.2
Via RHSA-2012:0333 https://rhn.redhat.com/errata/RHSA-2012-0333.html
Those links display a page with this error message:
404 - Unknown commit object
(In reply to comment #7)
> > http://git.kernel.org/linus/968544b96be6801bee3e5974fd1dc29e5ab454ff
> > http://git.kernel.org/linus/1bb57b5ea265a1fe2974b6b84fe819489a37e6b3
> Those links display a page with this error message:
> 404 - Unknown commit object
I might have mixed it up with an internal repo. I will get back to you on this. Thanks.
(Ignore comment #6-8)
This issue did not affect the Linux kernel as shipped with Red Hat Enterprise Linux 4, 5, and 6. This has been addressed in Red Hat Enterprise MRG via https://rhn.redhat.com/errata/RHSA-2012-0333.html.