Patchwork powerpc/spufs: Fix spinning in spufs_ps_fault on signal

login
register
mail settings
Submitter Jeremy Kerr
Date Nov. 18, 2008, 11:09 p.m.
Message ID <1227049787.482219.695250894439.1.gpush@pingu>
Download mbox | patch
Permalink /patch/9510/
State Accepted
Headers show

Comments

Jeremy Kerr - Nov. 18, 2008, 11:09 p.m.
Currently, we can end up in an infinite loop if we get a signal
while the kernel has faulted in spufs_ps_fault. Eg:

 alarm(1);

 write(fd, some_spu_psmap_register_address, 4);

- the write's copy_from_user will fault on the ps mapping, and
signal_pending will be non-zero. Because returning from the fault
handler will never clear TIF_SIGPENDING, so we'll just keep faulting,
resulting in an unkillable process using 100% of CPU.

This change returns VM_FAULT_SIGBUS if there's a fatal signal pending,
letting us escape the loop.

Signed-off-by: Jeremy Kerr <jk@ozlabs.org>

---
 arch/powerpc/platforms/cell/spufs/file.c |    3 +++
 1 file changed, 3 insertions(+)

Patch

diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index b73c369..1b26071 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -390,6 +390,9 @@  static int spufs_ps_fault(struct vm_area_struct *vma,
 	if (offset >= ps_size)
 		return VM_FAULT_SIGBUS;
 
+	if (fatal_signal_pending(current))
+		return VM_FAULT_SIGBUS;
+
 	/*
 	 * Because we release the mmap_sem, the context may be destroyed while
 	 * we're in spu_wait. Grab an extra reference so it isn't destroyed