Date: Thu, 3 Dec 1998 07:30:20 +1100 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: current@FreeBSD.ORG Subject: Re: sio breakage Message-ID: <98Dec3.072944est.40336@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
Bruce Evans <bde@zeta.org.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98Dec3.072944est.40336>