Messages in this thread | | | Date | Thu, 17 May 2007 16:39:46 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH] AFS: Implement shared-writable mmap [try #2] |
| |
David Howells wrote: > Nick Piggin <nickpiggin@yahoo.com.au> 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 EKEYREJECTED from the server, drops its lock and > is then preempted. > > (2) The second process gets EKEYREJECTED from the server, drops its lock, > truncates the page, reloads the page and modifies it. > > (3) The first process resumes and truncates the page, thereby splatting the > second process's write. > > Or: > > (1) The first process gets EKEYREJECTED from the server, clears the writeback > information from the page, drops its lock and is then preempted. > > (2) The second process attaches its own writeback information to the page and > modifies it. > > (3) The first process resumes and truncates the page, thereby splatting the > second process's write.
If there are race issues involving concurrent invalidations, then you'd fix that up by taking a filesystem specific lock to prevent them.
Generic write path should be holding i_mutex, but I don't think you can take that from page_mkwrite... Just add one of your own.
> Really, what I want to do is pass the page lock to truncate to deal with. > Better still, I want truncate to be selective, based on whether or not a page > is still associated with the rejected writeback. I wonder if I should call > truncate_complete_page() or invalidate_complete_page() directly.
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.
-- 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/
| |