Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 6 Oct 2001 11:24:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 6 Oct 2001 11:24:13 -0400 Received: from geos.coastside.net ([207.213.212.4]:45766 "EHLO geos.coastside.net") by vger.kernel.org with ESMTP id ; Sat, 6 Oct 2001 11:24:09 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1002379256.857.3.camel@thanatos> In-Reply-To: <1002379256.857.3.camel@thanatos> Date: Sat, 6 Oct 2001 08:24:51 -0700 To: Thomas Hood From: Jonathan Lundell Subject: Re: Question about rtc_lock Cc: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At 10:40 AM -0400 2001-10-06, Thomas Hood wrote: >On Sat, 2001-10-06 at 09:13, Alan Cox wrote: >> > No, but what if the rtc interrupts while the lock is held in this >> > bit of code? >> >> Thats fine. It wont take the lock > >But the first line of irq_interrupt() is: > spin_lock (&rtc_lock); > >If one has a multi-processor machine, and CPUx is going through >the bootflag code, which takes the rtc_lock, and that CPU is >interrupted and enters rtc_interrupt(), which tries to take the >rtc_lock, won't it deadlock? > >If not, then I'm missing some clue about how these spinlocks work. rtc_interrupt(), you mean. Even if there weren't current interrupt code doing CMOS accesses, it would seem prudent to assume that there might be eventually, the RTC/NVRAM being a multi-purpose shared resource. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/