From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [GIT PULL] Fix lost interrupt race in Xen event channels Date: Mon, 30 Aug 2010 09:48:40 +0100 Message-ID: References: <4C7B8B520200007800012C31@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C7B8B520200007800012C31@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , Daniel Stodden Cc: Jeremy Fitzhardinge , "Xen-devel@lists.xensource.com" , Tom Kopec List-Id: xen-devel@lists.xenproject.org On 30/08/2010 09:43, "Jan Beulich" wrote: >>>> On 30.08.10 at 10:03, "Jan Beulich" wrote: >> Helpful would be if the function returned whether it actually went >> through the mask/unmask pair, as I'm not sure the double >> unmasking really is a good idea, especially in the PIRQ case (for >> the moment I'm considering putting an already-unmasked check >> into both ->eoi() handlers). > > Actually, it seems to me that this check really (also) belongs into > unmask_evtchn(). Keir (I think you wrote this code originally), is > there a reason (other than the implied assumption that it won't > get called on an already unmasked event channel) the function > uses sync_clear_bit() rather than sync_test_and_clear_bit(), > doing the other actions only if the bit wasn't already clear, just > like Xen itself does for the respective hypercall implementation? Well, in 2.6.18 it was at least very unlikely that unmask_evtchn() would be called on an already-unmasked port. And the implementation of unmask-evtchn() is safe in the case that it is called for an already-unmasked port -- it just does a bit more work than necessary in that case. -- Keir