On Wed, Nov 09, 2022 at 11:23:01AM +0100, Jan Beulich wrote: > On 09.11.2022 11:11, Roger Pau Monné wrote: > > On Wed, Nov 09, 2022 at 08:48:46AM +0100, Jan Beulich wrote: > >> Finally I'm not convinced of the usefulness of this dying check in the > >> first place: is_dying may become set immediately after the check was > >> done. > > > > While strictly true, this code is executed with the domain lock held, > > so while is_dying might change, domain_kill() won't make progress > > because of the barrier on the domain lock just after setting is_dying. > > I guess I'm confused now: This code is called with the domctl lock > held, which - as said before - is a questionable thing, for serializing > things more than necessary as well as for holding this lock for > excessive periods of time. IOW I consider it wrong to depend on that > in paging_domctl() to synchronize against domain_kill(). Yet indeed that > should eliminate races at present.
Right, both are domctls. There are other places where is_dying get set as part of failures in the domain create paths, but then the paging domctl failing would be natural, as the domain is being destroyed as part of a failed domain create. Since I don't see replies to my other comments, do you agree on returning an error then? Thanks, Roger.
