On Mon, 8 Feb 2021 17:02:01 +0000, Farley, Peter x23353 <peter.far...@broadridge.com> wrote:
>Obvious application-level solution: Make sure your program occupies whole >pages by adding adjusted DC XLnnnn at the end to get to a 4096-byte boundary. > Length is limited to 256. With hardware generations, pages get larger >-----Original Message----- >From: On Behalf Of Charles Mills >Sent: Monday, February 8, 2021 11:57 AM > >Storage protection is page by page. So ... design tradeoff decision: > >- Leave any part of the program that occupies a partial page unprotected. >- "Waste" the remainder of the partially-occupied page. > >IBM obviously chose the former. > Half-assed implementation. And Key 0 exemption? But some kernel code is historically or necessarily self-modifying. A co-worker once (successfully) claimed an exemption from our REFR coding standard, arguing (accurately) that his code never ran in a multi-threaded context. But ObEmerson. What is the performance tradeoff between voiding the I-Cache and GETMAIN/FREEMAIN for subroutine ENTRY/RETURN? >________________________________________ >-----Original Message----- >From: Seymour J Metz >Sent: Monday, February 8, 2021 8:51 AM > >> Therefore, any parts of the program that are on partial pages are not >page-protected. > >Ouch! Why? > >________________________________________ >From Peter Relson [rel...@us.ibm.com] >Sent: Monday, February 8, 2021 9:13 AM > ><snip> >The effect of REFRPROT has long been enforced for modules loaded from APF >libraries. ></snip> > >Only for non-key-0 programs. Putting code into key 0 storage is not all that >REFRPROT does. > ><snip> >Does REFRPROT have a "warn" setting? ></snip> >No. What would it warn about? That you loaded a refreshable program? You can't >know it won't work until it doesn't work. It is easy enough to scan your >libraries for things that are marked refreshable. > Harder to detect self-modification. ></snip> >But now there is an intrinsic penalty from mixing I-cache and D-cache but >presumably not enough to merit changing. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
