hitHuang commented on code in PR #19479: URL: https://github.com/apache/nuttx/pull/19479#discussion_r3611548336
########## sched/sched/sched_backtrace.c: ########## @@ -28,15 +28,34 @@ #include <nuttx/sched.h> #include <nuttx/init.h> +#include <string.h> + #include "sched.h" #ifdef CONFIG_ARCH_HAVE_BACKTRACE +/**************************************************************************** + * Pre-processor Definitions + ****************************************************************************/ + +#if defined(CONFIG_SMP) && defined(CONFIG_ARCH_ADDRENV) + +/* Depth of the scratch buffer used to relay a remote backtrace back to + * the caller, since the caller's own buffer may not be mapped in the + * address environment active on the target CPU. Requests larger than + * this are serviced over multiple round trips. Review Comment: Thanks for the suggestion. Just my thinking on why I'd lean toward the fixed-size scratch buffer over switching to kmm_malloc: 1. Robustness-wise, size comes from an untrusted syscall input, and the fixed buffer keeps resource usage independent of it — always 32 pointers per round, no matter how big size is. In practice call stacks aren't usually that deep, so even with a huge size this typically ends in one or two IPI rounds anyway. With kmm_malloc, the allocation size is driven directly by that untrusted value. 2. Complexity-wise, going the heap route would mean moving the allocation outside the critical section, re-validating the target tcb after re-acquiring it, and handling a new allocation-failure path — none of which the current loop needs to worry about. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
