On Wed, 21 February 2007 13:09:56 +, Jörn Engel wrote:
3. Seperating out sync notification
Ok, that turned out to be a bad idea. Deadlock still exists. Now it is
harder to hit and involves:
I_SYNC waiting on LogFS write mutex
clear_inode waiting on I_SYNC with I_FREEING set
find_inode
Hi,
Im not sure if this is the right list to ask that question but,
the function load_elf_binary calls clear_user on elf_bss and there's a comment
saying:
/*
* This bss-zeroing can fail if the ELF
* file specifies odd protections. So
* we don't check the return value
*/
what I would
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
On Thu, Feb 22, 2007 at 04:58:28PM -0500, J. Bruce Fields wrote:
I'm also curious--exposing my total ignorance of the dlm--why taking
such a lock would always be so expensive, or would always be required on
open. Surely the typical case should be one where there's no conflict
and never has
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
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
14 matches
Mail list logo
