lkml.org 
[lkml]   [2007]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/5] revoke: core code
On Fri, 16 Mar 2007, Andrew Morton wrote:
> I assume that any future callers to sys_read() will reliably do the right
> thing at this stage, so we are concerned with threads which are presently
> partway through a read from this inode?

Yes. We first revoke the file descriptors under tasklist_lock after which
any new operations on the revoked inode descriptors fail.

On Fri, 16 Mar 2007, Andrew Morton wrote:
> If it _is_ accurate then hm, tricky. It all rather depends upon how the
> relevant filesystem implements reading (and writing?). Which is why you
> made it a file_operation, fair enough.

Yeah, filesystem dependent. Writes are not a problem as do_sync() will
wait until the writers are done. For that part, generic_file_revoke()
should be fine although suboptimal for most filesystems.

On Fri, 16 Mar 2007, Andrew Morton wrote:
> But even for ext2 and ext3 (please keep ext4 in sync with ext3 changes,
> btw), if some process is partway through a big page_cache_readahead()
> operation then a concurrent invalidate_inode_pages2() call won't worry it
> at all: the pagecache will be reinstantiated and do_generic_mapping_read()
> will proceed to copy that pagecache out to the user after the revoke() has
> returned. I think.

That's bad. Can we perhaps wait until readers are done?

On Fri, 16 Mar 2007, Andrew Morton wrote:
> I'm afraid I havent paid any attention to this revoke proposal before, I
> don't understand the usecases nor the implementation details so things
> which are implicitly-obvious-to-you must be explained to me. But others
> will benefit from that explanation too ;) What, exactly, are we trying to do
> with the already-opened files and the currently-in-progress syscalls?

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.

On Fri, 16 Mar 2007, Andrew Morton wrote:
> (A concurrent direct-io read might be a problem too?)

Good point. We would need to take down those too.

Pekka
-
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/

\
 
 \ /
  Last update: 2007-03-16 12:47    [W:0.069 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site