[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()
>>> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |