From owner-freebsd-current Wed Dec 2 12:30:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01018 for freebsd-current-outgoing; Wed, 2 Dec 1998 12:30:48 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01006 for ; Wed, 2 Dec 1998 12:30:43 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40336>; Thu, 3 Dec 1998 07:29:44 +1100 Date: Thu, 3 Dec 1998 07:30:20 +1100 From: Peter Jeremy Subject: Re: sio breakage To: current@FreeBSD.ORG Message-Id: <98Dec3.072944est.40336@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: >>I'd suggest sending SIGBUS, with the interrupts enabled. This would >>allow the application to recover if necessary. > >Recovery may be impossible, since timing for the critical region may >have been violated I should have said `if possible', rather than `if necessary'. In fact if the process was in the middle of fiddling with the hardware, the entire machine might be effectively hosed (eg, if XFree86 gets interrupted half-way through re-configuring the video card). >>I don't believe this is reasonable. We should provide some safe way >>for an application program to execute code with interrupts disabled. > >I gave a way: only access a single page (including for code). Having code and data on the same page is not particularly clean. (And having write permission to an executable memory block is a security hole). >Oops, this is not enough. The "cli" might work because it is cached I don't believe that the cache can contain data for a non-resident page. At least on the ix86, it's a physical-address cache, so the cache must (of necessity) be flushed if the page is reused. >But the application has no way of knowning if the memory is resident. man 2 mincore For most purposes (excluding systems thrashing), referencing all the affected pages before the CLI will be sufficient to ensure they are resident. >>The guaranteed approach is to use mlock(2) on the affected regions. >>This is also the most expensive (since multiple system calls are >>required). Whilst this only works for root, only root can normally >>open /dev/io (and hence use CLI/STI). > >It is cheap enough in time if the memory is kept locked, If you need to atomically execute a small number of instructions, the added overhead of 1 or 2 mlock/munlock pairs is relatively huge. Also, if we're just talking about initialisation code, having it locked in memory is wasteful. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message