Handling of revoke() with mapped memory

Posted Jul 13, 2013 1:40 UTC (Sat) by vomlehn (guest, #45588)
Parent article: Retrying revoke()

...a better solution might be to just cause all accesses to return 0xff...

No, please, no! Solutions which return some value or which allow reuse of the process' virtual address space without notification are going to cause the process to use bad data without any way to know this has happened. Huge possibilities for *bad* things to happen.

Signals may be the best way to handle this because they, at least, guarantee that naive programs, i.e. those that are not programmed to handle revocation of a file descriptor, will quickly draw attention to themselves as requiring a fix.

One other possibility would be to disallow revoke() if the device is mapped unless the process has indicated it can handle it via some other system call (revoke_ok(), perhaps). Then it can chose to handle it with a signal, by getting some magic value from memory, or something else entirely. This may the the most backward compatible approach.