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 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.

David

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