Page MenuHomeFreeBSD

itimer: Serialize accesses to p->p_itimers
ClosedPublic

Authored by markj on Aug 31 2021, 7:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Apr 28, 9:16 AM
Unknown Object (File)
Sun, Apr 14, 5:29 PM
Unknown Object (File)
Mon, Apr 8, 1:56 PM
Unknown Object (File)
Mar 17 2024, 10:26 AM
Unknown Object (File)
Mar 3 2024, 4:16 AM
Unknown Object (File)
Jan 2 2024, 11:43 PM
Unknown Object (File)
Dec 21 2023, 7:35 PM
Unknown Object (File)
Dec 20 2023, 7:57 AM
Subscribers

Details

Summary

Fix a subtle race between itimer_proc_continue() and process exit.

itimer_proc_continue() may be called via realitexpire(), the real
interval timer. Note that exit1() drains this timer _after_ draining
and freeing itimers. Moreover, itimers_exit() is called without the
process lock held; it only acquires the proc lock when deleting
individual itimers, so once they are drained we free p->p_itimers
without any synchronization. Thus, itimer_proc_continue() may load a
non-NULL p->p_itimers array and iterate over it after it has been freed.

Fix the problem by using the process lock to synchronize with
itimer_proc_continue(). Since itimers are allocated lazily I think the
extra overhead is acceptable. Another solution may be to short-circuit
execution of itimer_proc_continue() if P_WEXIT is set.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Aug 31 2021, 7:19 PM
kib added inline comments.
sys/kern/kern_time.c
1825–1826

I think an explanation is needed there, that the lock is not about protecting the assignment as is, but to sync assignment with the itimer_proc_continue().

This revision is now accepted and ready to land.Aug 31 2021, 8:17 PM
This revision now requires review to proceed.Aug 31 2021, 8:19 PM
This revision is now accepted and ready to land.Aug 31 2021, 8:29 PM