Re: Fwd: New Defects reported by Coverity Scan for XenProject

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.