From owner-freebsd-arch Sun Mar 18 21:57:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B507A37B718; Sun, 18 Mar 2001 21:57:51 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2J5vmZ04161; Sun, 18 Mar 2001 21:57:48 -0800 (PST) (envelope-from dillon) Date: Sun, 18 Mar 2001 21:57:48 -0800 (PST) From: Matt Dillon Message-Id: <200103190557.f2J5vmZ04161@earth.backplane.com> To: Bruce Evans Cc: John Baldwin , Matthew Jacob , arch@FreeBSD.ORG Subject: Re: 'final' man pages References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> will DTRT and not enable interrupts until after the second restore_intr(). :> You do have to pair them up much like lock acquire/releases. : :The problem is if interrupts are controlled by masks. A lower priority :interrupt may occur while the above code is running (unless you dumb down :the masks a little to give levels). The handler for this interrupt must :keep it disabled and not proceed far before continuing with the above :code (since the above code has higher priority). This invalidates x and :y if x and y contain the mask. If the masking is effectively per-cpu, this isn't actually a problem. The spl*() calls had the same issue. All that happens is that the lower priority interrupt gets in, masks interrupts, then restores them prior to returning. So from the point of view of the code being interrupted the mask hasn't changed at all. However, if multiple cpu's are allowed to make these calls and the masking involves shared state, you would have a problem with the cpu's tripping over each others masks. Insofar as this thread is concerned it isn't an issue that we have to worry about. For the same reason, the per-cpu interrupt nesting count and related tests do not require any special locking even if they gets interrupted, because the state is restored prior to the interrupt returning (no matter how many interrupts occur or how deeply nested the code gets). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message