LKML Archive on
help / color / mirror / Atom feed
From: Anton Altaparmakov <>
To: Mark Fasheh <>
Cc: Nick Piggin <>,
	Hugh Dickins <>,
	linux-kernel <>,
	Linux Memory Management <>,
	David Howells <>,
	Andrew Morton <>
Subject: Re: page_mkwrite caller is racy?
Date: Tue, 30 Jan 2007 14:58:50 +0000 (GMT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, 29 Jan 2007, Mark Fasheh wrote:
> On Tue, Jan 30, 2007 at 12:14:24PM +1100, Nick Piggin wrote:
> > This is another discussion, but do we want the page locked here? Or
> > are the filesystems happy to exclude truncate themselves?
> No page lock please. Generally, Ocfs2 wants to order cluster locks outside
> of page locks. Also, the sparse b-tree support I'm working on right now will
> need to be able to allocate in ->page_mkwrite() which would become very
> nasty if we came in with the page lock - aside from the additional cluster
> locks taken, ocfs2 will want to zero some adjacent pages (because we support
> atomic allocation up to 1 meg).

Ditto for NTFS.  I will need to lock pages on both sides of the page for 
large volume cluster sizes thus I will have to drop the page lock if it is 
already taken so it might as well not be...  Although I do not feel 
strongly about it.  If the page is locked I will just drop the lock and 
then take it again.  If possible to not have the page locked that would 
make my code a little easier/more efficient I expect...

Best regards,

Anton Altaparmakov <aia21 at> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer,

  reply	other threads:[~2007-01-30 15:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-29 10:20 Nick Piggin
2007-01-29 16:08 ` Hugh Dickins
2007-01-29 20:41   ` Anton Altaparmakov
2007-01-30  1:14   ` Nick Piggin
2007-01-30  1:51     ` Mark Fasheh
2007-01-30 14:58       ` Anton Altaparmakov [this message]
2007-01-31  1:18         ` Nick Piggin
2007-01-29 20:00 ` Mark Fasheh
2007-02-01 11:44 ` David Howells

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: page_mkwrite caller is racy?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).