Implement ionice

[mmclinton]

ionice shows or changes the I/O scheduling class and priority of a process. This is all of ionice(1): -c, -n, -p, -P, -u, -t, -h, -V, reading a priority with no arguments, setting one on a pid, pgid or uid, and running a command under a priority with the 126 and 127 statuses that go with a failed exec. No option is half implemented. It is Linux only; the other targets compile and exit 1 with a message.

I built this against util-linux 2.42.2 and checked it against 2.37.4, 2.39.2 and 2.41.1 as well, comparing stdout, stderr, exit status and the arguments of the ioprio_get and ioprio_set syscalls over 139 invocations. Those four references do not differ from each other on a single one of those cases, so what follows holds for all of them.

The documented ranges are enforced

-c outside 0-3 and -n outside 0-7 are rejected with exit status 1 and no syscall. util-linux accepts most of them and exits 0 - it refuses only the ones whose wrap lands on a class the kernel will not take, such as -c 4 and -n -1 - so this is a deliberate divergence in which arguments succeed, not just in what gets printed. It is the question I raised in #624, and the answer there was to enforce and document.

The reason it is worth a divergence is that the accepted values do not mean what they read as. The kernel takes the class from three bits and reads the level modulo eight, so ionice -c 99 runs idle, ionice -n 8192 changes the class outright, and -n 8 is accepted as a level of 0 - the highest best-effort priority, one step past the bottom of the documented range rather than one step below it. -c 10 prints unknown prio class 10 and then runs best-effort at exit 0 anyway; with -t it prints nothing at all.

Three things follow that whoever reviews this may otherwise notice:

• The ionice: unknown prio class N warning does not exist here, because no class can be unknown any more. -t therefore has one fewer thing to silence.
• Exit status 1 is a choice for the values util-linux accepts. It exits 0 for those, so there was no status to copy, and 1 is what it already uses for the argument errors it does diagnose. For the values it refuses outright, -c 4 and -n -1 among them, we agree with it at 1.
• A value too wide for an i32 still reports ERANGE, unchanged, because the reference errors there too.

ionice.md and --help are deliberately not amended. They already state both ranges, and per Sylvestre's advice this body is the disclosure.

Two behaviors that are not in ionice(1)

Neither is visible in the output, and both are matched here:

• The idle class always carries priority level 7 and none always carries 0, whatever -n asks for.
• A lone id of 0 on the read path means the calling process, not the process group or the user numbered 0.

The syscalls

There are no libc wrappers for ioprio_get and ioprio_set, so ioprio.rs calls them through syscall(). Those two blocks are the only unsafe in the crate.

What the tests do not cover

55 integration tests, plus one for the non-Linux arm. Four items worth naming:

• No root path. A successful realtime set needs CAP_SYS_NICE, so only the EPERM refusal is tested. A user namespace does not help: the kernel checks realtime ioprio against the initial user namespace, so uid 0 inside unshare -Ur is refused exactly as before.
• Write-and-read-back only covers -p. -P and -u writes are never verified against a live target.
• Nothing exercises -c or -n on a process the caller does not own beyond the EPERM case, which earns its refusal from pid 1 belonging to root rather than from the class being lowered.
• Untested: architectures other than x86_64, signal delivery during exec, and very large id lists.

Closes #624