Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kernel/sched: fix logging after stack overflow #6622

Merged
merged 1 commit into from
Jan 13, 2025

Conversation

ritesh55555
Copy link
Contributor

@ritesh55555 ritesh55555 commented Jan 8, 2025

This commit changes logging method from dbg to lldbg to print stack overflow information. This is done because after stack overflow, using dbg does not work because of more stack memory requirement. But in the lldbg case, it uses low level syslog, so it uses minimal stack memory.

logs before:

cycle in normal thread done
stack base ptr of normal thread is 0xdeadbeef
cycle in recursive thread done with cnt 423

security level: 0
===========================================================
Assertion details
===========================================================
print_assert_detail: Assertion failed CPU0 at file: sched/sched_removereadytorun.c line 125 task: recusrsive_thread pid: 20
print_assert_detail: Assert location (PC) : 0x0e01b587

logs after changing to lldbg:

cycle in normal thread done
stack base ptr of normal thread is 0xdeadbeef
cycle in recursive thread done with cnt 423
stack base 
###############    STACK OVERFLOW at pid 20 (recusrsive_thread) ###################

security level: 0
===========================================================
Assertion details
===========================================================
print_assert_detail: Assertion failed CPU0 at file: sched/sched_removereadytorun.c line 125 task: recusrsive_thread pid: 20
print_assert_detail: Assert location (PC) : 0x0e01b587


@ritesh55555 ritesh55555 force-pushed the stack_overflow_logfix branch from 2991b9b to 110ebbf Compare January 8, 2025 11:43
Copy link
Contributor

@samsung-singh samsung-singh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed logging after stack overflow in kernel sched, this change is good to merge.

Comment on lines 127 to 132
if (*(uint32_t *)(rtcb->stack_base_ptr) != STACK_COLOR) {
dbg_noarg("############### STACK OVERFLOW at pid %d ", rtcb->pid);
lldbg_noarg("\n############### STACK OVERFLOW at pid %d ", rtcb->pid);
#if CONFIG_TASK_NAME_SIZE > 0
dbg_noarg("(%s) ", rtcb->name);
lldbg_noarg("(%s) ", rtcb->name);
#endif
dbg_noarg("###################\n");
lldbg_noarg("###################\n");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could cause log mix.
Because we will call the PANIC after this message, how about adding enter_critical_section?

Copy link
Contributor

@sunghan-chang sunghan-chang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And the same codes are at 4 different locations. How about making a new api for that?

@ritesh55555 ritesh55555 force-pushed the stack_overflow_logfix branch 3 times, most recently from 1c57080 to be7f3e9 Compare January 9, 2025 10:36
@@ -88,6 +88,33 @@
* Public Functions
****************************************************************************/

/****************************************************************************
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry but let's add this with new file, not here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@ritesh55555 ritesh55555 force-pushed the stack_overflow_logfix branch 2 times, most recently from f6ba762 to b72722c Compare January 10, 2025 08:52
/****************************************************************************
* kernel/sched/sched_checkstackoverflow.c
*
* Redistribution and use in source and binary forms, with or without
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to add this license. Let's remove.

os/kernel/sched/sched_checkstackoverflow.c Show resolved Hide resolved
@@ -60,7 +60,7 @@ CSRCS += sched_setscheduler.c sched_getscheduler.c
CSRCS += sched_yield.c sched_rrgetinterval.c sched_foreach.c
CSRCS += sched_lock.c sched_unlock.c sched_lockcount.c sched_self.c
CSRCS += sched_getaffinity.c sched_setaffinity.c
CSRCS += sched_getcpu.c
CSRCS += sched_getcpu.c sched_checkstackoverflow.c
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The function is called with CONFIG_SW_STACK_OVERFLOW_DETECTION.
It means this file is valid with the config. Let's add conditional for this.
Or, remove the conditional at all c file, and in header, let's do like below

#ifdef CONFIG_XXX
void sched_checkstackoverflow(FAR struct tcb_s *rtcb);
#else
#define sched_checkstackoverflow(x)
#endif

@ritesh55555 ritesh55555 force-pushed the stack_overflow_logfix branch from b72722c to 89b1e5a Compare January 10, 2025 11:13
	- This commit changes logging method from
	  dbg to lldbg to print stack overflow information.
	  This is done because after stack overflow, using
	  dbg does not work because of more stack memory
	  requirement. But in the lldbg case, it uses
	  low level syslog, so it uses minimal stack memory.
@ritesh55555 ritesh55555 force-pushed the stack_overflow_logfix branch from 89b1e5a to aaca92a Compare January 10, 2025 11:15
@kishore-sn kishore-sn merged commit 3237906 into Samsung:master Jan 13, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants