i#4953 Ubuntu20: Fix linux.syscall_pwait hang.

Fixes hang at the syscall ppoll_time64 by handling it same as ppoll. The former is the year-2038-safe variant of the latter, that allows a wider field for timestamp, as the year 2038 will see a unix timestamp greater than 2^31.

Adds new syscalls up to Linux kernel 5.10.46.

Adds a warning for new syscalls other than ppoll_time64 that are not handled yet and have a similarly named variant that needs special handling. E.g. SYS_clone has special handling, so added a warning for SYS_clone3.

Also upgrades Ubuntu version for the x86-32 bit GA CI to 20.04.

Issue: #5131 (closed) Fixes: #4953 (closed)

requested review from @derekbruening

This gap looks suspicious: but on inspection it seems to be deliberate.

__NR_pidfd_send_signal onwards syscall number assignments seem to align on 32- and 64-bit, and the space is perhaps for arch-specific syscalls. https://github.com/torvalds/linux/commit/0d6040d4681735dfc47565de288525de405a5c99

Hmm should the warning then be under -xarch_root too?

Yeah, there should be. Done.

Wait, this syscall is ignorable if xarch_root is not set right? That is the case this PR doesn't print warning for currently. If xarch_root is set, the pre and post handling will print the warning anyway.

The xarch_root path manipulation seems to be very targeted to what the loader uses: it is only looking at openat and not at open. So if the loader switched to using open it would also find the wrong lib w/o a warning: but these are easy errors to find since you'd get the wrong arch and see the error right away; plus these are common syscalls so we don't want to intercept (and avoid inlining) if we can avoid it.

Okay so no warning then in any case?

I don't have a strong opinion for the -xarch_root case, could go either way.

Removed it.

Add a test to suite/tests/linux/syscall_pwait.cpp (maybe just the raw version, a la psyscall_raw_ppoll) under ifdef SYS_ppoll_time64?

Done.

requested review from @derekbruening

I think this should be removed: we don't care about open and so are unlikely to care about openat2.

But we do care about SYS_openat, which is why I assumed we should atleast warn for SYS_openat2. Xref the discussion in the other comment thread: IIUC we expect any issues with openat2 handling to be clearly visible, and that is why we want to remove the warning?

If -xarch_root is not set I don't think there should be any warning.

Removed it.

approved this merge request

Merged by: abhinav92003 at 2021-09-29 23:11:53 UTC

closed