4 ms·
It sounds like exit_signals() is being called too early, and based on the test case linked this might be a library issue rather than a code or kernel issue? Ed
by mjevans 3y ago
It sounds like exit_signals() is being called too early, and based on the test case linked this might be a library issue rather than a code or kernel issue?
Edit: Reading the article it's more clear this happens in kernel's:
do_exit() {
...
exit_signals(tsk); /* sets PF_EXITING */
...
exit_files(tsk);
Would a better solution not be to exit_signals(tsk); later in do_exit() after all possible signal sources are exhausted?
- loeg 3y ago> It sounds like exit_signals() is being called too early Or zap_pid_ns too late, yeah.
- cryptonector 3y agoLater would be better, no? Since it'd allow the FUSE process to outlive the init process, thus allowing the flushes to complete.
- cryptonector 3y agoIt doesn't matter. Filesystem waits are historically non-interruptible. The correct fix is indeed to allow the flushes to fail fast rather than wait forever.