Hi,

my btrace ustack tracing efforts still lead to occasional kernel panics.
The reason is when a btrace(8) profile probe grabs the userland stack,
it might interrupt copy(9) from/to userland. The nested copy(9) in the
profiling probe fails to preserve pcb_onfault of the already running
invocation. It blindly restores NULL. If the interrupted copy(8) fails,
it crashes.

I only adjusted copyin(), as that is what ustack relies on. Shall I
adjust the other copy-routines, too? The diff gets a lot bigger then.

Boots and passes regress/sys/copy on amd64 and i386.


 - Christian

---
 sys/arch/amd64/amd64/copy.S | 2 +-
 sys/arch/i386/i386/locore.s | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys/arch/amd64/amd64/copy.S b/sys/arch/amd64/amd64/copy.S
index 23f5f70220f7..c1c94f92464c 100644
--- a/sys/arch/amd64/amd64/copy.S
+++ b/sys/arch/amd64/amd64/copy.S
@@ -150,7 +150,7 @@ ENTRY(copyout)
 ENTRY(_copyin)
 	RETGUARD_SETUP(kcopy, r10)
 	movq	CPUVAR(CURPCB),%rax
-	pushq	$0
+	pushq	PCB_ONFAULT(%rax)
 	leaq	copy_fault(%rip),%r11
 	movq	%r11,PCB_ONFAULT(%rax)
 	SMAP_STAC
diff --git a/sys/arch/i386/i386/locore.s b/sys/arch/i386/i386/locore.s
index d3d04c50ba4a..143161606334 100644
--- a/sys/arch/i386/i386/locore.s
+++ b/sys/arch/i386/i386/locore.s
@@ -509,7 +509,7 @@ ENTRY(_copyin)
 	pushl	%esi
 	pushl	%edi
 	GET_CURPCB(%eax)
-	pushl	$0
+	pushl	PCB_ONFAULT(%eax)
 	movl	$copy_fault,PCB_ONFAULT(%eax)
 	SMAP_STAC
 
-- 
2.34.1

• smime.p7s (5K)