Summary:
- I noticed that getopt() test in ostest wailed with
esp32-devkitc:smp and spresense:smp
- Finally, I found that the task-specific data is not
initialized.
- This commit fixes this issue
Impact:
- None
Testing:
- Tested with ostest esp32-devkitc:smp and spresense:smp
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
getopt() in the FLAT build environment is not thread safe. This is because global variables that are process-specific in Unix are truly global in the FLAT build. Moving the getopt() variables into TLS resolves this issue.
No side-effects are expected other than to getopt()
Tested with sim:nsh
it is wrong to define a new grpid_t, but not reuse pid_t,
because it make getpid(parent) == getppid(child) impossible.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Summary:
- During investigating critical section with semaphores, I noticed
that nxtask_flushstreams() is called with a critical section.
- The function calls lib_flushall() which handles a semaphore
in userspace.
- So it should be done without a critical section
Impact:
- SMP only
Testing:
- Tested with ostest the following configs
- esp32-devkitc:smp (QEMU), sabre-6quad:smp (QEMU)
- maix-bit:smp (QEMU), sim:smp
- spresense:smp
- Tested with nxplayer and stress test with spresense:wifi_smp
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- This commit fixes comments and label in nxtask_assign_pid()
Impact:
- None
Testing:
- Built with spresense:wifi
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- During reviewing sched_lock() in nxtask_assign_pid(),
I noticed that g_pidhash is not protected by a critical section
- Because g_pidhash is accessed in an interrupt context,
it should be protected by a critical section.
- Actually, nxsched_foreach(), nxsched_get_tcb() and so on
use a critical section.
Impact:
- No impact
Testing:
- Tested with spresense:wifi (non-SMP) and spresense:wifi_smp
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- During repeating ostest with sabre-6quad:smp (QEMU),
I noticed that pthread_rwlock_test sometimes stops
- Finally, I found that nxtask_exit() released a critical
section too early before context switching which resulted in
selecting inappropriate TCB
- This commit fixes this issue by moving nxsched_resume_scheduler()
from nxtask_exit() to up_exit() and also removing
spin_setbit() and spin_clrbit() from nxtask_exit()
because the caller holds a critical section
- To be consistent with non-SMP cases, the above changes
were done for all CPU architectures
Impact:
- This commit affects all CPU architectures regardless of SMP
Testing:
- Tested with ostest with the following configs
- sabre-6quad:smp (QEMU, dev board), sabre-6quad:nsh (QEMU)
- spresense:wifi_smp
- sim:smp, sim:ostest
- maix-bit:smp (QEMU)
- esp32-devkitc:smp (QEMU)
- lc823450-xgevk:rndis
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- This commit fixes global IRQ control logic
- In previous implementation, g_cpu_irqset for a remote CPU was
set in sched_add_readytorun(), sched_remove_readytorun() and
up_schedule_sigaction()
- In this implementation, they are removed.
- Instead, in the pause handler, call enter_critical_setion()
which will call up_cpu_paused() then acquire g_cpu_irqlock
- So if a new task with irqcount > 1 restarts on the remote CPU,
the CPU will only hold a critical section. Thus, the issue such as
'POSSIBLE FOR TWO CPUs TO HOLD A CRITICAL SECTION' could be resolved.
- Fix nxsched_resume_scheduler() so that it does not call spin_clrbit()
if a CPU does not hold a g_cpu_irqset
- Fix nxtask_exit() so that it acquires g_cpu_irqlock
- Update TODO
Impact:
- All SMP implementations
Testing:
- Tested with smp, ostest with the following configurations
- Tested with spresense:wifi_smp (NCPUS=2,4)
- Tested with sabre-6quad:smp (QEMU, dev board)
- Tested with maix-bit:smp (QEMU)
- Tested with esp32-core:smp (QEMU)
- Tested with lc823450-xgevk:rndis
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- I noticed waitpid_test stops with lc823450-xgevk:rndis
- The condition was CONFIG_DEBUG_ASSERTION=y
- Actually, the child task sent SIGCHILD but the parent couldn't catch the signal
- Then, I found that nx_waitid(), nx_waitpid() use sched_lock()
- However, a parent task and a child task are running on different CPUs
- So, sched_lock() is not enough and need to use a critical section
- Also, signal handling in nxtask_exithook() must be done in a critical section
Impact:
- SMP only
Testing:
- Tested with ostest with the following configurations
- lc823450-xgevk:rndis (CONFIG_DEBUG_ASSERTION=y and n)
- spresense:smp
- spresense:wifi_smp (NCPUS=2 and 4)
- sabre-6quad:smp (QEMU)
- esp32-core:smp (QEMU)
- maix-bit:smp (QEMU)
- sim:smp
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- I noticed that nxsched_merge_pending() is called outside a critical section
- The issue happens if a new rtcb does not hold a critical section
- Actually, global IRQ control is done in nxsched_resume_scheduler() in nxtask_exit()
- However, nxsched_merge_pending() was called after calling nxsched_resume_scheduler()
- This commit fixes the issue by moving nxsched_merge_pending() before the function
- NOTE: the sequence was changed for SMP but works for non-SMP as well
Impact:
- This commit affects both SMP and non-SMP
Testing:
- Tested with ostest with the following configurations
- spresense:wifi_smp (NCPUS=2 and 4)
- spresense:wifi (non SMP)
- sabre-6quad:smp (QEMU)
- esp32-core:smp (QEMU)
- maix-bit:smp (QEMU)
- sim:smp
- lc823450-xgevk:rndis
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
to ensure the basic info(e.g. pid) setup correctly before call arch API
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I851cb0fdf22f45844938dafc5981b3f576100dba
Summary:
- During Wi-Fi audio streaming test, I found a deadlock in nxtask_exit()
- Actually, nxtask_exit() was called and tried to enter critical section
- In enter_critical_section(), there is a deadlock avoidance logic
- However, if switched to a new rtcb with irqcount=0, the logic did not work
- Because the 2nd critical section was treated as if it were the 1st one
- Actually, it tried to run the deadlock avoidance logic
- But nxtask_exit() was called with critical section (i.e. IRQ already disabled)
- So the logic did not work as expected because up_irq_restore() did not enable the IRQ.
- This commit fixes this issue by incrementing irqcount before calling nxtask_terminate()
- Also it adjusts g_cpu_irqlock and g_cpu_lockset
Impact:
- Affects SMP only
Testing:
- Tested with spresense:wifi_smp (smp, ostest, nxplayer, telnetd)
- Tested with sabre-6quad:smp with QEMU (smp, ostest)
- Tested with maix-bit:smp with QEMU (smp, ostest)
- Tested with esp32-core:smp with QEMU (smp, ostest)
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
since nxtask_startup will initialize c++ global variables which shouldn't
be done inside the kernel thread
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Move sched/task/task/task_gettid.c to libs/libc/unistd/lib_gettid.c. gettid() is a dumb wrapper around getpid(). It is wasteful of resources to support TWO systme calls, one for getpid() and one for gettid(). Instead, move gettid() in the C library where it calls the single sysgtem call, getpid(). Much cleaner.
1.Reduce the default size of task_group_s(~512B each task)
2.Scale better between simple and complex application
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ia872137504fddcf64d89c48d6f0593d76d582710
Since up_release_stack auto detect whether the memory come from builtin heap
if (ttype == TCB_FLAG_TTYPE_KERNEL)
{
if (kmm_heapmember(dtcb->stack_alloc_ptr))
{
kmm_free(dtcb->stack_alloc_ptr);
}
}
else
{
/* Use the user-space allocator if this is a task or pthread */
if (umm_heapmember(dtcb->stack_alloc_ptr))
{
kumm_free(dtcb->stack_alloc_ptr);
}
}
This reverts commit 124e6ee53d.
add PR_SET_NAME_EXT/PR_GET_NAME_EXT extension to avoid semantic
conflicts, use extened version for pthread_setname_np/pthread_getname_np
Change-Id: I40404c737977a623130dcd37feb4061b5526e466
Signed-off-by: chao.an <anchao@xiaomi.com>
to avoid the similar code spread around each application
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I8967d647eaf2ecae47f29f83e7fa322ef1b42a02
change the stack pointer type from (uint32_t *) to (void *)
Change-Id: I90bb7d6a9cb0184c133578a1a2ae9a19c233ad30
Signed-off-by: chao.an <anchao@xiaomi.com>
since it is impossible that the current running thread is
in the waiting state and then need to wake up self.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ie2ba55c382eb3eb7c8d9f04bba1b9e294aaf6196
utilize the call inside nxtask_exit instead, also move
nxsched_suspend_scheduler to nxtask_exit for symmetry
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I219fc15faf0026e452b0db3906aa40b40ac677f3
In the FLAT build if CONFIG_LIB_SYSCALL=y, then the function task_spawn() will be duplicated.: One version in libs/libc/spawn and one version in sched/task.
The version of task_spawn in lib/libc/spawn exists only if CONFIG_LIB_SYSCALL is selected. In that case, the one in sched/task/task_spawn.c should be static, at least in the FLAT build.
The version of task_spawn.c in libs/libc/spawn simply marshals the parameters into a structure and calls nx_task_spawn(). If CONFIG_LIB_SYSCALL is defined then nx_task_spawn() will un-marshal the data can call the real task spawn. This nonsense is only necessary because task_spawn has 8 parameters and the maximum number of parameters in a system call is only 6.
Without syscalls: Application should call directly in task_spawn() in sched/task/task_spawn.c and, hence, it must not be static
With syscalls: Application should call the marshalling task_spawn() in libs/libc/spawn/lib_task_spawn.c -> That will call the autogenerated nx_task_spawn() proxy -> And generate a system call -> The system call will the unmarshalling nx_task_spawn() in sched/task/task_spawn.c -> Which will, finally, call the real task_spawn().
The side-effect of making task_spawn() static is that it then cannot be used within the OS. But as far as I can tell, nothing in the OS itself currently uses task_spawn() so I think it is safe to make it conditionally static. But that only protects from duplicate symbols in the useless case mentioned above.
Block and MTD drivers may be opened and managed as though they were character drivers. But this is really sleight of hand; there is a hidden character driver proxy that mediates the interface to the block and MTD drivers in this case.
fstat(), however, did not account for this. It would report the characteristics of the proxy character driver, not of the underlying block or MTD driver.
This change corrects that. fstat now checks if the character driver is such a proxy and, if so, reports the characteristics of the underlying block or MTD driver, not the proxy character driver.
sched_releasetcb() will normally free the stack allocated for a task. However, a task with a custom, user-managed stack may be created using nxtask_init() followed by nxtask_activer. If such a custom stack is used then it must not be free in this many or a crash will most likely result.
This chagne addes a flag call TCB_FLAG_CUSTOM_STACK that may be passed in the the pre-allocted TCB to nxtask_init(). This flag is not used internally anywhere in the OS except that if set, it will prevent sched_releasetcb() from freeing that custom stack.
