On 28/02/2024 1:26 pm, Roger Pau Monné wrote: > 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.
Fine. So long as someone has looked into it and thinks we're fine. ~Andrew
