|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/4] xen/watchdog: Drop all locked operations on the watchdog_inuse_map
>>> On 10.05.19 at 20:28, <andrew.cooper3@xxxxxxxxxx> wrote:
> All modifications to the watchdog_inuse_map happen with d->watchdog_lock held,
> so there are no concurrency problems to deal with.
But concurrency problems can also occur for readers. While
not a problem afaict, dump_domains() actually has such an
example (and hence might be worth mentioning here).
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -1068,17 +1068,15 @@ static long domain_watchdog(struct domain *d,
> uint32_t id, uint32_t timeout)
> }
> else /* Allocate the next available timer. */
> {
> - for ( id = 0; id < NR_DOMAIN_WATCHDOG_TIMERS; id++ )
> - {
> - if ( test_and_set_bit(id, &d->watchdog_inuse_map) )
> - continue;
> - break;
> - }
> - if ( id == NR_DOMAIN_WATCHDOG_TIMERS )
> + id = ffs(~d->watchdog_inuse_map) - 1;
I'm surprised we have no (universally available) ffz(). I wonder
though whether find_first_zero_bit() wouldn't be the better
choice here anyway, as the result wouldn't be undefined in
case NR_DOMAIN_WATCHDOG_TIMERS grew to 32.
Also while this looks to be logically independent of patch 2, it
doesn't look like it would apply on its own.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |