From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: xen kernel crash at boot since 23598:b24018319772 Date: Fri, 01 Jul 2011 11:18:23 +0100 Message-ID: References: <4E0DB760020000780004B949@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4E0DB760020000780004B949@nat28.tlf.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 Cc: Christoph Egger , "xen-devel@lists.xensource.com" , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 01/07/2011 11:02, "Jan Beulich" wrote: >>>> On 30.06.11 at 18:33, Keir Fraser wrote: >> Note that domain_spin_lock_irq_desc() has a retry loop for a reason! It >> knows that pirq-irq mapping may change under its feet, so it needs to >> re-check the mapping with the desc_lock held, at which point the mapping >> cannot change *if* it obtained the correct desc_lock in time! >> >> Perhaps pirq_spin_lock_irq_desc() needs a similar retry loop? Perhaps > > Yes. Will send a patch soon. > >> pirq_spin_lock_irq_desc() should never have been forked from >> domain_spin_lock_irq_desc(), and all callers should simply use the former? > > I'd rather not - the lookup isn't really inexpensive (and doesn't need > to be re-done on each iteration either), which is why I created the > clone in the first place. Instead I think that with adding the retry > loop here, domain_spin_lock_irq_desc() could become a simple > wrapper around pirq_spin_lock_irq_desc(). Yes please! -- Keir > Jan >