revoke-core-code

revoke-core-code

The revokeat(2) and frevoke(2) system calls invalidate open file descriptors
and shared mappings of an inode.  After an successful revocation, operations
on file descriptors fail with the EBADF or ENXIO error code for regular and
device files, respectively.  Attempting to read from or write to a revoked
mapping causes SIGBUS.

The actual operation is done in two passes:

 1. Revoke all file descriptors that point to the given inode. We do
    this under tasklist_lock so that after this pass, we don't need
    to worry about racing with close(2) or dup(2).

 2. Take down shared memory mappings of the inode and close all file
    pointers.

The file descriptors and memory mapping ranges are preserved until the
owning task does close(2) and munmap(2), respectively.

You use revoke() (with chown, for example) to gain exclusive access to
an inode that might be in use by other processes. This means that we must
mke sure that:

  - operations on opened file descriptors pointing to that inode fail
  - there are no shared mappings visible to other processes
  - in-progress system calls are either completed (writes) or abort
    (reads)

After revoke() system call returns, you are guaranteed to have revoked
access to an inode for any processes that had access to it when you
started the operation. The caller is responsible for blocking any future
open(2) calls that might occur while revoke() takes care of fork(2) and
dup(2) during the operation.

[bunk@stusta.de: various cleanups]
[clameter@sgi.com: slab allocators: Remove multiple alignment specifications]
[deweerdt@free.fr: fix use-uninitialised bug]
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>