whm@arizona.UUCP (Bill Mitchell) (02/02/85)
I have a question about how the Unix kernel manages stack space. Suppose
one has a process that grabs a couple of hundred kbytes of stack space for
use in a subroutine. Obviously, while this space lies between the stack
pointer and the end of the stack, the pages in the region are part of
the address space of the process. My question is: If the process returns
from the subroutine, are those stack pages used by the subroutine still
in the process's address space?
It would seem like a reasonable thing for the system to not consider the
pages to be in the process's address space, i.e., consider the stack page
into which the sp points to be the lowest stack page in the process's
address space. (Note that a down-growing stack is assumed for purposes
of discussion.) On 4.2 on Suns and Vaxs, the system does allow (based
on empirical studies rather than code examination) access to pages below
the sp as long as they were properly contained in the stack at some point
in time. Is this implementation dependent or is this some sort of standard
Unix "feature"?
Thanks in advance,
Bill Mitchell
whm.arizona@csnet-relay
{ihnp4,noao,mcnc,utah-cs}!arizona!whmrobert@cheviot.UUCP (Robert Stroud) (02/05/85)
In article <21131@arizona.UUCP> whm@arizona.UUCP (Bill Mitchell) asks whether stack pages grabbed while the stack is deep are ever reclaimed by the system when the stack recedes. > On 4.2 on Suns and Vaxes, the system does allow (based >on empirical studies rather than code examination) access to pages below >the sp as long as they were properly contained in the stack at some point >in time. Is this implementation dependent or is this some sort of standard >Unix "feature"? > > Thanks in advance, > Bill Mitchell > whm.arizona@csnet-relay > {ihnp4,noao,mcnc,utah-cs}!arizona!whm I don't know about more recent versions of Unix, but this was a "feature" of the PDP-11 V7 implementation where I first met Unix. I used it to extend my data area beyond 56K without fear of a segmentation violation. The memory mapping hardware on this PDP-11 restricted you to 8 segments, each of which could address up to 8K in steps of 64 bytes - or something like that. Because Unix must always have a stack segment, you couldn't extend your memory (using sbrk) beyond 56K (or 8 - 1 segments). However, if you extended the stack segment to its full 8K by setting, de-referencing and then re-setting the stack pointer, and set your break to 56K, then the full 64K address space was addressable without any danger of segmentation violation, and you could sneak a few extra bytes into the bottom of the stack segment from the top of the data segment. The danger with this is that you lose the memory protection facilities and stack overflow checks, but as far as I could tell, the memory was never reclaimed. Obviously, a more modern Unix uses much more sophisticated memory management hardware, so this part of the kernel code has probably been completely rewritten. On the other hand, if it was in V7.... I wasn't particularly proud of this trick, but it got me out of a hole. If anyone else out there is still using PDP-11's(!), they may find it useful. Robert Stroud, Computing Laboratory, University of Newcastle upon Tyne. ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa UUCP ...!ukc!cheviot!robert "Unix is what runs on Dennis Ritchie's machine!"
rhesmith@wlcrjs.UUCP (Richard H. E. Smith II) (02/08/85)
This is a little bit of obscure history of interest to pdp-11 users, and slightly aged unix hackers. You can skip out now if this isn't your sort of thing. Otherwise, please bear with the long quotes: >>In article <21131@arizona.UUCP> whm@arizona.UUCP (Bill Mitchell) asks: >>whether stack pages grabbed while the stack is deep are ever reclaimed >>by the system when the stack recedes. >> >> On 4.2 on Suns and Vaxes, the system does allow (based >>on empirical studies rather than code examination) access to pages below >>the sp as long as they were properly contained in the stack at some point >>in time. Is this implementation dependent or is this some sort of standard >>Unix "feature"? >In article <248@cheviot.UUCP> robert@cheviot.UUCP (Robert Stroud) writes: >I don't know about more recent versions of Unix, but this was a "feature" >of the PDP-11 V7 implementation where I first met Unix. I used it to extend >my data area beyond 56K without fear of a segmentation violation. > >The memory mapping hardware on this PDP-11 restricted you to 8 segments, each >of which could address up to 8K in steps of 64 bytes - or something like that. >Because Unix must always have a stack segment, you couldn't extend your memory >(using sbrk) beyond 56K (or 8 - 1 segments). > >However, if you extended the stack segment to its full 8K by setting, >de-referencing and then re-setting the stack pointer, and set your break >to 56K, then the full 64K address space was addressable without any >danger of segmentation violation, and you could sneak a few extra bytes... > >I wasn't particularly proud of this trick, but it got me out of a hole. >If anyone else out there is still using PDP-11's(!), they may find it useful. If the pdp-11 wasn't being used in its "separate instruction and data space" mode, you could do something even stranger... you could hang it up completely. I did this to UNIX[tm] V6 back at the University of Wisconsin, in '74 or '75. The pdp-11/45 has a privileged instruction SPL, which was a NOP in user state except that it would hold interupts for one instruction (oops! a microcode bug!). By carefully allocating data and stack, one could fill the entire 32Kword address space with SPL instructions, and lock up the cpu completely. All of address space except one NOP would really annoy the other users, but did (eventually) allow interrupts. Either looked nice in the lights, too. I don't believe that the 11/70 cpu or later cpus have this microcode bug. I don't advise you to test it... you must reset from the front panel after the crash... altho a really skilled sysadm can spot this loop, and patch it out of existance from the switches... somehow, I imagine that anyone still running an 11 has such. (No, I'm not picking on you. I write 11 software for a living.) To do the trick, I believe that some strange balance of allocating stack and brk() memory had to be used, because the kernel allocated stack to the program in some multiple of 3(?) 32word hunks. Now, who remembers the one-instruction core clear? -- ---------- Dick Smith ..ihnp4!wlcrjs!rhesmith