From: Sage Weil <sage@newdream.net>
To: Chris Mason <chris.mason@oracle.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone()
Date: Sun, 18 Sep 2011 22:40:42 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.1109182237480.24861@cobra.newdream.net> (raw)
In-Reply-To: <1316359797-sup-4549@shiny>
On Sun, 18 Sep 2011, Chris Mason wrote:
> Excerpts from Sage Weil's message of 2011-09-16 12:39:06 -0400:
> > On Fri, 16 Sep 2011, Li Zefan wrote:
> > > It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
> > > (Btrfs: truncate pages from clone ioctl target range)
> > >
> > > We should pass the dest range to the truncate function, but not the
> > > src range.
> >
> > Sigh... yes.
> >
> > > Also move the function before locking extent state.
> >
> > Hmm, any reason? i_mutex protects us from a racing write(2), but what
> > about a racing mmap()? e.g.
> >
> > cloner: truncates dest pages
> > writer: mmap -> page_mkwrite locks extent, creates new dirty page, unlocks
> > cloner: locks extent, clones, unlocks extent
>
> Thanks guys. The locking order is page lock -> extent lock. So if we
> call truncate_inode_pages with the extent lock held, we're off into
> ABBA.
Oh right. This patch makes sense now.
> If we want to avoid the mmap race, we'll have to look for the dirty
> pages with the extent lock held, drop the lock and goto back to the
> truncate_inode_pages call.
Yeah, given that (at Li points out) we're not locking dst extents at all,
I don't think it's worth worrying about now. Sorry for the noise!
sage
next prev parent reply other threads:[~2011-09-19 5:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-16 8:59 [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone() Li Zefan
2011-09-16 16:39 ` Sage Weil
2011-09-18 15:31 ` Chris Mason
2011-09-19 5:40 ` Sage Weil [this message]
2011-09-19 3:07 ` Li Zefan
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=Pine.LNX.4.64.1109182237480.24861@cobra.newdream.net \
--to=sage@newdream.net \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lizf@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.