You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by "patacongo (via GitHub)" <gi...@apache.org> on 2023/05/16 16:13:53 UTC
[GitHub] [nuttx] patacongo opened a new issue, #9298: Signal must be masked when it is delivered to a signal handler
patacongo opened a new issue, #9298:
URL: https://github.com/apache/nuttx/issues/9298
Signal must be masked when it is delivered to a signal handler per:
> https://pubs.opengroup.org/onlinepubs/007904875/functions/sigaction.html
> When a signal is caught by a signal-catching function installed by sigaction(), a new signal mask is calculated and installed for the duration of the signal-catching function (or until a call to either [sigprocmask()](https://pubs.opengroup.org/onlinepubs/007904875/functions/sigprocmask.html) or [sigsuspend()](https://pubs.opengroup.org/onlinepubs/007904875/functions/sigsuspend.html) is made). This mask is formed by taking the union of the current signal mask and the value of the sa_mask for the signal being delivered [XSI] [Option Start] unless SA_NODEFER or SA_RESETHAND is set, [Option End] and then _including the signal being delivered_. If and when the user's signal handler returns normally, the original signal mask is restored.
Any action queued for that signal while the signal is masked should be deferred. It should go into the group pending signal list and should not be processed until until the signal is unmasked (which should occur when the signal handler returns).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] xiaoxiang781216 closed issue #9298: Signal must be masked when it is delivered to a signal handler
Posted by "xiaoxiang781216 (via GitHub)" <gi...@apache.org>.
xiaoxiang781216 closed issue #9298: Signal must be masked when it is delivered to a signal handler
URL: https://github.com/apache/nuttx/issues/9298
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] patacongo commented on issue #9298: Signal must be masked when it is delivered to a signal handler
Posted by "patacongo (via GitHub)" <gi...@apache.org>.
patacongo commented on issue #9298:
URL: https://github.com/apache/nuttx/issues/9298#issuecomment-1550119585
> I think the issue is a signal maybe delivered while its handler is running (the nested case being the shortest path to expose it) , so yes, it needs to be withheld or block (to let that handler a chance to exit).
This PR fixes the problem because it eliminates _all_ nesting. There was a window in which xcp.sigdeliver was NULL when it should not have been. That permitted an unsupported nested signal action to occur because of the logic in https://github.com/apache/nuttx/blob/master/arch/arm/src/armv7-m/arm_schedulesigaction.c#L88
In the current design, any nested signal will clobber xcp.sigdelver and crash the system. This PR does not change that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] mu578 commented on issue #9298: Signal must be masked when it is delivered to a signal handler
Posted by "mu578 (via GitHub)" <gi...@apache.org>.
mu578 commented on issue #9298:
URL: https://github.com/apache/nuttx/issues/9298#issuecomment-1550138175
You write faster that I can read (I have a slow morning today). Yes about priority handling, not particularly just for signal API, it is always nice to have.
Anyway, in a general context, any item which is enqueued should be considered read-only ; it could be handled with a private bitset ; because if something is marked deferred ; it should not be possible to externally change it (user).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] patacongo commented on issue #9298: Signal must be masked when it is delivered to a signal handler
Posted by "patacongo (via GitHub)" <gi...@apache.org>.
patacongo commented on issue #9298:
URL: https://github.com/apache/nuttx/issues/9298#issuecomment-1550095150
Here is where one-at-a-time signal handler is handled for ARMv7M: https://github.com/apache/nuttx/blob/master/arch/arm/src/armv7-m/arm_schedulesigaction.c#L88
/* Refuse to handle nested signal actions */
if (tcb->xcp.sigdeliver == NULL)
{
So I suspect that fact that you are seeing nested signal handling in this case is ONLY due to the fact that xcp.sigdeliver is NULL when it should be non-NULL (because we really are in a signal handler).
This results in the error:
- The signal handler is incorrectly entered while a signal handler is being processed.
- As a consequence the saved xcp.sigdeliver is clobber and an infinite loop results.
This change is correct because there should be no window where xcp.sigdeliver is NULL while we are in a signal handler. But I don't think this is the root cause of the problem.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] mu578 commented on issue #9298: Signal must be masked when it is delivered to a signal handler
Posted by "mu578 (via GitHub)" <gi...@apache.org>.
mu578 commented on issue #9298:
URL: https://github.com/apache/nuttx/issues/9298#issuecomment-1550004037
I think the issue is a signal maybe delivered while its handler is running, so yes, it needs to be withheld or block. `Are nested signals should be banned? (absolutism)` I don't know might break legit things out there.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] patacongo commented on issue #9298: Signal must be masked when it is delivered to a signal handler
Posted by "patacongo (via GitHub)" <gi...@apache.org>.
patacongo commented on issue #9298:
URL: https://github.com/apache/nuttx/issues/9298#issuecomment-1550099729
> Why would you interrupt one handler to run another versus letting the current handler run to completion first.
Signals do have a priority associated with them and should run in priority order. So it might not be a bad thing to permit a higher priority signal to interrupt a lower priority signal. Unfortunately signal prioritization is not currently supported: #8899
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] patacongo commented on issue #9298: Signal must be masked when it is delivered to a signal handler
Posted by "patacongo (via GitHub)" <gi...@apache.org>.
patacongo commented on issue #9298:
URL: https://github.com/apache/nuttx/issues/9298#issuecomment-1550085217
> Should nested signals be banned? (absolutism)
I am not sure. Certainly be default, handles for the same signal number are forced to be sequential (by the POSIX the requirement to mask the signal on entry into the signal handler). But:
- You can always modify the sigprocmask within the signal handler, and
- That would not apply to other signals.
Interrupting one signal handler to process another implies some priority handling of signals. Why would you interrupt one handler to run another versus letting the current handler run to completion first. I think that the dispatch logic currently will not permit nested signal handlers (but I would need to verify that).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] patacongo commented on issue #9298: Signal must be masked when it is delivered to a signal handler
Posted by "patacongo (via GitHub)" <gi...@apache.org>.
patacongo commented on issue #9298:
URL: https://github.com/apache/nuttx/issues/9298#issuecomment-1550052005
Close with #9299
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org