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

[Edward Liaw]

>
> 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


Thanks for the explanation!  That makes sense.

Thanks,
Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20221013/84024ece/attachment.htm>