Updated timers.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL() with tmrENTER/EXIT_CRITICAL().
- Added vTimerEnterCritical() and vTimerExitCritical() to map to the
data group critical section macros.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated stream_buffer.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL/_FROM_ISR() with sbENTER/EXIT_CRITICAL_FROM_ISR().
- Added vStreambuffersEnterCritical/FromISR() and
vStreambuffersExitCritical/FromISR() to map to the data group critical
section macros.
- Added prvLockStreamBufferForTasks() and prvUnlockStreamBufferForTasks() to suspend the stream
buffer when executing non-deterministic code.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated event_groups.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL/_FROM_ISR() with event_groupsENTER/EXIT_CRITICAL/_FROM_ISR().
- Added vEventGroupsEnterCritical/FromISR() and
vEventGroupsExitCriti/FromISR() functions that map to the data group
critical section macros.
- Added prvLockEventGroupForTasks() and prvUnlockEventGroupForTasks() to suspend the event
group when executing non-deterministic code.
- xEventGroupSetBits() and vEventGroupDelete() accesses the kernel data group
directly. Thus, added vTaskSuspendAll()/xTaskResumeAll() to these fucntions.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated queue.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL/_FROM_ISR() with queueENTER/EXIT_CRITICAL_FROM_ISR().
- Added vQueueEnterCritical/FromISR() and vQueueExitCritical/FromISR()
which map to the data group critical section macros.
- Added prvLockQueueForTasks() and prvUnlockQueueForTasks() as the granular locking equivalents
to prvLockQueue() and prvUnlockQueue() respectively
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated critical section macros with granular locks.
Some tasks.c API relied on their callers to enter critical sections. This
assumption no longer works under granular locking. Critical sections added to
the following functions:
- `vTaskInternalSetTimeOutState()`
- `xTaskIncrementTick()`
- `vTaskSwitchContext()`
- `xTaskRemoveFromEventList()`
- `vTaskInternalSetTimeOutState()`
- `eTaskConfirmSleepModeStatus()`
- `xTaskPriorityDisinherit()`
- `pvTaskIncrementMutexHeldCount()`
Added missing suspensions to the following functions:
- `vTaskPlaceOnEventList()`
- `vTaskPlaceOnUnorderedEventList()`
- `vTaskPlaceOnEventListRestricted()`
Fixed the locking in vTaskSwitchContext()
vTaskSwitchContext() must aquire both kernel locks, viz., task lock and
ISR lock. This is because, vTaskSwitchContext() can be called from
either task context or ISR context. Also, vTaskSwitchContext() must not
alter the interrupt state prematurely.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
- Updated prvCheckForRunStateChange() for granular locks
- Updated vTaskSuspendAll() and xTaskResumeAll()
- Now holds the xTaskSpinlock during kernel suspension
- Increments/decrements xPreemptionDisable. Only yields when 0, thus allowing
for nested suspensions across different data groups
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Changed xPreemptionDisable to be a count rather than a pdTRUE/pdFALSE. This
allows nested calls to vTaskPreemptionEnable(), where a yield only occurs when
xPreemptionDisable is 0.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
xTaskPriorityInherit() is called inside a critical section from queue.c. This
commit moves the critical section into xTaskPriorityInherit().
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
FreeRTOS MPU: Remove MPU region number check
This change removes the assertion and runtime check that enforces
matching between configTOTAL_MPU_REGIONS and physical MPU
regions,. This allows applications running on devices with 16 MPU
regions to manage 8 MPU regions while leaving the remaining 8
for the kernel.
Signed-off-by: Erick Reyes <erickreyes@google.com>
Use architecture-dependent UBaseType_t instead of fixed type for
ullMachineTimerCompareRegisterBase. This type is defined to uint32_t or
uint64_t based on XLEN, resolving warnings on 32-bit platforms.
Reported by landretk@ on the PR FreeRTOS/FreeRTOS-Kernel#1176.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
RISC-V: refine fpu reg context offset
pxCode and mstatus stored at index 0 and 1 are based on XLEN.
Therefore, the correct formula to calculate the FPU register index
should be ( ( 2 * portWORD_SIZE ) + ( regIndex * portFPU_REG_SIZE ) ).
Signed-off-by: wangfei_chen <wangfei_chen@realsil.com.cn>
* port: riscv: Split the number of registers and the size of the context
* port: riscv: Create some macros for the FPU context
* port: riscv: Add a couple of macros that store fpu context
* port: riscv: Update the stack init function to include the fpu context size
* port: riscv: Add a chip_specific_extensions file that includes the F extension
* Update dictionary to include some risc-v instructions
* port: riscv: Fix a few typos
* port: riscv: Apply @aggarg's sugestions
Disable stack overflow check for MPU ports
Stack overflow check is not straight forward to implement for MPU ports
because of the following reasons:
1. The context is stroed in TCB and as a result, pxTopOfStack member
points to the context location in TCB.
2. System calls are executed on a separate privileged only stack.
It is still okay because an MPU region is used to protect task stack
which means task stack overflow will trigger an MPU fault.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Include current task runtime in ulTaskGetRunTimeCounter
Update ulTaskGetRunTimeCounter to include elapsed time since the last
context switch when called for the currently running task. Previously,
this time was not included in the calculation.
Fixes#1202.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
While using the macOS default LLDB debugger, a call to vTaskEndScheduler results in an unhandled SIGUSR1 (aka SIGRESUME) when restoring the scheduler thread's signals with pthread_sigmask. This crashes the program.
Added instructions in portable/ThirdParty/GCC/Posix/port.c to suppress SIGUSR1 to prevent LLDB debugger interference when exiting xPortStartScheduler
Thanks to: @johnboiles for pointing it out in #1224
This commit updates the definition of taskRESERVED_TASK_NAME_LENGTH in
tasks.c to fix an unreachable preprocessor condition.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
On FreeBSD pthread_once_t is a struct and cast is required.
Otherwise there's compilation error:
../../mocks/freertos/port.c:261:23: error: expected expression
hSigSetupThread = PTHREAD_ONCE_INIT;
^
PTHREAD_ONCE_INIT is defined as: { PTHREAD_NEEDS_INIT, NULL } on FreeBSD
Co-authored-by: Jakub Tymejczyk <jakub.tymejczyk@enigma.com.pl>
Mark mutex as robust to prevent deadlocks
Prevent application hangs that occur when a thread dies while holding a
mutex, particularly during vTaskEndScheduler or exit calls. This is
achieved by setting the PTHREAD_MUTEX_ROBUST attribute on the mutex.
Fixes:
- GitHub issue: FreeRTOS/FreeRTOS-Kernel#1217
- Forum thread: freertos.org/t/22287
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
fix: SA violation fixes and simplification for idle task length restrictions
This change:
* Removes the dependency on strings.h for the prvCreateIdleTask function
* Resolves several static analysis violations reported by tools like Parasoft
Builds off of - https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/1203
Fix the context array size for MPU ports
Ensure the saved context location falls within the reserved context area
rather than overlapping with the next MPU_SETTINGS structure member.
This never caused a problem because actual read/write operations
start from one word before the saved context location.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
The application writer needs to name their IRQ handler as:
1. vApplicationIRQHandler if the IRQ handler does not use FPU registers.
2. vApplicationFPUSafeIRQHandler is the IRQ handler uses FPU registers.
When the application uses vApplicationFPUSafeIRQHandler, a default
implementation of vApplicationIRQHandler is used which stores FPU
registers and then calls vApplicationFPUSafeIRQHandler.
Note that recent versions of GCC may use FP/SIMD registers to optimize 16-bytes
copy and especially when using va_start()/va_arg() functions (e.g printing some thing
in IRQ handlers may trigger usage of FPU registers)
This implementation is heavily inspired by both the ARM_CA9 port and the ARM_CRx_No_GIC
port done in [1]
[1] https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/1113
Signed-off-by: Marouen Ghodhbane <marouen.ghodhbane@nxp.com>
FPSR and FPCR are two 64-bits registers where only the lower 32 bits are defined.
Save them when doing context switch with FPU context saving enabled.
Signed-off-by: Marouen Ghodhbane <marouen.ghodhbane@nxp.com>
This is a direct backport of upstream commit [1] for aarch64 (legacy operation port)
done under [2]
The same code can be applied on the aarch SRE port to be able to enable FPU context
saving on all tasks context switch to mitigate GCC optimization to use SIMD registers
for copy.
[1] "55eceb22: Add configUSE_TASK_FPU_SUPPORT to AARCH64 port (#1048)"
[2] https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/1048
Signed-off-by: Marouen Ghodhbane <marouen.ghodhbane@nxp.com>
Add xQueueCreateSetStatic method for static allocation of Queue Sets
This commit introduces the xQueueCreateSetStatic function, which allows for the static allocation of Queue Sets in FreeRTOS when both configUSE_QUEUE_SETS and configSUPPORT_STATIC_ALLOCATION are enabled.
armv8.1-m: Add task dedicated PAC key
To harden the security, each task is assigned a dedicated PAC key, so that attackers needs to guess the all the tasks' PAC keys right to exploit the system using Return Oriented Programming.
The kernel is now updated to support the following:
* A PAC key set with a random number generated and is saved in the task's context when a task is created.
* As part of scheduling, the task's PAC key is stored/restored to/from the task's context when a task is unscheduled/scheduled from/to run.
stack-overflow-check: Introduce portGET_CURRENT_TOP_OF_STACK macro
When MPU wrapper v2 is used, the task's context is stored in TCB and `pxTopOfStack`` member of TCB points to the context location in TCB. We, therefore, need to read PSP to find the task's current top of stack.
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
The function vApplicationFPUSafeIRQHandler gets the value of ICCIAR as
parameter, but a constant containing the address of ICCIAR was also
defined. Fix the name of the constant to align it with what it actually
holds.
* fix(freertos): Limit idle task name copy operation and ensure null termination
This commit:
- Limits the idle task name length copy operation to prevent
Out-of-bounds memory access warnings from static code analyzers.
- Fixes a bug where in the idle task name could be non null-terminated
string for SMP configuration.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
* Pass core ID to CRITICAL_NESTING_COUNT macros
* Match existing data type for xCoreID
* Get core ID when interrupts are disabled
* Implement get core ID with interrupt disabled
* Get core ID inline within vTaskSuspendAll() to resolve compiler warning
* Fix formatting check
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
---------
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Ching-Hsin,Lee <chinglee@amazon.com>
Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
