Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Dec 1998 23:07:00 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        current@FreeBSD.ORG, peter.jeremy@auss2.alcatel.com.au
Subject:   Re: sio breakage
Message-ID:  <199812021207.XAA05665@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>>something_more_likely()
>>{
>>	asm("cli");
>>	var = 0;
>>	asm("sti");
>>}
>
>>Fixes:
>>kernel: send a fatal signal to applications that do this.
>
>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 by a few usec for taking the trap, and when interrupts
are enabled, interrupt processing may violate the timing by another N
msec, not to mention that a clock interrupt may trigger rescheduling of
the process so that it is not run for another M scheduling quanta.

My current fix just enables interrupts and prints an error message at the
start of trap().  I've noticed traps with interrupts disabled for:

	asm("cli");
	asm("sti");		/* trace trap here for single stepping */

and

	char *p = malloc(0x1000);
	asm("cli");
	p[0] = 0;		/* pagefault here for normal operation */
	asm("sti");

>>applications: don't do this.
>
>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).  The
page must be mapped in for execution of the "cli" in it to work.
Oops, this is not enough.  The "cli" might work because it is cached
(pipelines probably aren't a problem because they will probably never
cross page boundaries).

>>  If interrupts must be disabled, then all
>>              critical code and data must be within one page.
>
>The restriction is slightly more liberal than this: all code in the
>flow of control between the CLI and STI (inclusive), together with all
>data referenced by such code must be resident at the time the CLI is
>executed.

But the application has no way of knowning if the memory is resident.
I forgot about caches when I suggested putting everything on one pages
as a way of knowing that at least that page is 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, and cheapest
in space if everything is on one page :-).

Bruce

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?199812021207.XAA05665>