Re: [PATCH v6 0/3] XSA-343 followup patches

[Jürgen Groß <jgross@xxxxxxxx>]

On 18.11.20 09:22, Jan Beulich wrote:
> On 17.11.2020 19:13, Julien Grall wrote:
> > On 09/11/2020 16:38, Juergen Gross wrote:
> > > Juergen Gross (3):
> > >     xen/events: access last_priority and last_vcpu_id together
> > >     xen/evtchn: rework per event channel lock
> > >     xen/evtchn: revert 52e1fc47abc3a0123
> > While looking at the list of commits, I noticed that the first patch
> > hasn't been committed. They were all acked/reviewed, so I am a bit
> > puzzled why this was omitted...
> >
> > I have nearly missed as I was expecting the 3 patches to be committed
> > together. May I suggest that in the future we reply to the cover letter
> > and mention which patches are (or not) committed?
> >
> > Regarding patch #1, I will commit it tomorrow unless there are strong
> > objections against.
> Without a clear outline of what would break with the present logic,
> I had previously indicated I'm not convinced of the change. This
> isn't a strong objection, no, but I still wouldn't want to see my
> name associated with it in such a case. Furthermore I clearly view
> this as not a backporting candidate, while the other two are (as I
> did previously indicate). Hence the latter two patches wanted
> re-basing ahead of the first one anyway, to ease the backports.
Consider an NMI during evtchn_fifo_set_pending() between updating
last_vcpu_id and last_priority, while on another cpu a concurrent
evtchn_fifo_set_pending() is being called. On that other cpu
lock_old_queue() might return a wrong queue as it will read only
the new last_vcpu_id, but not the new last_priority value.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature