On Fri, 16 Mar 2007 22:37:57 +0200 "Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> What we could do is add a "I am revoked" flag to struct file which
> blocks any future ->readpage, ->readpages, and ->direct_IO on the
> file. Alternatively, we could change the ->f_mapping to point to an
> address
On 3/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
However, modifying i_size like this might be a problem - the inode could be
dirty and it'll get written to disk! Perhaps we could change i_size_read()
to cheat and to return zero if there's a revoke in progress.
I don't think we can
On 3/16/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> Serious question - do we actually need revoke() on a normal file ? BSD
> has never had this, SYS5 has never had this.
On 3/16/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
It's needed for forced unmount (bits of it anyway) and
partial-revocation
On Fri, 16 Mar 2007, Andrew Morton wrote:
> What you're trying to do here is very similar to truncate(), and truncate()
> has had a lot of work put into it, and it does work.
Indeed. revoke() is the same as truncate() without, well, the truncation
part.
On Fri, 16 Mar 2007, Andrew Morton wrote:
On 3/16/07, Alan Cox <[EMAIL PROTECTED]> wrote:
Serious question - do we actually need revoke() on a normal file ? BSD
has never had this, SYS5 has never had this.
It's needed for forced unmount (bits of it anyway) and
partial-revocation in SLIM.
-
To unsubscribe from this list: send the line
On 3/16/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> I'm not sure that running do_fsync() will guarantee that all sys_write()
> callers will have finished their syscall. Probably they will have, in
> practice. But there is logic in the sync paths to deliberately bale out
> if we're competing with
> I'm not sure that running do_fsync() will guarantee that all sys_write()
> callers will have finished their syscall. Probably they will have, in
> practice. But there is logic in the sync paths to deliberately bale out
> if we're competing with ongoing dirtyings, to avoid livelocking.
For
On Fri, 16 Mar 2007 13:44:27 +0200 (EET) Pekka J Enberg <[EMAIL PROTECTED]>
wrote:
> 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
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
On Fri, 16 Mar 2007 08:44:46 +0200 "Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> On 3/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Why is this code using invalidate_inode_pages2()? That function keeps on
> > breaking, has ill-defined semantics and will probably change in the future.
> >
> >
On Fri, 16 Mar 2007 08:44:46 +0200 Pekka Enberg [EMAIL PROTECTED] wrote:
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
Why is this code using invalidate_inode_pages2()? That function keeps on
breaking, has ill-defined semantics and will probably change in the future.
Exactly what
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
On Fri, 16 Mar 2007 13:44:27 +0200 (EET) Pekka J Enberg [EMAIL PROTECTED]
wrote:
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
I'm not sure that running do_fsync() will guarantee that all sys_write()
callers will have finished their syscall. Probably they will have, in
practice. But there is logic in the sync paths to deliberately bale out
if we're competing with ongoing dirtyings, to avoid livelocking.
For device
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote:
Serious question - do we actually need revoke() on a normal file ? BSD
has never had this, SYS5 has never had this.
It's needed for forced unmount (bits of it anyway) and
partial-revocation in SLIM.
-
To unsubscribe from this list: send the line
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote:
I'm not sure that running do_fsync() will guarantee that all sys_write()
callers will have finished their syscall. Probably they will have, in
practice. But there is logic in the sync paths to deliberately bale out
if we're competing with
On Fri, 16 Mar 2007, Andrew Morton wrote:
What you're trying to do here is very similar to truncate(), and truncate()
has had a lot of work put into it, and it does work.
Indeed. revoke() is the same as truncate() without, well, the truncation
part.
On Fri, 16 Mar 2007, Andrew Morton wrote:
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote:
Serious question - do we actually need revoke() on a normal file ? BSD
has never had this, SYS5 has never had this.
On 3/16/07, Pekka Enberg [EMAIL PROTECTED] wrote:
It's needed for forced unmount (bits of it anyway) and
partial-revocation in
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
However, modifying i_size like this might be a problem - the inode could be
dirty and it'll get written to disk! Perhaps we could change i_size_read()
to cheat and to return zero if there's a revoke in progress.
I don't think we can actually
On Fri, 16 Mar 2007 22:37:57 +0200 Pekka Enberg [EMAIL PROTECTED] wrote:
What we could do is add a I am revoked flag to struct file which
blocks any future -readpage, -readpages, and -direct_IO on the
file. Alternatively, we could change the -f_mapping to point to an
address space that has
Hi Andrew,
On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg
<[EMAIL PROTECTED]> wrote:
On 3/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
n all system calls must return long.
Fixed.
On 3/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
so the modification of vm_flags
On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg <[EMAIL PROTECTED]>
wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> 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
On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg [EMAIL PROTECTED]
wrote:
From: Pekka Enberg [EMAIL PROTECTED]
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
Hi Andrew,
On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg
[EMAIL PROTECTED] wrote:
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
n all system calls must return long.
Fixed.
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
so the modification of vm_flags is
From: Pekka Enberg <[EMAIL PROTECTED]>
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.
From: Pekka Enberg [EMAIL PROTECTED]
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.
26 matches
Mail list logo
