[TUHS] re: Raise of interrupt level necessary

[TUHS] re: Raise of interrupt level necessary

[Wolfgang Helbig]

Dennis, I greatly appreciate your reply. What amazes me most, is the fact
that after 20 odd years you still remember those tricky details:

>For example, the clock interrupt routine can inspect user
>space (for display(), for example, though this is inactive
>on the 11/40), and even change it (for profiling).
>It does appear that other things (checking for
>a direct-from user-mode interrupt) in the clock routine
>already guard against these particular problems.

To see what happens, I just removed those IPL raising instructions from gword,
pword,_savu, _aretu, _copyseg, and _clearseg in m40.s. In fact, it didn't crash
the system. At least on my configuration, ISRs don't touch user space while
interrupting a kernel process. This rule is broken by the clock ISR, which calls
display() unconditionally. Just curious: Is there any other reason beside
seeing blinking lights that justifies calling display() 60 times per second
and breaking the rule?

I also removed IPL protection from the return sequence of the trap routine,
still works. Testing was done on Bob Supnik's SIMH PDP-11 simulator with only
one terminal. By the way, is anyone running V6 on a real PDP-11? Here
is the diff of my modifications to m40.s:

# diff m40.s.6 m40.s
44d43
*       bis     $340,PS
455,456d453
*       mov     PS,-(sp)
*       bis     $340,PS
472,473d468
*       mov     PS,-(sp)
*       bis     $340,PS
480d474
*       mov     (sp)+,PS
485d478
*       mov     (sp)+,PS
539d531
*       bis     $340,PS
548d539
*       bis     $340,PS
594c585
*       mov     $30340,PS
---
.       bis     $30000,PS
621c612
*       mov     $30340,PS
---
.       bis     $30000,PS

Greetings,

Wolfgang Helbig

[TUHS] re: Raise of interrupt level necessary

[Michael Davidson]

Wolfgang Helbig wrote:

>
>To see what happens, I just removed those IPL raising instructions from gword,
>pword,_savu, _aretu, _copyseg, and _clearseg in m40.s. In fact, it didn't crash
>the system. At least on my configuration, ISRs don't touch user space while
>interrupting a kernel process. This rule is broken by the clock ISR, which calls
>display() unconditionally. Just curious: Is there any other reason beside
>seeing blinking lights that justifies calling display() 60 times per second
>and breaking the rule?
>
Well it depends on what you think that the "rule" is ...

If you think that the "rule" is "no ISR can touch user space while
interrupting a kernel process", then it is display() that breaks
the rule.

If, however, the rule is "the user PAR and PDR registers will at
all times reflect the address space mapping of the current user
process" then it is _copyseg and _clearseg that "break" the rule
by "borrowing" some of the user PARs and PDRs, and in that case
it seems appropriate that they should raise the spl level so that
nobody else will be "surprised" by seeing those registers in an
apparently inconsistent state.







 

[TUHS] re: Raise of interrupt level necessary

[Ian King]

Yes, I have v6 running on an 11/34; it's amazing how easy it is to
corrupt the filesystem.  :-)  One of these days, I need to dd another
fresh system disk (RK05) off my "sacred copy" of a PUPS image (tediously
transferred via 9600 baud serial using Warren's excellent vtserver
tools).  In any case, why do you ask?  - Ian 

-----Original Message-----
From: Wolfgang Helbig [mailto:helbig@Informatik.BA-Stuttgart.DE] 
Sent: Saturday, December 14, 2002 12:48 AM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] re: Raise of interrupt level necessary


[snip]

I also removed IPL protection from the return sequence of the trap
routine, still works. Testing was done on Bob Supnik's SIMH PDP-11
simulator with only one terminal. By the way, is anyone running V6 on a
real PDP-11? [snip]

[TUHS] re: Raise of interrupt level necessary

[Wolfgang Helbig]

>Date: Sat, 14 Dec 2002 15:27:40 -0800

Michael Davidson wrote:
>If you think that the "rule" is "no ISR can touch user space while
>interrupting a kernel process", then it is display() that breaks
>the rule.

The point is, that this rule leads to somewhat simpler and therefore
better code -- breaking the rule calls for some justification.
Calling display() from the clock-ISR is the only place where an ISR does
not conform to this rule.


Greetings

Wolfgang Helbig

[TUHS] re: Raise of interrupt level necessary

[Dennis Ritchie]

Wolfgang Helbig wondered,

 > While studying the V6 kernel, I search for some rules as when to raise
 > the interrupt priority level (IPL). I came up with something like this:
 > A kernel process needs to raise the IPL if a change of data must be atomic and might
 > be accessed (not necessarily changed) by an IRS.

 > In light of this rule, some raising of interrupts seem unnecessary:
 > - In m40.s changes of the user space segmentation registers are bracketed by raising
 > and lowering the IPL, although these registers are never accessed by an ISR.

 > - Likewise, in m40.s, just before the trap routine checks the runrun flag and
 > restores r0, r1 and the user stackpointer, it raises the IPL. I can't see what
 > possibly should go wrong, if being interrupted while restoring the values.
 
It's quite possible that the code is unnecessarily cautious.
In general one does not want an interrupt while something
sensitive is in a half-changed state (for example, some of
the addressing registers changed, or a stack half-switched).

For example, the clock interrupt routine can inspect user
space (for display(), for example, though this is inactive
on the 11/40), and even change it (for profiling).
It does appear that other things (checking for
a direct-from user-mode interrupt) in the clock routine
already guard against these particular problems.

It's been a long time since I've looked at this, however.

	Dennis