Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1415247

Re: SIGSYS annoyance

Show all headers | View raw

On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1176099
>
> Should SIGSYS be delivered to the handler even if blocked?  What, if
> anything, does POSIX say?  All I can find is in pthread_sigmask(3p):
>
> If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated
> while they are blocked, the result is undefined, unless the signal was
> generated by the action of another process, or by one of the functions
> kill(), pthread_kill(), raise(), or sigqueue().
>
> It would be easy enough to change our behavior so that we deliver the
> signal even if it's blocked or to at least add a flag so that users
> can request that behavior.

I had trouble following that bug. It sounded like glib just needed a
way to define its signal mask, and that's what they ended up
implementing?

I think the current behavior is correct. SIGSYS is being generated by
the running process (i.e. the seccomp filter) and if it has a handler
but the signal is blocked, we should treat it as uncaught and kill. On
the other hand, it could be seen like "raise", in which case the
blocking should be ignored? Is there an active problem somewhere here?
It seems like the referenced bug has been fixed already.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

SIGSYS annoyance Andy Lutomirski <luto@amacapital.net> - 2016-06-04 07:20 +0200
  Re: SIGSYS annoyance Kees Cook <keescook@chromium.org> - 2016-06-06 18:10 +0200
    Re: SIGSYS annoyance Andy Lutomirski <luto@amacapital.net> - 2016-06-09 19:30 +0200
      Re: SIGSYS annoyance Mikael Pettersson <mikpelinux@gmail.com> - 2016-06-10 11:10 +0200

csiph-web