Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 19/06/15 14:04, Jan Beulich wrote:
>>>> On 19.06.15 at 14:23, <david.vrabel@xxxxxxxxxx> wrote:
>> On 19/06/15 11:55, Jan Beulich wrote:
>>>>>> On 19.06.15 at 11:52, <david.vrabel@xxxxxxxxxx> wrote:
>>>> On 19/06/15 10:29, Jan Beulich wrote:
>>>>>>>> On 18.06.15 at 12:40, <david.vrabel@xxxxxxxxxx> wrote:
>>>>>> On 18/06/15 11:36, Jan Beulich wrote:
>>>>>>>>>> On 17.06.15 at 14:02, <david.vrabel@xxxxxxxxxx> wrote:
>>>>>>>> --- a/xen/common/event_channel.c
>>>>>>>> +++ b/xen/common/event_channel.c
>>>>>>>> @@ -1175,22 +1175,6 @@ int alloc_unbound_xen_event_channel(
>>>>>>>>  
>>>>>>>>  void free_xen_event_channel(struct domain *d, int port)
>>>>>>>>  {
>>>>>>>> -    struct evtchn *chn;
>>>>>>>> -
>>>>>>>> -    spin_lock(&d->event_lock);
>>>>>>>> -
>>>>>>>> -    if ( unlikely(d->is_dying) )
>>>>>>>> -    {
>>>>>>>> -        spin_unlock(&d->event_lock);
>>>>>>>> -        return;
>>>>>>>> -    }
>>>>>>>> -
>>>>>>>> -    BUG_ON(!port_is_valid(d, port));
>>>>>>
>>>>>> I can keep this one.
>>>>>>
>>>>>>>> -    chn = evtchn_from_port(d, port);
>>>>>>>> -    BUG_ON(!consumer_is_xen(chn));
>>>>>>>
>>>>>>> At least in debug builds I think these would better be retained.
>>>>>>
>>>>>> But this one has to go because it will always trip when
>>>>>> free_xen_event_channel() is called after evtchn_destroy() (which will
>>>>>> have cleared xen_consumer).
>>>>>
>>>>> Then why not
>>>>>
>>>>>     BUG_ON(!consumer_is_xen(chn) && !d->is_dying);
>>>>>
>>>>> or keep the d->is_dying check in place? I can see why accelerating
>>>>> notify_via_xen_event_channel() is useful, but
>>>>> free_xen_event_channel()?
>>>>
>>>> This BUG_ON() is a pretty weak check and I don't really see the point of
>>>> it.  I'm not respinning v4 just for this.
>>>
>>> I'm not sure what makes this more weak than the other BUG_ON()
>>> you agreed to retain - both try to validate that the callers don't do
>>> bad things. Admitted, both would better be ASSERT()s...
>>>
>>> As to spinning v4 - I see no need, as I can easily adjust this while
>>> committing, as long as you don't disagree to have your name under
>>> the result.
>>
>> I disagree.
>>
>> For this assert to be safe it needs to take suitable locks such as:
>>
>> #ifdef DEBUG
>>     struct evtchn *chn;
>>
>>     chn = evtchn_from_port(d, port);
>>     spin_lock(&chn->lock);
>>     BUG_ON(chn->state != ECS_FREE && !consumer_is_xen(chn));
>>     spin_unlock(&chn->lock);
>> #endif
>>
>> or if you want the is_dying check, you need the event lock instead.
>>
>> I wrote the first one, saw it was lots of noise for almost no gain and
>> threw it away.
> 
> Which is why as an alternative I suggested not to touch
> free_xen_event_channel() at all in this patch.

I found the this is_dying check confusing and since it is now
unnecessary and not very useful it is better to remove it to make the
code easier for others to understand.

David


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