On Wed, Feb 28, 2024 at 02:04:23PM +0100, Jan Beulich wrote: > On 28.02.2024 13:19, Andrew Cooper wrote: > > Take 2, hopefully with Stewart's correct email address this time. > > > > ~Andrew > > > > On 28/02/2024 12:17 pm, Andrew Cooper wrote: > >> Not sure how well this is going to be formatted, but there's one new and > >> potentially interesting issue found by Coverity. > > To be honest I didn't consider this interesting at all, but instead a false > positive due to limited insight that the tool has. But maybe I was wrong > and you see something I didn't see? vpci_process_pending() is vCPU-local > (run from the guest resume path), and hence there simply are no two threads > who want to look at the field. Storing NULL into it is merely a kind of > progress indicator, relevant to the given vCPU only.
Indeed, there's no (intended) way for vpci_process_pending() to be executed concurrently against the same vcpu parameter, and hence there should be no concurrency hazards. Setting it to NULL is a mere indication there's no further work to be done, and the vCPU can resume guest context execution. defer_map() (the function that queues the work to be done) can only be reached as a result of a guest accessing the PCI config space, so if the vCPU is not running defer_map() can't be called either for that vCPU. Thanks, Roger.
