For example a race in managing tcb->sigprocmask may cause signal not being delivered at all.
The mechanism is as follows:
1. cpu 1: nxsig_deliver adds the signal to the sigprocmask for the duration of signal delivery
2. cpu 2: new signal (same signo) is dispatched in nxsig_tcbdispatch
3. cpu 2: nxsig_tcbdispatch detects that signal is masked
4. cpu 2: nxsig_tcbdispatch leaves critical section before calling nxsig_add_pendigsignal
5. cpu 1: nxsig_deliver finishes. The "nxsig_unmask_pendingsignal" is called in the end but does nothing
6. cpu 2: nxsig_tcbdispatch continues and adds the pending signal
In the end, the logic in the end of nxsig_deliver, which tries to handle signals added
to the pending queue during the signal action delivery (step 5) failed, and the pending signal
was not delivered.
Fix this by just keeping the critical section for during the whole duration of nxsig_tcbdispatch,
and move things which can't be executed from within critical section outside.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
For some SMP calls it is necessary to lock the current CPU for the process
receiving the SMP call. This is done by setting the CPU affinity to the
current CPU and preventing the CPU selection algorithm from switching
CPUs.
dtcb->flags |= TCB_FLAG_CPU_LOCKED;
CPU_SET(dtcb->cpu, &dtcb->affinity);
However, this logic is currently broken, as CPU_SET is defined as:
#define CPU_SET(c,s) do { *(s) |= (1u << (c)); } while (0)
In order to assign tcb->cpu (the current CPU) to the affinity mask, the
mask must be cleared first by calling CPU_ZERO.
Renaming "modlib" to "libelf" is more in line with the implementation content,
which makes it easier for individual developers to understand the capabilities of this module.
CONFIG_LIBC_MODLIB -> CONFIG_LIBC_ELF
Signed-off-by: chao an <anchao.archer@bytedance.com>
test:
1.use mps3-an547 build helloxx as module and run it
2.use qemu-armv7a:knsh test kernel build helloxx and run it
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
There is no need for a gettid() syscall, as the thread ID is stable through
the life of the process. It is safe to put a copy of TID to TLS. This way
a user processes can access TID quickly via its own stack, instead of
having to use an expensive syscall.
Signed-off-by: Ville Juven <ville.juven@unikie.com>
This avoids unnecessary syscalls in memory protected builds, when mutex
lock/unlock can be done with only atomic counter access
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
When the semaphore priority flags is set to NONE, and the semaphore
is a mutex, the fast locking path can be used, even when
priority inheritance or priority protect are enabled globally.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
After pthread mutexes changed to nxmutex, the priority inheritance
was set on by default; even if one tried to control it with
CONFIG_PTHREAD_MUTEX_DEFAULT_PRIO_INHERIT.
Also the CONFIG_PTHREAD_MUTEX_DEFAULT_PRIO_PROTECT is not effective.
Fix this by setting the default mutex priority adjustment flags according
to CONFIG_PTHREAD_MUTEX_DEFAULT_PRIO_INHERIT and CONFIG_PTHREAD_MUTEX_DEFAULT_PRIO_PROTECT.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Replace get current tcb method from nxsched_get_tcb(nxsched_gettid()) to this_task(),
change two function calls with inline function to improve performance:
FAR struct tcb_s *tcb = nxsched_get_tcb(nxsched_gettid());
FAR struct tcb_s *tcb = this_task();
Signed-off-by: chao an <anchao.archer@bytedance.com>
The kernel mapping should be performed in sem_wait (thread level) as
virtual memory mappings cannot be added from interrupt, at least for now.
The reason?
kmm_map() depends on mm_map_add(), which in turn uses a mutex for mutual
exclusion. Using mutexes from interrupt level is not permitted.
Mapping tcb->waitobj into kernel virtual memory directly in sem_wait()
makes sense, since accessing tcb->waitobj via a user virtual address can
lead to unexpected results (the wrong mappings can be in place).
This commit addresses an issue where calling `wd_cancel_period` within the periodic watchdog callback would fail to cancel the watchdog timer.
Signed-off-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com>
Fix build error with the following condition.
- CONFIG_BOARD_CRASHDUMP_CUSTOM=y
- CONFIG_COREDUMP=n
The condition for calling `coredump_initialize()` is incorrect.
CONFIG_BOARD_CRASHDUMP_CUSTOM is not dependent on CONFIG_COREDUMP.
Signed-off-by: SPRESENSE <41312067+SPRESENSE@users.noreply.github.com>
The missing <nuttx/spinlock.h> header caused following compile errors:
CC: clock/clock_adjtime.c clock/clock_adjtime.c: In function 'adjtime_wdog_callback':
clock/clock_adjtime.c:67:11: error: implicit declaration of function 'spin_lock_irqsave' [-Wimplicit-function-declaration]
67 | flags = spin_lock_irqsave(&g_adjtime_lock);
| ^~~~~~~~~~~~~~~~~
clock/clock_adjtime.c:78:3: error: implicit declaration of function 'spin_unlock_irqrestore' [-Wimplicit-function-declaration]
78 | spin_unlock_irqrestore(&g_adjtime_lock, flags);
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Coredump doens't need CONFIG_ELF to be enabled, but need elf.h to include correct elf32.h or elf64.h.
Select LIBC_ARCH_ELF in COREDUMP to allow LIBC_ARCH_ELF_64BIT to be
defined correctly.
Signed-off-by: Neo Xu <neo.xu1990@gmail.com>
Firstly call arm_coredump_add_region in up_initialize to add nvic region, then call
coredump_set_memory_region to add board mem region, at this moment, an overlap occurs.
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
Add a custom note for NuttX information including magic and coredump
file data size, so when system reboots, we can check if the block device
contains valid coredump file, and save it to file system.
Signed-off-by: xuxingliang <xuxingliang@xiaomi.com>
reason:
1 Accelerated the implementation of sched_lock, remove enter_critical_section in sched_lock and
only enter_critical_section when task scheduling is required.
2 we add sched_lock_wo_note/sched_unlock_wo_note and it does not perform instrumentation logic
Signed-off-by: hujun5 <hujun5@xiaomi.com>
The load/compare and RMW to wait_count need protection. Using atomic
operations should resolve both issues.
NOTE:
The assumption that the user will call pthread_cond_signal /
pthread_cond_broadcast with the mutex given to pthread_cond_wait held is
simply not true. It MAY hold it, but it is not forced. Thus, using the
user space lock for protecting the wait counter as well is not valid!
The pthread_cond_signal() or pthread_cond_broadcast() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits; however, if predictable scheduling behaviour is required, then that mutex is locked by the thread calling pthread_cond_signal() or pthread_cond_broadcast().
[1] https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_signal.html
elf_emit_tcb_note: nitems(status.pr_regs) is 18, g_tcbinfo.regs_num is 17, then g_tcbinfo.reg_off.p[17] has been out of bounds
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
These options are unistd-specific and should not be filesystem dependent,
and also not suitable for define in the sched directory.
Signed-off-by: chao an <anchao.archer@bytedance.com>
reason:
We decouple semcount from business logic
by using an independent counting variable,
which allows us to remove critical sections in many cases.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
