3

Every resource I read about DPMI and interrupts says that all memory (code/data/stack) that might be used in an interrupt handler should be locked (aka pinned), to make sure it won't be paged out. The idea behind this is that when a page fault occurs in an interrupt handler, you'll get a double fault, and your program will crash.

But is that really so? I imagine a double fault could occur right at the moment when the interrupt occurs, and the CPU tries to jump to your interrupt handler, but the code happens to be paged out. Once your ISR code is already running, I don't see how a page fault could cause disaster. What's so different between the interrupt context and normal program context?

As a quick test, I wrote a simple timer ISR that allocates some memory with char* ptr = new char[1024*1024], and then immediately discards the pointer. Running under CWSDPMI with paging enabled, this does crash after a while, but only because new throws a std::bad_alloc exception. No double faults, as far as I can tell.

Maybe if the interrupt occurs while doing disk I/O (in the middle of int 21), and the page fault handler calls int 21 again, that might cause trouble. But then that doesn't have anything to do with double faults. And then I don't think a protected mode interrupt handler could be called during int 21, anyway.

Is locked memory really that important?

user5434231
  • 579
  • 3
  • 16
  • I am by no means an expert on this, but is it even *possible* to have an interrupt handler paged out? Doesn't the IDT hold *physical* addresses? And... `new`? In an ISR? – DevSolar Feb 27 '16 at 18:59
  • I believe the IDTR does point to the physical location of the IDT, but the IDT itself stores virtual addresses. And yes, you can write ISRs in C++ if you have a wrapper function written in assembly (djgpp provides one in its standard library). – user5434231 Feb 27 '16 at 19:27
  • 2
    I know about the wrapper. But... *why* `new` in an interrupt? You'd want to have it return *as fast as possible*, delegating to a high-level handler. You would *not* want it to page in, allocate, mumblemumble, free... at least, *I* wouldn't... – DevSolar Feb 27 '16 at 20:09
  • I'm just allocating memory in an attempt to trigger a page fault... but nothing disastrous happens, which leaves me wondering if page faults in interrupt context are such a big deal after all. – user5434231 Feb 27 '16 at 20:36
  • 3
    If you know how to make a file system driver work at interrupt time then, no, it isn't necessary. Nobody knows how to do that in Real Life. – Hans Passant Feb 27 '16 at 23:04
  • 1
    I would appreciate it if someone could explain *why* file system access doesn't work during an interrupt. I'm curious. – user5434231 Feb 28 '16 at 10:13

0 Answers0