[v5,0/2] XSA-343 followup patches

Message

Juergen Gross Nov. 9, 2020, 6:41 a.m. UTC

The patches for XSA-343 produced some fallout, especially the event
channel locking has shown to be problematic.

Patch 1 is targeting fifo event channels for avoiding any races for the
case that the fifo queue has been changed for a specific event channel.

The second patch is modifying the per event channel locking scheme in
order to avoid deadlocks and problems due to the event channel lock
having been changed to require IRQs off by the XSA-343 patches.

Changes in V5:
- moved evtchn_write_[un]lock() to event_channel.c (Jan Beulich)
- used normal read_lock() in some cases (Jan Beulich)

Changes in V4:
- switched to real rwlock

Changes in V3:
- addressed comments

Juergen Gross (2):
  xen/events: access last_priority and last_vcpu_id together
  xen/evtchn: rework per event channel lock

 xen/arch/x86/irq.c         |   6 +-
 xen/arch/x86/pv/shim.c     |   9 +--
 xen/common/event_channel.c | 144 +++++++++++++++++++++----------------
 xen/common/event_fifo.c    |  25 +++++--
 xen/include/xen/event.h    |  32 ++++++---
 xen/include/xen/sched.h    |   8 ++-
 6 files changed, 136 insertions(+), 88 deletions(-)

Comments

Jan Beulich Nov. 9, 2020, noon UTC | #1

On 09.11.2020 07:41, Juergen Gross wrote:
> The patches for XSA-343 produced some fallout, especially the event
> channel locking has shown to be problematic.
> 
> Patch 1 is targeting fifo event channels for avoiding any races for the
> case that the fifo queue has been changed for a specific event channel.
> 
> The second patch is modifying the per event channel locking scheme in
> order to avoid deadlocks and problems due to the event channel lock
> having been changed to require IRQs off by the XSA-343 patches.
> 
> Changes in V5:
> - moved evtchn_write_[un]lock() to event_channel.c (Jan Beulich)
> - used normal read_lock() in some cases (Jan Beulich)
> 
> Changes in V4:
> - switched to real rwlock
> 
> Changes in V3:
> - addressed comments
> 
> Juergen Gross (2):
>   xen/events: access last_priority and last_vcpu_id together
>   xen/evtchn: rework per event channel lock

Didn't you mean to add a 3rd patch here to drop the 2nd call to
xsm_evtchn_send() again?

Jan

Juergen Gross Nov. 9, 2020, 1:05 p.m. UTC | #2

On 09.11.20 13:00, Jan Beulich wrote:
> On 09.11.2020 07:41, Juergen Gross wrote:
>> The patches for XSA-343 produced some fallout, especially the event
>> channel locking has shown to be problematic.
>>
>> Patch 1 is targeting fifo event channels for avoiding any races for the
>> case that the fifo queue has been changed for a specific event channel.
>>
>> The second patch is modifying the per event channel locking scheme in
>> order to avoid deadlocks and problems due to the event channel lock
>> having been changed to require IRQs off by the XSA-343 patches.
>>
>> Changes in V5:
>> - moved evtchn_write_[un]lock() to event_channel.c (Jan Beulich)
>> - used normal read_lock() in some cases (Jan Beulich)
>>
>> Changes in V4:
>> - switched to real rwlock
>>
>> Changes in V3:
>> - addressed comments
>>
>> Juergen Gross (2):
>>    xen/events: access last_priority and last_vcpu_id together
>>    xen/evtchn: rework per event channel lock
> 
> Didn't you mean to add a 3rd patch here to drop the 2nd call to
> xsm_evtchn_send() again?

I wanted to that after this series has been accepted, but I can include
it here, of course.


Juergen