[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 3/3] evtchn/fifo: don't spin indefinitely when setting LINK



>>> On 04.11.13 at 15:52, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> On 04/11/13 14:39, Jan Beulich wrote:
>>>>> On 31.10.13 at 16:03, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>>> If the buggy or malicious guest does cause the loop to exit early, the
>>> newly pending event will be unreachable by the guest and it and
>>> subsequent events may be lost.
>> 
>> ... yet here it is not really clear which guest the last "guest" refers
>> to (i.e. it's fine if the malicious guest harms itself, but the change
>> would be pointless if the malicious guest could still harm the other
>> one).
> 
> The malicious guest loses the event.

So then "that guest" would perhaps be more precise than "the
guest"?

>>> @@ -90,6 +92,8 @@ static void evtchn_fifo_set_pending(struct vcpu *v, 
>>> struct evtchn *evtchn)
>>>          event_word_t *tail_word;
>>>          bool_t linked = 0;
>>>  
>>> +        evtchn->q = q;
>>> +
>>>          spin_lock_irqsave(&q->lock, flags);
>>>  
>>>          /*
>> 
>> I fail to see how this change is related to the rest of the patch.
> 
> This is needed so the correct queue lock is used in evtchn_fifo_unmask().

I guessed that, but I wasn't able to immediately see why that would
not have been a requirement before.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.