Hi Daniel
Okay let me rephrase my question:
1) I read that an ISR cannot cause a page fault. Is the statement true?
What ISR can not cause is actually a blocking situation. Since page
fault could actually lead a kernel code path to be suspended and allow
scheduler to activate another process (thus another kernel code path
takes place), that's why ISR cannot cause page fault because by design
the developer knows it will cause blocking state.
To tackle this situation, whenever you want to allocate and then use a
memory block, either you use atomic allocation via kmalloc or prepare a
memory pool first. That way, the pages are ready when you need them.
2) In the case it is true, how are situations like this handled : an
ISR tries to use a data item that has been swapped out?
That won't happen, unless the developer makes a mistake of course. But
as long as it is accessing kernel mode pages, it is safe since it won't
get swapped out.
3) I have the following argument that convinces me that the statement
is false. When an ISR causes a page fault, the page fault handler is
invoked since its priority is higher. When it finishes the control
goes back to ISR, just like the normal case of nested ISR execution.
Hence an ISR can cause page fault. Is any thing wrong with this
argument?
read my above explanation and I am sure you'll get it.
regards,
Mulyadi
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
