This is a follow-up to the following, or any subsequent versions of it:
https://lore.kernel.org/all/[email protected]/
This patchset brings distinction between the set of blocked signals stored
in uc_sigmask, and the actual set of blocked signals. Also, fix a wrong
mention of sigprocmask(), and replace it with sigaction().
Changes in v2:
- Make the description clear and concise
- Use semantic newlines
Dev Jain (2):
signal.7: Clearly describe ucontext kernel dump to userspace
signal.7: Fix wrong mention of sigprocmask
man/man7/signal.7 | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--
2.34.1
The handler is registered with sigaction(), not sigprocmask(). Even if the
purpose of writing sigprocmask() here was to mention blocked signals, the
statement currently concerns the "addition" of blocked signals; signals
blocked through sigprocmask() would already be present in the thread
context of blocked signals.
Fixes: e7a5700 (getcontext.3, signal.7: tfix)
Signed-off-by: Dev Jain <[email protected]>
---
man/man7/signal.7 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/man7/signal.7 b/man/man7/signal.7
index 7d22a7cfe..57eab7847 100644
--- a/man/man7/signal.7
+++ b/man/man7/signal.7
@@ -293,7 +293,7 @@ contain the mask of new signals blocked through
Any signals specified in
.I act\->sa_mask
when registering the handler with
-.BR sigprocmask (2)
+.BR sigaction (2)
are added to the thread's signal mask.
The signal being delivered is also
added to the signal mask, unless
--
2.34.1
On Tue, Jun 11, 2024 at 02:38:23PM +0530, Dev Jain wrote:
> The handler is registered with sigaction(), not sigprocmask(). Even if the
> purpose of writing sigprocmask() here was to mention blocked signals, the
> statement currently concerns the "addition" of blocked signals; signals
> blocked through sigprocmask() would already be present in the thread
> context of blocked signals.
Reviewed-by: Mark Brown <[email protected]>