Code and data pages are mapped from the executable. Code is read-only
and can therefore be discarded at any time, since it exists on disk (in
the executable file, no swap needed). Data is mapped copy-on-write
(read-only pages until writes occur, then a writable copy is generated).
So only modified data pages and new mappings not backed by a disk file
need to be saved in swap space.
> Well... I don't think this will have much impact in my module because what it
> does is:
>
> - change the code in a process
> - return to the process
> - next time the process is scheduled, the code will be stored again in the CS
I'm not sure why you would want to actually _change_ code. You could
prepare a page in kernel with the busy loop and map that into user
space.
Then make the kernel return to your busy loop and let it call back to
the kernel again when finished, then remove the mapping to leave no
traces. Maybe that could be done by redirecting a signal handler
pointer and raising that signal.
I don't know how difficult that is, it's just an idea. But it sure
sounds easier than modifying a read-only page without side effects.
-- Andreas Bombe <bombe@informatik.tu-muenchen.de> DSA key 0x04880A44 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/