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)
Fri, Dec 13, 3:54 AM
Unknown Object (File)
Oct 27 2024, 6:54 PM
Unknown Object (File)
Oct 14 2024, 6:06 AM
Unknown Object (File)
Oct 1 2024, 5:05 PM
Unknown Object (File)
Sep 26 2024, 5:30 PM
Unknown Object (File)
Sep 26 2024, 5:30 PM
Unknown Object (File)
Sep 26 2024, 5:30 PM
Unknown Object (File)
Sep 26 2024, 5:30 PM
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