Re: [Xen-devel] [PATCHv3 5/6] evtchn: remove the locking when unmasking an event channel

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.06.15 at 13:36, <david.vrabel@xxxxxxxxxx> wrote:
> On 18/06/15 12:30, Jan Beulich wrote:
>>>>> On 17.06.15 at 14:03, <david.vrabel@xxxxxxxxxx> wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -978,8 +978,6 @@ int evtchn_unmask(unsigned int port)
>>>      struct domain *d = current->domain;
>>>      struct evtchn *evtchn;
>>>  
>>> -    ASSERT(spin_is_locked(&d->event_lock));
>>> -
>>>      if ( unlikely(!port_is_valid(d, port)) )
>>>          return -EINVAL;
>>>  
>>> @@ -1146,9 +1144,7 @@ long do_event_channel_op(int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>          struct evtchn_unmask unmask;
>>>          if ( copy_from_guest(&unmask, arg, 1) != 0 )
>>>              return -EFAULT;
>>> -        spin_lock(&current->domain->event_lock);
>>>          rc = evtchn_unmask(unmask.port);
>>> -        spin_unlock(&current->domain->event_lock);
>> 
>> And, looking particularly at evtchn_fifo_unmask() (and its descendant
>> evtchn_fifo_set_pending()), you get away without acquiring the port
>> lock in or around evtchn_port_unmask()? If indeed so, this one would
>> again be independent on 1, 2, and 4, i.e. could go in together with 3.
> 
> Yes.  This is only dependent on #3 (simplify port_is_valid()).

I'm still not convinced that not taking the port lock is correct: It
is my understanding that e.g. the (last_vcpu_id,last_priority) pair
needs to be updated atomically. Yet nothing prevents the
(notify_vcpu_id,priority) pair now from getting updated in the
middle of it being snapshot in evtchn_fifo_set_pending(). Are you
saying this is no problem?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel