From owner-cvs-sys Mon Jul 28 02:23:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA20355 for cvs-sys-outgoing; Mon, 28 Jul 1997 02:23:48 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA20350; Mon, 28 Jul 1997 02:23:33 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA10322; Mon, 28 Jul 1997 19:19:18 +1000 Date: Mon, 28 Jul 1997 19:19:18 +1000 From: Bruce Evans Message-Id: <199707280919.TAA10322@godzilla.zeta.org.au> To: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/isa isa.c Sender: owner-cvs-sys@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >msmith 1997/07/28 00:49:41 PDT > > Modified files: > sys/i386/isa isa.c > Log: > Use disable_intr() / read/write_eflags() to ensure that interrupt > handlers don't skew the results of isa_dmastatus. The function can be > safely called with interrupts disabled. > > Submitted by: Stephen McKay Erm, it already used splhigh() to ensure this. Rule 1: No function can be called safely with CPU interrupts disabled. (A few are called, with various amounts of unsafety. E.g., mcount is called from interrupt handler entry points. This is necessary for accurate profiling, but takes too long on slow machines.) splhigh() wouldn't be enough if isa_dmastatus() were called from a fast interrupt handler, but this shouldn't happen - see rule 1 :-). It would be particularly unsafe to call it, since the fast interrupt might be interrupting isa_dmastart() or other programming of the DMA registers that should be atomic. isa_dmastart() doesn't even use splhigh(). This seems to be more broken than I thought :-(. Concurrent calls from interrupt handlers can happen because interrupt handlers that used DMA don't all run at the same ipl. Only ipl = splhigh() would be common, and that would be too high. Bruce