Because what getpid returns can change during the lifetime of a process, if it moves to a different PID namespace. I guess updating the vdso every time that happens is not worth the little gains.
> ... can change during the lifetime of a process, ...
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 :-)
Does avoiding userspace being trampled by the kernel mean avoiding a context switch? Does the kernel write to userspace-accessible memory that the spinlock guards?
Unrelated, but what does "open-coded" mean? I never seem to find an obvious answer online.
st_goliath|2 years ago
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 :-)
vacuity|2 years ago
Unrelated, but what does "open-coded" mean? I never seem to find an obvious answer online.