linux-user: Don't assume 0 is not a valid host timer_t value
commit9e59899f8c75e3a7b327eb42ef61818d7f06992e
authorPeter Maydell <peter.maydell@linaro.org>
Mon, 25 Jul 2022 11:00:35 +0000 (25 12:00 +0100)
committerLaurent Vivier <laurent@vivier.eu>
Tue, 27 Sep 2022 11:19:05 +0000 (27 13:19 +0200)
tree494fa6b2350763fde8dce2154478b4a40073c0d7
parent9b9145f04d303354d8da1112577ece26aaf478dd
linux-user: Don't assume 0 is not a valid host timer_t value

For handling guest POSIX timers, we currently use an array
g_posix_timers[], whose entries are a host timer_t value, or 0 for
"this slot is unused".  When the guest calls the timer_create syscall
we look through the array for a slot containing 0, and use that for
the new timer.

This scheme assumes that host timer_t values can never be zero.  This
is unfortunately not a valid assumption -- for some host libc
versions, timer_t values are simply indexes starting at 0.  When
using this kind of host libc, the effect is that the first and second
timers end up sharing a slot, and so when the guest tries to operate
on the first timer it changes the second timer instead.

Rework the timer allocation code, so that:
 * the 'slot in use' indication uses a separate array from the
   host timer_t array
 * we grab the free slot atomically, to avoid races when multiple
   threads call timer_create simultaneously
 * releasing an allocated slot is abstracted out into a new
   free_host_timer_slot() function called in the correct places

This fixes:
 * problems on hosts where timer_t 0 is valid
 * the FIXME in next_free_host_timer() about locking
 * bugs in the error paths in timer_create where we forgot to release
   the slot we grabbed, or forgot to free the host timer

Reported-by: Jon Alduan <jon.alduan@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20220725110035.1273441-1-peter.maydell@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
linux-user/syscall.c