Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] SMP signal dispatch seems racy #14807

Open
1 task done
yamt opened this issue Nov 15, 2024 · 4 comments
Open
1 task done

[BUG] SMP signal dispatch seems racy #14807

yamt opened this issue Nov 15, 2024 · 4 comments
Labels
Arch: all Issues that apply to all architectures Area: Kernel Kernel issues OS: Mac Issues related to MacOS (building system, etc) Type: Bug Something isn't working

Comments

@yamt
Copy link
Contributor

yamt commented Nov 15, 2024

Description / Steps to reproduce the issue

the signal sending logic (kill) basically does:

  1. enter_critical_section
  2. decide the target thread
  3. check signal mask of the thread
  4. make a cross call to the target cpu (nxsched_smp_call_single)

as nxsched_smp_call_single drops the critical section, there seems to be nothing to prevent the signal mask from changing in the meantime. it can end up with a signal delivered while being blocked.

similarly, the need_restore logic in sig_handler seems dangerous as it can revert unrelated changes to those fields.

On which OS does this issue occur?

[OS: Mac]

What is the version of your OS?

macOS 14.7

NuttX Version

master

Issue Architecture

[Arch: all]

Issue Area

[Area: Kernel]

Verification

  • I have verified before submitting the report.
@yamt yamt added the Type: Bug Something isn't working label Nov 15, 2024
@github-actions github-actions bot added Arch: all Issues that apply to all architectures Area: Kernel Kernel issues OS: Mac Issues related to MacOS (building system, etc) labels Nov 15, 2024
@xiaoxiang781216
Copy link
Contributor

@hujun260 please look at this issue.

@hujun260
Copy link
Contributor

hujun260 commented Nov 15, 2024

as nxsched_smp_call_single drops the critical section, there seems to be nothing to prevent the signal mask from changing in the meantime. it can end up with a signal delivered while being blocked.

I don't think this change caused #14749,
because the release of the critical section is going to happen regardless of whether I call nxsched_smp_call_single or not.
image

similarly, the need_restore logic in sig_handler seems dangerous as it can revert unrelated changes to those fields.

There are two fields: affinity and flag.
Due to the setting of TCB_FLAG_CPU_LOCKED, the affinity will not be changed during the process.
image

The tcb->flags may undergo changes, which I can further refine. During restoration, only the TCB_FLAG_CPU_LOCKED field of tcb->flags will be restored, without altering any other fields.
#14812

@yamt
Copy link
Contributor Author

yamt commented Nov 15, 2024

as nxsched_smp_call_single drops the critical section, there seems to be nothing to prevent the signal mask from changing in the meantime. it can end up with a signal delivered while being blocked.

I don't think this change caused #14749, because the release of the critical section is going to happen regardless of whether I call nxsched_smp_call_single or not. image

i don't understand your logic.
in non cross call case, the critical section is released after up_schedule_sigaction.

@hujun260
Copy link
Contributor

in non cross call case, the critical section is released after up_schedule_sigaction.

Regardless of whether it crosses cores, up_schedule_sigaction will be invoked, and nxsched_smp_call_single will wait until up_schedule_sigaction has been called and returns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Arch: all Issues that apply to all architectures Area: Kernel Kernel issues OS: Mac Issues related to MacOS (building system, etc) Type: Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants