public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Robbie Ko <robbieko@synology.com>
To: linux-btrfs@vger.kernel.org
Cc: Robbie Ko <robbieko@synology.com>
Subject: [PATCH v3 6/7] Btrfs: incremental send, don't send utimes for non-existing directory
Date: Tue, 23 Jun 2015 18:39:50 +0800	[thread overview]
Message-ID: <1435055991-10109-7-git-send-email-robbieko@synology.com> (raw)
In-Reply-To: <1435055991-10109-1-git-send-email-robbieko@synology.com>

There's one where we attempt to get utimes from a directory that
doesn't exist in the send snapshot.

Example:

Parent snapshot:
|---- a/ (ino 259)
    |---- c (ino 264)
|---- b/ (ino 260)
    |---- d (ino 265)
|---- del/ (ino 263)
    |---- item1/ (ino 261)
    |---- item2/ (ino 262)

Send snapshot:
|---- a/ (ino 259)
|---- b/ (ino 260)
|---- c/ (ino 264)
    |---- item2 (ino 262)
|---- d/ (ino 265)
    |---- item1/ (ino 261)

First, 261 can't move to d/item1 without the rename of inode 265.
So as 262. Thus 261 and 262 need to wait for rename.
Second, since 263 will be deleted and there are two waiting
sub-directory 261 and 262, rmdir_ino of 261 will set to 263 and
rmdir_ino of 262 is not set. If 262 is processed earlier than 261,
utime of both 263 and 264 will be updated. However, 263 should not
update since it will vanish.

We're trying to send utimes for a directory/inode that doesn't exist
in the send snapshot. That send_utimes() will use part of a leaf
beyond its boundaries or a wrong slot (belonging to some other
unrelated inode), because btrfs_search_slot() returns 1 when we call
it to find the inode item to extract a utimes value from, and
send_utimes() is not prepared to deal with such case because it
assumes no one calls it for an inode that doesn't exist in the send
root. And that we fix the problem in the offending caller.

Signed-off-by: Robbie Ko <robbieko@synology.com>
---

V3:modify comment

 fs/btrfs/send.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 838abf4..dcf384d 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -3241,8 +3241,18 @@ finish:
 	 * and old parent(s).
 	 */
 	list_for_each_entry(cur, &pm->update_refs, list) {
-		if (cur->dir == rmdir_ino)
+		/*
+		 * don't send utimes for non-existing directory
+		 */
+		ret = get_inode_info(sctx->send_root, cur->dir, NULL,
+			     NULL, NULL, NULL, NULL, NULL);
+		if (ret == -ENOENT) {
+			ret = 0;
 			continue;
+		}
+		if (ret < 0)
+			goto out;
+
 		ret = send_utimes(sctx, cur->dir, cur->dir_gen);
 		if (ret < 0)
 			goto out;
-- 
1.9.1


  parent reply	other threads:[~2015-06-23 10:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-23 10:39 [PATCH v3 0/7] Btrfs incremental send fix serval case for rename and rm directory Robbie Ko
2015-06-23 10:39 ` [PATCH v3 1/7] Revert "Btrfs: incremental send, remove dead code" Robbie Ko
2015-06-23 15:09   ` Filipe David Manana
2015-06-23 15:24     ` David Sterba
2015-06-23 10:39 ` [PATCH v3 2/7] Btrfs: incremental send, avoid circular waiting and descendant overwrite ancestor need to update path Robbie Ko
2015-06-23 10:39 ` [PATCH v3 3/7] Btrfs: incremental send, avoid ancestor rename to descendant Robbie Ko
2015-06-23 15:05   ` Filipe David Manana
2015-06-23 10:39 ` [PATCH v3 4/7] Btrfs: incremental send, fix orphan_dir_info leak Robbie Ko
2015-06-23 10:39 ` [PATCH v3 5/7] Btrfs: incremental send, fix rmdir but dir have a unprocess item Robbie Ko
2015-06-23 10:39 ` Robbie Ko [this message]
2015-06-23 10:39 ` [PATCH v3 7/7] Btrfs: incremental send, avoid the overhead of allocating an orphan_dir_info object unnecessarily Robbie Ko
2015-06-23 14:52   ` David Sterba
2015-06-23 15:35 ` [PATCH v3 0/7] Btrfs incremental send fix serval case for rename and rm directory Filipe David Manana

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=1435055991-10109-7-git-send-email-robbieko@synology.com \
    --to=robbieko@synology.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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