Date: Wed, 6 May 2020 13:20:40 +0100
From: Geoff Clare <[email protected]>
Message-ID: <[email protected]>
| Why so averse to what is obviously the simplest and cleanest solution?
Simple, perhaps (certainly for the libc code, not so much for the kernel)
clean, not even close.
| If you don't want to do the string processing in the kernel, then
| you can have the userland function create an array of pathnames to
| try loading.
That's fractionally better, but not a lot.
| That approach won't work because it will repeat the list of file actions,
| some of which might not be idempotent.
The only possibility I can see is open(O_CREAT|O_EXCL), or (O_CREATE, 0444)
- I'd be willing to simply allow those ones to fail (tell people not to use
those combinations with posix_spawnp() - they aren't very likely cases)
if that is the sole drawback.
open(O_CREAT) is the only thing that alters anything that isn't local
to the new (child) process image that I can see (there's no unlink file
action I don't believe - having that would cause problems), and everything
done in that vanishes as soon as the posix_spawn() fails.
The alternative seems to be either extreme ugliness, or not allowing
the chdir file actions at all with posix_spawnp() - and I know which
of those I'd prefer (especially as nothing uses it anyway...)
| Also, how would you distinguish between a path related error caused
| by the attempted image load from one caused by one of the file actions?
You don't - you err on the side of caution, if it might be a path error,
treat it that way. If it is a file action error, the effect will be that
we get the same error once for each prefix in PATH (the error won't magically
go away). That's a little ineffecient, but it's only for an unlikely
case (an error case), so doesn't really matter.
kre
