From: David Howells <dhowells@redhat.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] AFS: Implement shared-writable mmap [try #2]
Date: Wed, 16 May 2007 17:56:27 +0100 [thread overview]
Message-ID: <23262.1179334587@redhat.com> (raw)
In-Reply-To: <464B3209.4010003@yahoo.com.au>
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
in the inode and then calls invalidatepage() - and thus they don't get written
back, but some of those pages may contain writes from other processes. The
whole inode isn't owned by one user at a time.
I hadn't considered invalidate_inode_pages_range(), but that suffers from the
deadlock problem.
> > 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.
(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).
Furthermore, the caller of prepare_write() probably won't take kindly to the
page it's dealing with being evicted from the pagecache.
> 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?
> 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.
David
next prev parent reply other threads:[~2007-05-16 16:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-16 10:02 [PATCH] AFS: Implement shared-writable mmap [try #2] David Howells
2007-05-16 12:07 ` Nick Piggin
2007-05-16 13:16 ` David Howells
2007-05-16 13:32 ` Nick Piggin
2007-05-16 16:12 ` David Howells
2007-05-16 16:32 ` Nick Piggin
2007-05-16 16:56 ` David Howells [this message]
2007-05-16 17:28 ` Nick Piggin
2007-05-16 17:46 ` David Howells
2007-05-16 17:59 ` Nick Piggin
2007-05-16 18:45 ` David Howells
2007-05-17 6:39 ` Nick Piggin
2007-05-17 12:30 ` David Howells
2007-05-17 17:46 ` David Howells
2007-05-18 2:29 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23262.1179334587@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox