Re: [PATCH] multipathd: fix inverted signal blocking logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2018-03-03 at 00:16 +0100, Martin Wilck wrote:
> On Fri, 2018-03-02 at 22:23 +0000, Bart Van Assche wrote:
> > On Fri, 2018-03-02 at 23:15 +0100, Martin Wilck wrote:
> > > On Fri, 2018-03-02 at 21:35 +0000, Bart Van Assche wrote:
> > > > This change looks more complicated to me than necessary. Have you
> > > > considered
> > > > to pass an empty signal set as the fourth ppoll() argument?
> > > 
> > > An empty set would mean that no signal is blocked during ppoll().
> > > Therefore e.g. SIGALRM would terminate multipathd if it arrives
> > > during the ppoll (no handler set, and default action is "Term").
> > 
> > Have you considered to only block SIGALRM while ppoll() is in
> > progress?
> 
> Why should we? The same reasoning applies to other signals such as e.g.
> SIGUSR2. We need to block all signals except those that we can handle.

I see two reasons:
- All signals that are delivered to the multipathd process except SIGALRM
  should interrupt ppoll(). SIGPIPE is delivered to the thread that caused
  that signal to be raised. SIGUSR2 is sent to a specific thread. Hence
  neither SIGPIPE nor SIGUSR2 will ever be delivered to the thread that
  calls ppoll().
- Asking ppoll() to block all signals is weird because some signals, e.g.
  SIGKILL and SIGSTOP, cannot be blocked.

Bart.

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux