> Miklos Szeredi wrote:
> This still does not address the situation where a file is 'permanently'
> mmap'd, does it?
>
> >>> So? If application doesn't do msync, then the file times won't be
> >>> updated. That's allowed by the standard, and so portable applications
> >>>
Miklos Szeredi wrote:
This still does not address the situation where a file is 'permanently'
mmap'd, does it?
So? If application doesn't do msync, then the file times won't be
updated. That's allowed by the standard, and so portable applications
will have to call msync.
It
> > > This still does not address the situation where a file is 'permanently'
> > > mmap'd, does it?
> >
> > So? If application doesn't do msync, then the file times won't be
> > updated. That's allowed by the standard, and so portable applications
> > will have to call msync.
>
> It is
On Thu, 2007-02-22 at 21:48 +0100, Miklos Szeredi wrote:
> > This still does not address the situation where a file is 'permanently'
> > mmap'd, does it?
>
> So? If application doesn't do msync, then the file times won't be
> updated. That's allowed by the standard, and so portable applications
Miklos Szeredi wrote:
__fput() will be called when there are no more references to 'file',
then it will update the time if the flag is set. This applies to
regular files as well as devices.
I suspect that you will find that, for a block device, the wrong inode
gets updated. That's
Miklos Szeredi wrote:
Take this example:
fd = open()
addr = mmap(.., fd)
write(fd, ...)
close(fd)
sleep(100)
msync(addr,...)
munmap(addr)
The file times will be updated in write(), but with your patch, the
bit in the mapping will also be set.
Then in msync() the
> > __fput() will be called when there are no more references to 'file',
> > then it will update the time if the flag is set. This applies to
> > regular files as well as devices.
> >
> >
>
> I suspect that you will find that, for a block device, the wrong inode
> gets updated. That's where
> > Take this example:
> >
> > fd = open()
> > addr = mmap(.., fd)
> > write(fd, ...)
> > close(fd)
> > sleep(100)
> > msync(addr,...)
> > munmap(addr)
> >
> > The file times will be updated in write(), but with your patch, the
> > bit in the mapping will also be set.
>
Miklos Szeredi wrote:
Why is the flag checked in __fput()?
It's because of this bit in the standard:
If there is no such call and if the underlying file is modified
as a result of a write reference, then these fields shall be
marked for update at some time after the
Miklos Szeredi wrote:
+int set_page_dirty_mapping(struct page *page);
This aspect of the design seems intrusive to me. I didn't see a strong
reason to introduce new versions of many of the routines just to handle
these semantics. What motivated this part of
> > +int set_page_dirty_mapping(struct page *page);
> >
> >
> >
> This aspect of the design seems intrusive to me. I didn't see a strong
> reason to introduce new versions of many of the routines just to handle
> these semantics. What motivated
> >> Why is the flag checked in __fput()?
> >>
> >
> > It's because of this bit in the standard:
> >
> > If there is no such call and if the underlying file is modified
> > as a result of a write reference, then these fields shall be
> > marked for update at some time after the
Miklos Szeredi wrote:
Inspired by Peter Staubach's patch and the resulting comments.
An updated version of the original patch was submitted to LKML
yesterday... :-)
Strange coincidence :)
file = vma->vm_file;
Miklos Szeredi wrote:
On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and
Miklos Szeredi wrote:
On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote:
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and
Miklos Szeredi wrote:
Inspired by Peter Staubach's patch and the resulting comments.
An updated version of the original patch was submitted to LKML
yesterday... :-)
Strange coincidence :)
file = vma-vm_file;
start
Why is the flag checked in __fput()?
It's because of this bit in the standard:
If there is no such call and if the underlying file is modified
as a result of a write reference, then these fields shall be
marked for update at some time after the write reference.
+int set_page_dirty_mapping(struct page *page);
This aspect of the design seems intrusive to me. I didn't see a strong
reason to introduce new versions of many of the routines just to handle
these semantics. What motivated this part of your design? Why the new
Miklos Szeredi wrote:
+int set_page_dirty_mapping(struct page *page);
This aspect of the design seems intrusive to me. I didn't see a strong
reason to introduce new versions of many of the routines just to handle
these semantics. What motivated this part of
Miklos Szeredi wrote:
Why is the flag checked in __fput()?
It's because of this bit in the standard:
If there is no such call and if the underlying file is modified
as a result of a write reference, then these fields shall be
marked for update at some time after the
Take this example:
fd = open()
addr = mmap(.., fd)
write(fd, ...)
close(fd)
sleep(100)
msync(addr,...)
munmap(addr)
The file times will be updated in write(), but with your patch, the
bit in the mapping will also be set.
Then in msync() the
__fput() will be called when there are no more references to 'file',
then it will update the time if the flag is set. This applies to
regular files as well as devices.
I suspect that you will find that, for a block device, the wrong inode
gets updated. That's where the
Miklos Szeredi wrote:
Take this example:
fd = open()
addr = mmap(.., fd)
write(fd, ...)
close(fd)
sleep(100)
msync(addr,...)
munmap(addr)
The file times will be updated in write(), but with your patch, the
bit in the mapping will also be set.
Then in msync() the
Miklos Szeredi wrote:
__fput() will be called when there are no more references to 'file',
then it will update the time if the flag is set. This applies to
regular files as well as devices.
I suspect that you will find that, for a block device, the wrong inode
gets updated. That's
On Thu, 2007-02-22 at 21:48 +0100, Miklos Szeredi wrote:
This still does not address the situation where a file is 'permanently'
mmap'd, does it?
So? If application doesn't do msync, then the file times won't be
updated. That's allowed by the standard, and so portable applications
will
This still does not address the situation where a file is 'permanently'
mmap'd, does it?
So? If application doesn't do msync, then the file times won't be
updated. That's allowed by the standard, and so portable applications
will have to call msync.
It is allowed, but it is
Miklos Szeredi wrote:
This still does not address the situation where a file is 'permanently'
mmap'd, does it?
So? If application doesn't do msync, then the file times won't be
updated. That's allowed by the standard, and so portable applications
will have to call msync.
It
Miklos Szeredi wrote:
This still does not address the situation where a file is 'permanently'
mmap'd, does it?
So? If application doesn't do msync, then the file times won't be
updated. That's allowed by the standard, and so portable applications
will have to call msync.
> On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > This patch makes writing to shared memory mappings update st_ctime and
> > st_mtime as defined by SUSv3:
> >
> >The st_ctime and st_mtime fields of a file that is mapped with
> >MAP_SHARED and PROT_WRITE
On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> This patch makes writing to shared memory mappings update st_ctime and
> st_mtime as defined by SUSv3:
>
>The st_ctime and st_mtime fields of a file that is mapped with
>MAP_SHARED and PROT_WRITE shall be
> >>> Inspired by Peter Staubach's patch and the resulting comments.
> >>>
> >>>
> >>>
> >> An updated version of the original patch was submitted to LKML
> >> yesterday... :-)
> >>
> >
> > Strange coincidence :)
> >
> >
> >>> file = vma->vm_file;
> >>> start
Miklos Szeredi wrote:
Inspired by Peter Staubach's patch and the resulting comments.
An updated version of the original patch was submitted to LKML
yesterday... :-)
Strange coincidence :)
file = vma->vm_file;
start = vma->vm_end;
+
> > > > This flag is checked in msync() and __fput(), and if set, the file
> > > > times are updated and the flag is cleared
> > >
> > > Why not also check inside vfs_getattr?
> >
> > This is the minimum, that the standard asks for.
> >
> > Note, your porposal would touch the times in
Trond Myklebust wrote:
On Wed, 2007-02-21 at 19:28 +0100, Miklos Szeredi wrote:
This flag is checked in msync() and __fput(), and if set, the file
times are updated and the flag is cleared
Why not also check inside vfs_getattr?
This is the minimum, that the standard asks
On Wed, 2007-02-21 at 19:28 +0100, Miklos Szeredi wrote:
> > > This flag is checked in msync() and __fput(), and if set, the file
> > > times are updated and the flag is cleared
> >
> > Why not also check inside vfs_getattr?
>
> This is the minimum, that the standard asks for.
>
> Note, your
> > This flag is checked in msync() and __fput(), and if set, the file
> > times are updated and the flag is cleared
>
> Why not also check inside vfs_getattr?
This is the minimum, that the standard asks for.
Note, your porposal would touch the times in vfs_getattr(), which
means, that the
> > Inspired by Peter Staubach's patch and the resulting comments.
> >
> >
>
> An updated version of the original patch was submitted to LKML
> yesterday... :-)
Strange coincidence :)
> > file = vma->vm_file;
> > start = vma->vm_end;
> > +
On Wed, 2007-02-21 at 18:51 +0100, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> This patch makes writing to shared memory mappings update st_ctime and
> st_mtime as defined by SUSv3:
>
>The st_ctime and st_mtime fields of a file that is mapped with
>MAP_SHARED and
Miklos Szeredi wrote:
From: Miklos Szeredi <[EMAIL PROTECTED]>
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and PROT_WRITE shall be marked for update at some
From: Miklos Szeredi <[EMAIL PROTECTED]>
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and PROT_WRITE shall be marked for update at some point
in the interval
From: Miklos Szeredi [EMAIL PROTECTED]
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and PROT_WRITE shall be marked for update at some point
in the interval
Miklos Szeredi wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and PROT_WRITE shall be marked for update at some
On Wed, 2007-02-21 at 18:51 +0100, Miklos Szeredi wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and
Inspired by Peter Staubach's patch and the resulting comments.
An updated version of the original patch was submitted to LKML
yesterday... :-)
Strange coincidence :)
file = vma-vm_file;
start = vma-vm_end;
+ mapping_update_time(file);
This flag is checked in msync() and __fput(), and if set, the file
times are updated and the flag is cleared
Why not also check inside vfs_getattr?
This is the minimum, that the standard asks for.
Note, your porposal would touch the times in vfs_getattr(), which
means, that the
On Wed, 2007-02-21 at 19:28 +0100, Miklos Szeredi wrote:
This flag is checked in msync() and __fput(), and if set, the file
times are updated and the flag is cleared
Why not also check inside vfs_getattr?
This is the minimum, that the standard asks for.
Note, your porposal would
Trond Myklebust wrote:
On Wed, 2007-02-21 at 19:28 +0100, Miklos Szeredi wrote:
This flag is checked in msync() and __fput(), and if set, the file
times are updated and the flag is cleared
Why not also check inside vfs_getattr?
This is the minimum, that the standard asks
This flag is checked in msync() and __fput(), and if set, the file
times are updated and the flag is cleared
Why not also check inside vfs_getattr?
This is the minimum, that the standard asks for.
Note, your porposal would touch the times in vfs_getattr(), which
means,
Miklos Szeredi wrote:
Inspired by Peter Staubach's patch and the resulting comments.
An updated version of the original patch was submitted to LKML
yesterday... :-)
Strange coincidence :)
file = vma-vm_file;
start = vma-vm_end;
+
Inspired by Peter Staubach's patch and the resulting comments.
An updated version of the original patch was submitted to LKML
yesterday... :-)
Strange coincidence :)
file = vma-vm_file;
start = vma-vm_end;
+
On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote:
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and PROT_WRITE shall be marked for
On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote:
This patch makes writing to shared memory mappings update st_ctime and
st_mtime as defined by SUSv3:
The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and PROT_WRITE shall be
52 matches
Mail list logo
