Hi Lennart,
On 04/03/2022 09:44, Lennart Poettering wrote:
On Fr, 04.03.22 09:26, Christopher Obbard (chris.obbard@xxxxxxxxxxxxx) wrote:
Right, so it looks like the call to close_range fails. This is a 5.4 kernel
which doesn;t have close_range - so this is understandable.
For a quick fix, I set have_close_range to false - see the patch attached.
It seemed to work well.
Since my 5.4 kernel is a heavily modified downstream one - next I will check
if that syscall was implemented by someone else, and also I will check if
vanilla systemd works on vanilla 5.4 (there is no reason why it shouldn't,
right?).
Hmm, this is strange. Our code already has fallback paths in place to
handle cases where the syscall is not implemented, i.e. where we see
ENOSYS when we call it. Our code should handle this perfectly already.
Is it possible that your patched kernel added non-standard syscalls
under the syscall numbers the official kernel later assigned to
close_range()? If so, this would explain that we see EINVAL, as of
course we call the syscall assuming it was close_range(), but if it is
actually something else mit very likely might not be able to make
sense of our parameters and thus return EINVAL.
In this case I am not very sympathetic to your case: squatting syscall
numbers is just a terrible idea...
Even worse: it turns out they backported the process_madvise syscall to
5.4 and changed the syscall number to be the same as close_range.
There are terrible ideas, then there is just being plain evil ;-).
Thanks for all the help.
Chris
