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.
There is an issue where the wrong process exit code is given to the parent
when a process exits. This happens when the process has pthreads running
user code i.e. not within a cancel point / system call.
Why does this happen ?
When exit() is called, the following steps are done:
- group_kill_children(), which tells the children to die via pthread_cancel()
Then, one of two things can happen:
1. if the child is in a cancel point, it gets scheduled to allow it to leave
the cancel point and gets destroyed immediately
2. if the child is not in a cancel point, a "cancel pending" flag is set and
the child will die when the next cancel point is encountered
So what is the problem here?
The last thread alive dispatches SIGCHLD to the parent, which carries the
process's exit code. The group head has the only meaningful exit code and
this is what should be passed. However, in the second case, the group head
exits before the child, taking the process exit code to its grave. The child
that was alive will exit next and will pass its "status" to the parent process,
but this status is not the correct value to pass.
This commit fixes the issue by passing the group head's exit code ALWAYS to
the parent process.
The function is not relevant any longer, remove it. Also remove
save_addrenv_t, the parameter taken by up_addrenv_restore.
Implement addrenv_select() / addrenv_restore() to handle the temporary
instantiation of address environments, e.g. when a process is being
created.
There is currently a big problem in the address environment handling which
is that the address environment is released too soon when the process is
exiting. The current MMU mappings will always be the exiting process's, which means
the system needs them AT LEAST until the next context switch happens. If
the next thread is a kernel thread, the address environment is needed for
longer.
Kernel threads "lend" the address environment of the previous user process.
This is beneficial in two ways:
- The kernel processes do not need an allocated address environment
- When a context switch happens from user -> kernel or kernel -> kernel,
the TLB does not need to be flushed. This must be done only when
changing to a different user address environment.
Another issue is when a new process is created; the address environment
of the new process must be temporarily instantiated by up_addrenv_select().
However, the system scheduler does not know that the process has a different
address environment to its own and when / if a context restore happens, the
wrong MMU page directory is restored and the process will either crash or
do something horribly wrong.
The following changes are needed to fix the issues:
- Add mm_curr which is the current address environment of the process
- Add a reference counter to safeguard the address environment
- Whenever an address environment is mapped to MMU, its reference counter
is incremented
- Whenever and address environment is unmapped from MMU, its reference
counter is decremented, and tested. If no more references -> drop the
address environment and release the memory as well
- To limit the context switch delay, the address environment is freed in
a separate low priority clean-up thread (LPWORK)
- When a process temporarily instantiates another process's address
environment, the scheduler will now know of this and will restore the
correct mappings to MMU
Why is this not causing more noticeable issues ? The problem only happens
under the aforementioned special conditions, and if a context switch or
IRQ occurs during this time.
Detach the address environment handling from the group structure to the
tcb. This is preparation to fix rare cases where the system (MMU) is left
without a valid page directory, e.g. when a process exits.
NuttX kernel should not use the syscall functions, especially after
enabling CONFIG_SCHED_INSTRUMENTATION_SYSCALL, all system functions
will be traced to backend, which will impact system performance.
Signed-off-by: chao an <anchao@xiaomi.com>
Implement a function for dropping references to the group structure and
finally freeing the allocated memory, if the group has been marked for
destruction
The number of work entries will be inconsistent with semaphore count
if the work is canceled, in extreme case, semaphore count will overflow
and fallback to 0 the workqueue will stop scheduling the enqueue work.
Signed-off-by: chao an <anchao@xiaomi.com>
continue the follow work:
commit 43e7b13697
Author: Xiang Xiao <xiaoxiang@xiaomi.com>
Date: Sun Jan 22 19:31:32 2023 +0800
assert: Log the assertion expression in case of fail
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
A testcase as following:
child_task()
{
sleep(3);
}
main_task()
{
while (1)
{
ret = task_create("child_task", child_task, );
sleep(1);
task_delete(ret);
}
}
Root casuse:
task_delete hasn's cover the condition that the deleted-task
is justing running on the other CPU.
Fix:
Let the nxsched_remove_readytorun() do the real work
Signed-off-by: ligd <liguiding1@xiaomi.com>
1. When pthread exit, set the default cancellability state to NONCANCELABLE state.
2. Make sure modify tcb->flags is atomic operations.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
This is just unnecessary, a process cannot be destroyed by another
process in any case, every time this is executed the active address
environment is the process getting destroyed.
Even in the hypothetical case this was possible, the system would
crash at once if a context switch happens between "select()" and
"restore()", which is possible as the granule allocator is protected by
a semaphore (which is a synchronization point).
