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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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()?

Jan


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