From: Pekka Enberg <penberg@cs.helsinki.fi>
The revokeat(2) system call ensures that after successful revocation you can

only access an inode via a file descriptor that is obtained from a subsequent

open(2) call.  The open(2) system call can be blocked by the caller with

chmod(2) and chown(2) prior to calling revokeat(2) to gain exclusive access to

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

revokeat(2) system call guarantees that:
  (1) open file descriptors are revoked,
  (2) file descriptors created by fork(2) and dup(2) during

      the operation are revoked,
  (3) file descriptors obtained via a SCM_RIGHTS datagram during or

      after the revoke operation are revoked,
  (4) in-flight read(2) and write(2) operations are either completed

      or aborted before revokeat(2) returns successfully,
  (5) attempting to read from or write to a shared memory mapping

      raises SIGBUS, and
  (6) copy-on-write to a private memory mapping after successful

      revokeat(2) call does not reveal any data written after the

      system call has returned.
TODO:
  - I/O requests that are in-flight

  - Breaking of private mapping COW races with fork
Cc: Alan Cox <alan@redhat.com>

Cc: Al Viro <viro@zeniv.linux.org.uk>

Cc: Christoph Hellwig <hch@infradead.org>

Cc: Peter Zijlstra <peterz@infradead.org>

Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>

---

 fs/revoke.c           |  450 ++++++++++++++++++++++++++++++++++++++++++++++++++

 include/linux/fs.h    |   10 +

 include/linux/magic.h |    2

 include/linux/mm.h    |    1

 mm/mmap.c             |   11 +

 5 files changed, 473 insertions(+), 1 deletion(-)
Index: 2.6/fs/revoke.c

===================================================================

--- /dev/null	1970-01-01 00:00:00.000000000 ...
[ message continues ]

Skip everything that has reassigned ->f_op in open()?  That includes all
*Um*
Where exactly do we terminate operations in progress and how the devil is

locking supposed to be done in driver?

--

Humm, we were trying to get rid of file_list_lock(), this puts up

another user of the sb file list.
Also, that loop looks horribly expensive: n*(1+m); where n is the list

size, and m the number of matching fds.
Granted, I see no other options either.
-

Something like the loop above is not going to go in for sure.  Once we

get rid of the sb->s_files we can put the list_head in struct file to

new use eventually if we don't want to get rid of it.  E.g. and

per-inode list would be much better than the per-superblock one and

would regularize what the tty driver is doing.
But I'm not too interesting in hashing out these details currently,

my primary concern is to get the per-mount r/o plus fallout like the

correct remount r/o and file_list_lock removal in and stable first.
-

Hi,
Sure, adding a list of struct files to struct inode obviously works for

me. But it does increase the size of struct inode which I thought you're

not allowed to do ;-)
Anyway, there are still some other problems with this patch if we want to

use it to implement forced unmount (my bad, we can't go changing struct

inode because it's shared by different mount points).
			Pekka

-