Date: Fri, 25 Dec 1998 22:17:50 +1100 From: Bruce Evans <bde@zeta.org.au> To: jdp@polstra.com, mike@smith.net.au Cc: current@FreeBSD.ORG Subject: Re: trap 12 with interrupts disabled Message-ID: <199812251117.WAA31256@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > If my page fault fails because I've blocked the interrupt, I'd expect >> > some serious damage to happen to the process environment.n >> >> Usually you're lucky and something else turns them on unconditionally. >> This test simply makes damn sure that if you take a fault interrupts >> get turned back on. > >I'm still not entirely clear about the implications of this change. >If I understand it right, the message is caused by a bug in Xaccel. Right. >.. >Do the interrupts get turned back off again when control returns to >Xaccel, or do they remain on? If Xaccel is assuming they're off, it >seems bad to turn them on underfoot. They get turned back off, but this might not help because control might not be returned to for Xaccel a long time. E.g., the kernel might decide to run 10 other processes for 100 msec each before returning to Xaccel. This might break whatever timing requirements Xaccel is attempting to meet by turning off interrupts. Before the change, the following could happen: 1) Benign case: the pagefault handler finds the page in the cache and completes fairly fast (< about 100 usec). 2) The pagefault handler runs for a long time without blocking. This causes slow response to interrupts. "A long time" can apparently be several 10's of msec so that clock interrupts are lost. I don't know how it can be so long (perhaps it is all in the application). 3) The pagefault handler blocks. Then interrupts are turned on underfoot when another process or idle() is run. Interrupts are "known" to be on already, and their state is "restored" to on when the blocked process is restarted in the kernel. They get turned back off when the process leaves the kernel. 4) The pagefault handler happens to calls something that "knows" that interrupts are on and "restores" their state to on after turning them off. This is essentially the same as the current behaviour. I'm not sure if it actually occurred. 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?199812251117.WAA31256>