linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: David Chinner <dgc@sgi.com>,
	xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality
Date: Thu, 8 Feb 2007 01:44:15 +1100	[thread overview]
Message-ID: <20070207144415.GN44411608@melbourne.sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0702071256530.25060@blonde.wat.veritas.com>

On Wed, Feb 07, 2007 at 01:00:28PM +0000, Hugh Dickins wrote:
> On Wed, 7 Feb 2007, David Chinner wrote:
> 
> > On Christoph's suggestion, take the guts of the proposed
> > xfs_vm_page_mkwrite function and implement it as a generic
> > core function as it used no specific XFS code at all.
> > 
> > This allows any filesystem to easily hook the ->page_mkwrite()
> > VM callout to allow them to set up pages dirtied by mmap
> > writes correctly for later writeout.
> > 
> > Signed-Off-By: Dave Chinner <dgc@sgi.com>
> 
> I'm worried about concurrent truncation.  Isn't it the case that
> i_mutex is held when prepare_write and commit_write are normally
> called?  But not here when page_mkwrite is called.

I'm not holding i_mutex. I assumed that it was probably safe to do
because we are likely to be reading the page off disk just before we
call mkwrite and that has to be synchronised with truncate in some
manner....

So, do I need to grab the i_mutex here? Is that safe to do that in
the middle of a page fault? If we do race with a truncate and the
page is now beyond EOF, what am I supposed to return?

I'm fishing for what I'm supposed to be doing here because there's
zero implementations of this callout in the kernel and the comments
in the code explaining the interface constraints are
non-existant....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  reply	other threads:[~2007-02-07 14:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-07 12:49 [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality David Chinner
2007-02-07 12:55 ` David Chinner
2007-02-07 13:00 ` Hugh Dickins
2007-02-07 14:44   ` David Chinner [this message]
2007-02-07 15:52     ` Chris Mason
2007-02-08  2:34       ` Nick Piggin
2007-02-07 15:56     ` Hugh Dickins
2007-02-07 22:50       ` David Chinner
2007-02-08 13:11         ` Chris Mason
2007-02-08 22:30           ` David Chinner

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=20070207144415.GN44411608@melbourne.sgi.com \
    --to=dgc@sgi.com \
    --cc=hugh@veritas.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=xfs@oss.sgi.com \
    /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;
as well as URLs for NNTP newsgroup(s).