From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final() Date: Fri, 19 Jun 2015 17:58:42 +0100 Message-ID: <55844A42.5060401@citrix.com> References: <1434542583-28073-1-git-send-email-david.vrabel@citrix.com> <1434542583-28073-3-git-send-email-david.vrabel@citrix.com> <5582BB4C02000078000868FB@mail.emea.novell.com> <5582A02A.9050803@citrix.com> <5583FD0F0200007800086EF1@mail.emea.novell.com> <5583E655.2070807@citrix.com> <5584115D0200007800086FC4@mail.emea.novell.com> <558409A6.7080006@citrix.com> <55842F8402000078000870ED@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z5zcz-0003eF-Ke for xen-devel@lists.xenproject.org; Fri, 19 Jun 2015 16:58:53 +0000 In-Reply-To: <55842F8402000078000870ED@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Keir Fraser , Ian Campbell , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 19/06/15 14:04, Jan Beulich wrote: >>>> On 19.06.15 at 14:23, wrote: >> On 19/06/15 11:55, Jan Beulich wrote: >>>>>> On 19.06.15 at 11:52, wrote: >>>> On 19/06/15 10:29, Jan Beulich wrote: >>>>>>>> On 18.06.15 at 12:40, wrote: >>>>>> On 18/06/15 11:36, Jan Beulich wrote: >>>>>>>>>> On 17.06.15 at 14:02, 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