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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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