Anyone know why getpid/getuid still aren’t implemented as vdso?
Fun fact: this is already an issue for the vdso.
gettimeofday(2) can use the CPU builtin cycle counters, but it needs information from the kernel to convert cycles to an actual timestamp (start and scale). This information too can change during the runtime.
To not have userspace trampled over by the kernel, the vdso contains an open-coded spinlock that is used when accessing this information.
I learnt about this while debugging a fun issue with a real-time co-kernel where the userspace thread occasionally ended up deadlocking inside gettimeofday and triggering the watchdog :-)
Unrelated, but what does "open-coded" mean? I never seem to find an obvious answer online.
In my understanding, open-coded means something akin to "manually inlined". Or: written inline while an acceptable alternative exists as a function.
I would appreciate if someone explained why it’s not a vdso rather than just repeating it’s not necessary like that’s a sufficient explanation.
Also given https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47i... while Linus may have changed tack in the decades since I would not expect much support from stating getpid is performance critical to you.
For sure, right up there with naming things and off-by-1s.
The only time your PID would change from a previous value obtained from that very same function is in the child, after a call to fork(), which is itself so heavy, that it would dwarf your calls to getpid
Also, what sort of raving lunatic had a busy loop checking the current process PID? Who allowed such a person access to a compiler? That seems like the bigger problem.
Why aren't the pages shared like other dynamic libraries?
We could use the rseq area for PID and TID.
Having said that I agree that it's probably not worth it to put getpid() into vDSO.
If we're going to add all sorts of dross to the vdso, like getpid(), who knows what else will end up there?
Somehow I doubt the code for getpid as a vdso would meaningfully impact the amount of memory used on a running system nor would I expect any meaningful impact to the number of page table entries. Do you have any supporting evidence for your claim otherwise?
This sounds so mad it needs more context. You don't need to detect when a process is forked, it's an action issued from inside the process?
Or clone3, but with PID namespaces the answer to "what is the PID of a process" is a trickier question.
getpid was a fairly common way to check for fork prior to mechanisms like madvise WIPEONFORK (Linux 4.14, released in 2017). systemd existed prior to 2017 and likely needed to support older kernels past 4.14's initial release. And the getpid cache was something glibc had prior to April 2017, likely to support this kind of use case. It was even documented behavior[1].
So, anyway, what systemd was doing wasn't totally stupid. It became a lot more expensive when glibc broke it on them and then it needed to be improved. But before that it wasn't as objectionable as people in this thread are suggesting.
(Also: pthread_atfork requires linking pthreads, which is or at least historically was seen as a significant burden on applications which do not use pthreads.)