Messages in this thread | | | Date | Thu, 17 May 2007 03:28:13 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH] AFS: Implement shared-writable mmap [try #2] |
| |
David Howells wrote: > Nick Piggin <nickpiggin@yahoo.com.au> 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() forcibly removes the dirty flag from each page
It had better not. We use that sucker to nuke pagecache when we're trying to reclaim inodes, for example...
>>>I can't as it can/would deadlock if called from prepare_write() in two >>>different ways. >> >>Which ways? Are you talking about prepare_write being called from >>page_mkwrite, or anywhere? > > > (1) prepare_write() is called with the target page locked and does not release > the lock. The truncation routines lock the page prior to invalidating it. > Any truncation routine that skips locked pages is of no use.
You can drop the lock, do the invalidation, and return AOP_TRUNCATED_PAGE. The new aops patches will provide a better solution, but that will work today.
> (2) Consider a run of pages that make up a single write by one user. Two > other writes from other users may be attempting to overwrite that run at > the same time. Each of them would need to invalidate the other's locked > page(s).
See #1.
> Furthermore, the caller of prepare_write() probably won't take kindly to the > page it's dealing with being evicted from the pagecache.
It's fine if you return AOP_TRUNCATED_PAGE.
>>More generally it sounds like a nasty thing to have a writeback cache if it >>can become incoherent (due to dirty pages that subsequently cannot be >>written back) without notification. Have you tried doing a write-through >>one? > > > How do you do a write-through cache for shared-writable mmap?
I just mean more generally. simple write(2) writes, for starters.
For shared writable mmap? I don't know... does POSIX require mmap data to be coherent with read(2)/write(2)? ;)
>>You may be clearing PG_uptodate, but isn't there still an underlying problem >>that you can have mappings to the page at that point? If that isn't a problem >>for you, then I don't know why you would have to clear PG_uptodate at all. > > > There might be, yes. I guess I should ask the VM to nuke all PTEs to each of > these pages too.
That's what the invalidate / truncate routines do.
-- SUSE Labs, Novell Inc. - 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/
| |