Re: [PATCH v3 3/4] kselftest/arm64: Add tests for SVE vector configuration

On Mon, Aug 02, 2021 at 01:37:50PM +0100, Dave Martin wrote:

On Mon, Aug 02, 2021 at 12:33:30PM +0100, Mark Brown wrote:

quoted

That really doesn't seem like a good idea - it's just asking for
fragility if a signal gets delivered to the parent process or something.
Even if almost all the time there will only be one trip through the loop
we should still have the loop there for those few cases where it
triggers.

This concern only applies when the program actually registers signal
handlers.

wait() can't return for any other reason, and it mustn't, precisely
because historically software would have made this assumption.  This is
one reason why wait3() etc. are separate functions.

That's great for the reader with a detailed knowledge of exactly what
error handling can be skipped and how standards conforming Linux is but
less good for the reader who is merely aware of best practices.  I am
not clear what the problem that is solved by removing the loop here is
TBH - to me it just makes it less obvious that we've handled everything.

That aside though, can't we use popen(3)?

I tend to forget about popen because it is "boring" to use it, but it
looks like it fits this case quite well.  Then it would be libc's
problem how to fork and wait safely.

popen() appears to be break the _SET_VL_ONEXEC test.  Between a lack of
strace in my test filesystem and not spotting anything obvious in the
glibc sources I can't tell exactly where it's doing something different,
though it does feel like it should be a separate testcase if it's
anything interesting.  I do think there is value in having exactly
what's done to start the child process be clear in the test program, and
that coverage of anything interesting from popen() could be done
incrementally.