History log of /freebsd-current/sys/x86/x86/stack_machdep.c
Revision Date Author Comments
# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 2555f175 31-Jan-2023 Konstantin Belousov <kib@FreeBSD.org>

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

Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38320


# f95e683f 23-Jul-2021 Mark Johnston <markj@FreeBSD.org>

Annotate amd64 stack unwinders with __nomemorysanitize

Sponsored by: The FreeBSD Foundation


# 831850d8 07-May-2021 Mark Johnston <markj@FreeBSD.org>

stack(9): Disable KASAN in stack_capture()

When unwinding the stack, we may encounter a stack frame in a poisoned
region of the stack, triggering a false positive.

Reviewed by: andrew, kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D30126


# 5941edfc 01-Dec-2020 John Baldwin <jhb@FreeBSD.org>

Add a kstack_contains() helper function.

This is useful for stack unwinders which need to avoid out-of-bounds
reads of a kernel stack which can trigger kernel faults.

Reviewed by: kib, markj
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D27356


# 1c29da02 31-Jan-2020 Mark Johnston <markj@FreeBSD.org>

Reimplement stack capture of running threads on i386 and amd64.

After r355784 the td_oncpu field is no longer synchronized by the thread
lock, so the stack capture interrupt cannot be delievered precisely.
Fix this using a loop which drops the thread lock and restarts if the
wrong thread was sampled from the stack capture interrupt handler.

Change the implementation to use a regular interrupt instead of an NMI.
Now that we drop the thread lock, there is no advantage to the latter.

Simplify the KPIs. Remove stack_save_td_running() and add a return
value to stack_save_td(). On platforms that do not support stack
capture of running threads, stack_save_td() returns EOPNOTSUPP. If the
target thread is running in user mode, stack_save_td() returns EBUSY.

Reviewed by: kib
Reported by: mjg, pho
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23355


# e688e781 07-Nov-2019 Andriy Gapon <avg@FreeBSD.org>

revert r354482, checking for XENHVM was a wrong way of checking for Xen


# bff7f83d 07-Nov-2019 Andriy Gapon <avg@FreeBSD.org>

IPI_TRACE is not really supported on xen

x86 stack_save_td_running() can work safely only if IPI_TRACE is a
non-maskable interrupt. But at the moment FreeBSD/Xen does not provide
support for the NMI delivery mode. So, mark the functionality as
unsupported similarly to other platforms without NMI.
Maybe there is a way to provide a Xen-specific working
stack_save_td_running(), but I couldn't figure it out.

MFC after: 3 weeks
Sponsored by: Panzura


# fe585be5 02-Aug-2018 Mark Johnston <markj@FreeBSD.org>

Verify that each frame pointer lies within the thread's kstack.

Previously, this check was omitted for the first frame pointer.

Reported by: pho
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16572


# 17b5949a 31-Jul-2017 Mark Johnston <markj@FreeBSD.org>

Don't trace running threads that have interrupts disabled.

In this case we shouldn't assume that the thread has a valid frame pointer.

Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D11787


# 10c480e7 06-Dec-2016 Mark Johnston <markj@FreeBSD.org>

Require the STACK option for code that captures stacks of running threads.

stack_machdep.c is compiled if either of the DDB or STACK options is
specified, but stack_save_td_running() isn't useable from DDB. Moreover,
stack_save_td_running() works by raising an NMI on the CPU running the
target thread, and the corresponding handler is compiled only if STACK is
configured.

Reported by: kib
MFC after: 1 week


# 610141ce 10-Sep-2015 Mark Johnston <markj@FreeBSD.org>

Add stack_save_td_running(), a function to trace the kernel stack of a
running thread.

It is currently implemented only on amd64 and i386; on these
architectures, it is implemented by raising an NMI on the CPU on which
the target thread is currently running. Unlike stack_save_td(), it may
fail, for example if the thread is running in user mode.

This change also modifies the kern.proc.kstack sysctl to use this function,
so that stacks of running threads are shown in the output of "procstat -kk".
This is handy for debugging threads that are stuck in a busy loop.

Reviewed by: bdrewery, jhb, kib
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D3256


# 4db79feb 10-Sep-2015 Mark Johnston <markj@FreeBSD.org>

Merge stack(9) implementations for i386 and amd64 under x86/.

Reviewed by: jhb, kib
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D3255