Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

David Howells wrote: Nick Piggin [EMAIL PROTECTED] wrote: You can drop the lock, do the invalidation, Hmmm... There's a danger of incurring a race by doing that. Consider two processes both trying to write to a dirty page for which writeback will be rejected: (1) The first process gets

Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

Nick Piggin [EMAIL PROTECTED] wrote: No, you shouldn't. We could theoretically introduce a new API for this, but I think it would be preferable if you can fix the race in the fs. Actually, I might be able to do better. When making a StoreData call to the AFS server, I send all the parameters

Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

David Howells wrote: Nick Piggin [EMAIL PROTECTED] wrote: No, you shouldn't. We could theoretically introduce a new API for this, but I think it would be preferable if you can fix the race in the fs. Actually, I might be able to do better. When making a StoreData call to the AFS server, I

[PATCH] AFS: Implement shared-writable mmap [try #2]

Implement shared-writable mmap for AFS. The key with which to access the file is obtained from the VMA at the point where the PTE is made writable by the page_mkwrite() VMA op and cached in the affected page. If there's an outstanding write on the page made with a different key, then

Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

Nick Piggin [EMAIL PROTECTED] wrote: I would strongly suggest you used (0, PAGE_CACHE_SIZE) for the range, That tells prepare_write() that the region to be modified is the whole page - which is incorrect. We're going to change a little bit of it. Hmmm... Thinking about it again, I probably

Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

David Howells wrote: Nick Piggin [EMAIL PROTECTED] wrote: I would strongly suggest you used (0, PAGE_CACHE_SIZE) for the range, That tells prepare_write() that the region to be modified is the whole page - which is incorrect. We're going to change a little bit of it. You don't know how

Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

Nick Piggin [EMAIL PROTECTED] wrote: In general (modulo bugs and crazy filesystems), you're not allowed to have !uptodate pages mapped into user addresses because that implies the user would be allowed to see garbage. Ths situation I have to deal with is a tricky one. Consider: (1) User A

Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

David Howells wrote: Nick Piggin [EMAIL PROTECTED] wrote: In general (modulo bugs and crazy filesystems), you're not allowed to have !uptodate pages mapped into user addresses because that implies the user would be allowed to see garbage. Ths situation I have to deal with is a tricky one.

Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

Nick Piggin [EMAIL PROTECTED] wrote: I can't call invalidate_inode_pages() or similar because that might incorrectly kill one of B's writes (or someone else's writes); besides, the on-server file hasn't changed. Why would that kill anyone's writes? Because invalidate_inode_pages()

Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

David Howells wrote: Nick Piggin [EMAIL PROTECTED] wrote: I can't call invalidate_inode_pages() or similar because that might incorrectly kill one of B's writes (or someone else's writes); besides, the on-server file hasn't changed. Why would that kill anyone's writes? Because

Re: [PATCH] AFS: Implement shared-writable mmap [try #2]

Nick Piggin [EMAIL PROTECTED] wrote: How do you do a write-through cache for shared-writable mmap? For shared writable mmap? I don't know... You can't do write-through caching for shared-writable mmap because the writes go directly into the pagecache once the page is made writable, at