pthread_cond_wait is preempted after releasing the lock, sched_lock cannot lock threads from other CPUs, use enter_critical_section
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Instead of using a volatile storage for the address environment in the
binfmt / loadinfo structures, always allocate the address environment
from kheap.
This serves two purposes:
- If the task creation fails, any kernel thread that depends on the
address environment created during task creation will not lose their
mappings (because they hold a reference to it)
- The current address environment variable (g_addrenv) will NEVER contain
a stale / incorrect value
- Releasing the address environment is simplified as any pointer given
to addrenv_drop() can be assumed to be heap memory
- Makes the kludge function addrenv_clear_current irrelevant, as the
system will NEVER have invalid mappings any more
Problem:
AppBringup task in default priority 240 ->
board_late_initialize() ->
some driver called work_queue() ->
nxsem_post(&(wqueue).sem) failed because sem_count is 0
hp work_thread in default priority 224 ->
nxsem_wait_uninterruptible(&wqueue->sem);
so hp_work_thread can't wake up, worker can't run immediately.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
- Remove the temporary "saved" variable when temporarily changing MMU
mappings to access another process's memory. The fact that it has an
address environment is enough to make the choice
- Restore nxflat_addrenv_restore-macro. It was accidentally lost when
the address environment handling was re-factored.
- The code will detect an error condition described in
https://cwiki.apache.org/confluence/display/NUTTX/Signaling+Semaphores+and+Priority+Inheritance
- The kernel will go to PANIC if semaphore holder can't be allocated even
if CONFIG_DEBUG_ASSERTIONS is disabled
- Clean-up code that handled posing of semaphore with priority inheritance
enabled from the interrupt context (remove nxsem_restore_baseprio_irq())
Summary:
- Support arm64 pmu api, Currently only the cycle counter function is supported.
- Using ARM64 PMU hardware capability to implement perf interface, modify all
perf interface related code.
- Support for pmu init under smp.
Signed-off-by: wangming9 <wangming9@xiaomi.com>
After enabling this option, you can automatically trace the function instrumentation without adding tracepoint manually.
This is similar to the Function Trace effect of the linux kernel
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
Assert in nxsem_post if:
- Priority inheritance is enabled on a semaphore
- A thread that does not hold the semaphore attempts to post it
This will detect an error condition described in https://cwiki.apache.org/confluence/display/NUTTX/Signaling+Semaphores+and+Priority+Inheritance
None. The debug instrumentation is only enabled if CONFIG_DEBUG_ASSERTIONS is enabled.
Use sim:ostest. Verify that no assertions occur.
Compilation error occurs after SCHED_CRITMONITOR is enabled
sched/sched_critmonitor.c:315: undefined reference to `serr'
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
sem_t is user memory and the correct mappings are needed to perform
the semaphore wait interruption.
Otherwise either a page fault, or access to the WRONG address environment
happens.
Refer to issue #8867 for details and rational.
Convert sigset_t to an array type so that more than 32 signals can be supported.
Why not use a uin64_t?
- Using a uin32_t is more flexible if we decide to increase the number of signals beyound 64.
- 64-bit accesses are not atomic, at least not on 32-bit ARMv7-M and similar
- Keeping the base type as uint32_t does not introduce additional overhead due to padding to achieve 64-bit alignment of uin64_t
- Some architectures still supported by NuttX do not support uin64_t
types,
Increased the number of signals to 64. This matches Linux. This will support all xsignals defined by Linux and also 32 real time signals (also like Linux).
This is is a work in progress; a draft PR that you are encouraged to comment on.
Calling syslog to print logs in clock_gettime will cause the system to have recursive output, i.e., clock_gettime->sinfo->syslog->clock_gettime, with the consequences of stack overflow or non-stop log output.
Decouple the semcount and the work queue length.
Previous Problem:
If a work is queued and cancelled in high priority threads (or queued
by timer and cancelled by another high priority thread) before
work_thread runs, the queue operation will mark work_thread as ready to
run, but the cancel operation minus the semcount back to -1 and makes
wqueue->q empty. Then the work_thread still runs, found empty queue,
and wait sem again, then semcount becomes -2 (being minused by 1)
This can be done multiple times, then semcount can become very small
value. Test case to produce incorrect semcount:
high_priority_task()
{
for (int i = 0; i < 10000; i++)
{
work_queue(LPWORK, &work, worker, NULL, 0);
work_cancel(LPWORK, &work);
usleep(1);
}
/* Now the g_lpwork.sem.semcount is a value near -10000 */
}
With incorrect semcount, any queue operation when the work_thread is
busy, will only increase semcount and push work into queue, but cannot
trigger work_thread (semcount is negative but work_thread is not
waiting), then there will be more and more works left in queue while
the work_thread is waiting sem and cannot call them.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
The _unmasked_ signal action was never added if the task is in system call
and waiting for (a different) signal.
This fixes deliver especially for default signal actions / unmaskable
signals, like SIGTERM.
As far as I can interpret how signal delivery should work when the signal
is blocked, it should still be sent to the pending queue even if the signal
is masked. When the sigmask changes it will be delivered.
The original implementation did not add the pending signal action, if
stcb->task_state == TSTATE_WAIT_SIG is true.
An attempt to patch this was made in #8563 but it is insufficient as it
creates an issue when the task is not waiting for a signal, but is in
syscall, in this case the signal is incorrectly queued twice.
since the chip/board vendor could disable dirvers/note and
provide the implementation of sched_note_xxx by self
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Remove calls to the userspace API exit() from the kernel. The problem
with doing such calls is that the exit functions are called with kernel
mode privileges which is a big security no-no.
Do not allow a deferred cancellation if the group is exiting, it is too
dangerous to allow the threads to execute any user space code after the
exit has started.
If the cancelled thread is not inside a cancellation point, just kill it
immediately via asynchronous cancellation. This will create far less
problems than allowing it to continue running user code.
For some reason the signal action was never performed if the receiveing
task was within a system call, the pending queue inser was simply missing.
This fixes the issue.
