Page MenuHomeFreeBSD

Improve kstack_contains() to account for pcb/fpu save area
ClosedPublic

Authored by kib on Feb 1 2023, 6:46 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 21 2024, 1:19 PM
Unknown Object (File)
Mar 10 2024, 10:47 PM
Unknown Object (File)
Mar 10 2024, 10:27 PM
Unknown Object (File)
Mar 10 2024, 10:27 PM
Unknown Object (File)
Mar 10 2024, 10:15 PM
Unknown Object (File)
Jan 18 2024, 1:18 PM
Unknown Object (File)
Jan 5 2024, 5:45 PM
Unknown Object (File)
Dec 31 2023, 7:04 PM

Details

Summary
commit efe0422590d9a8386c0135cd1bc91a3549f0fd70
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:   Wed Feb 1 01:49:54 2023 +0200

    kstack_contains(): account for struct pcb on stack
    
    for arm64, arm, powerpc, and riscv
    
commit 223c2779db22dd93362701d898269e8e6a78cd0d
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:   Wed Feb 1 02:30:20 2023 +0200

    i386 trap_check_kstack(): use kstack_contains()
    
commit f1ed6eba25c1b78130c1d274655fe9c2916908fa
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:   Wed Feb 1 01:43:23 2023 +0200

    i386 kstack_contains(): account for pcb/fpu save area
    
commit a17ada82dcd2b575c8a2837a9e7b56d2878ce9ed
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:   Wed Feb 1 00:47:40 2023 +0200

    Move kstack_contains() and GET_STACK_USAGE() to MD machine/stack.h

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kib requested review of this revision.Feb 1 2023, 6:46 AM

Somewhat surprisingly to me, on amd64 both fpu save area and pcb were moved out of the kstack. In other words, the only arch where kstack_contains() is correct ATM is amd64.

I think it would be nice to move the pcb out of the kstack on other arches as well. We want it for CheriBSD downstream for different reasons.

sys/i386/i386/trap.c
208 ↗(On Diff #116174)

Probably you need room for at least a word (4 bytes) here?

This revision is now accepted and ready to land.Feb 1 2023, 10:05 PM
sys/i386/i386/trap.c
208 ↗(On Diff #116174)

I am not sure. I believe IRET could sometimes fault after popping everything from the stack.

Do you mean that the call frame for the trap() itself must be already account for these 4 bytes?