[LTP] [PATCH v4 0/4] mmapstress01: refactor to ltp framework

[Cyril Hrubis]

Hi!
> > * I'm failing to see why we need to block SIGALRM just before alarm(0)
> >   as far as I can tell it's completely useless. Also blocking signals
> >   while we refork looks questionable.
> >
> 
> Is the reason it's blocking signals while reforking is due to the second
> choice in https://man7.org/linux/man-pages/man7/signal-safety.7.html?  I'm
> not familiar with signal handling.
> ```
> Block signal delivery in the main program when calling
> functions that are unsafe or operating on global data that is
> also accessed by the signal handler.
> ```

I do not think that this is a valid reason. What that paragraph is
trying to tell is that you either have to avoid calling anything that
modifies global state and may cause trouble or block signals in sections
that do the same but in the normal program context. Either way that
effectively makes sure that such code is never run concurently.

For example calling malloc()/free() modifies locks and data structures
in libc, it's not safe to be called from signal handler and can easily
cause deadlocks and corruptions. Technically you can avoid that either
by not calling malloc()/free() from a signal handler, or by disabling
signal handlers before you call malloc()/free() or anything that may
possibly call malloc()/free() in the rest of the program.

In this case the signal handler is as simple as it gets, it only sets a
global flag that is checked in the while () loop that reforks. And the
only important thing we do there is the fork(). However fork() cannot be
interrupted by a signal and return EINTR so it cannot even fail. It
would probably made some sense if we wanted to setup different signal
handlers in the child and avoid getting signals before we do so, but
that's not the case here either.

So either this is a leftover code that was there to protect something
that has been removed long in the past, or copy&pasted code from a
different test that acutally made use of that. At least I do not see any
other reason to have it there.

-- 
Cyril Hrubis
chrubis@suse.cz