We use this trick of writing to /proc/<pid>/mem in safety-critical programming to test all the fail cases required to get to 100% code-coverage, tested.
Its quite handy to be able to inject error data directly into a process-under-test and be sure that the exception code actually gets run.
Another thing we do is write to /dev/kmem (or more recently, /dev/kcore), which has to be explicitly enabled, for the purposes of crashing the kernel and ensuring that the system recovers as expected. This particular trick is so interesting to learn, if you're a systems programmer .. with the appropriate System.map, you can steer the kernel around entirely through calculated writes to /dev/kmem, in interesting ways .. find your way to the kernels' jiffies, and see what fun can be had!
Of course, this is all being supplanted by kprobes and eBPF, but back in the day it sure was fun to write tests with the dd tool .. ;)
alt Hacker News
We use this trick of writing to /proc/<pid>/mem in safety-critical programming to test all the fail cases required to get to 100% code-coverage, tested.
Its quite handy to be able to inject error data directly into a process-under-test and be sure that the exception code actually gets run.
Another thing we do is write to /dev/kmem (or more recently, /dev/kcore), which has to be explicitly enabled, for the purposes of crashing the kernel and ensuring that the system recovers as expected. This particular trick is so interesting to learn, if you're a systems programmer .. with the appropriate System.map, you can steer the kernel around entirely through calculated writes to /dev/kmem, in interesting ways .. find your way to the kernels' jiffies, and see what fun can be had!
Of course, this is all being supplanted by kprobes and eBPF, but back in the day it sure was fun to write tests with the dd tool .. ;)