Re: Is zero a valid value for the pid member of the AUDIT_SIGNAL_INFO message?

> pid=-1 has a special meaning for signals. But in terms of seeing it in a > sigaction handler for siginfo, not possible. So its a good init value. If > you look at sigaction(2), there is a si_code that indicates why the > signal was sent. One of them is SI_KERNEL. So, its possible that the > kernel decides to send a signal on certain occasions. That message is only sent on request from userspace, so I suppose userspace could request that information at any time, but the only time it would be meaningful is after that userspace process has received a signal.

> > I looked at converting audit_sig_pid from pid_t to struct pid *, but > > then get_pid() would also be needed to protect that reference. A > > put_pid() would need to be done once it is no longer needed, which could > > be immediately after it is read in the AUDIT_SIGNAL_INFO message > > preparation, assuming it would never need to be read again. If this > > isn't the case, put_pid() could be called when audit_pid is nulled, but > > if that message never comes, that struct pid is stuck with a stale > > refcount. (That isn't an issue if it is init or systemd, but it is > > still wrong.) > > > > This looks more and more like overkill and should probably leave > > audit_sig_pid as pid_t. > > The code has been working good for a long time. I am wondering if the > original intent was to make it general in case we decided to add more > signals that we are interested in. Such as HUP to reread config or other possibilities?