From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-nilfs <linux-nilfs@vger.kernel.org>,
syzbot+1097e95f134f37d9395c@syzkaller.appspotmail.com,
syzbot+32c3706ebf5d95046ea1@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com,
LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 2/2] nilfs2: do not update mtime of renamed directory that is not moved
Date: Sat, 11 Jan 2025 23:26:36 +0900 [thread overview]
Message-ID: <20250111143518.7901-3-konishi.ryusuke@gmail.com> (raw)
In-Reply-To: <20250111143518.7901-1-konishi.ryusuke@gmail.com>
A minor issue with nilfs_rename, originating from an old ext2
implementation, is that the mtime is updated even if the rename target
is a directory and it is renamed within the same directory, rather
than moved to a different directory.
In this case, the child directory being renamed does not change in any
way, so changing its mtime is unnecessary according to the
specification, and can unnecessarily confuse backup tools.
In ext2, this issue was fixed by commit 39fe7557b4d6 ("ext2: Do not
update mtime of a moved directory") and a few subsequent fixes, but it
remained in nilfs2.
Fix this issue by not calling nilfs_set_link(), which rewrites the
inode number of the directory entry that refers to the parent
directory, when the move target is a directory and the source and
destination are the same directory.
Here, the directory to be moved only needs to be read if the inode
number of the parent directory is rewritten with nilfs_set_link, so
also adjust the execution conditions of the preparation work to avoid
unnecessary directory reads.
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
---
fs/nilfs2/namei.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/fs/nilfs2/namei.c b/fs/nilfs2/namei.c
index e02fae6757f1..953fbd5f0851 100644
--- a/fs/nilfs2/namei.c
+++ b/fs/nilfs2/namei.c
@@ -370,6 +370,7 @@ static int nilfs_rename(struct mnt_idmap *idmap,
struct folio *old_folio;
struct nilfs_dir_entry *old_de;
struct nilfs_transaction_info ti;
+ bool old_is_dir = S_ISDIR(old_inode->i_mode);
int err;
if (flags & ~RENAME_NOREPLACE)
@@ -385,7 +386,7 @@ static int nilfs_rename(struct mnt_idmap *idmap,
goto out;
}
- if (S_ISDIR(old_inode->i_mode)) {
+ if (old_is_dir && old_dir != new_dir) {
err = -EIO;
dir_de = nilfs_dotdot(old_inode, &dir_folio);
if (!dir_de)
@@ -397,7 +398,7 @@ static int nilfs_rename(struct mnt_idmap *idmap,
struct nilfs_dir_entry *new_de;
err = -ENOTEMPTY;
- if (dir_de && !nilfs_empty_dir(new_inode))
+ if (old_is_dir && !nilfs_empty_dir(new_inode))
goto out_dir;
new_de = nilfs_find_entry(new_dir, &new_dentry->d_name,
@@ -412,7 +413,7 @@ static int nilfs_rename(struct mnt_idmap *idmap,
goto out_dir;
nilfs_mark_inode_dirty(new_dir);
inode_set_ctime_current(new_inode);
- if (dir_de)
+ if (old_is_dir)
drop_nlink(new_inode);
drop_nlink(new_inode);
nilfs_mark_inode_dirty(new_inode);
@@ -420,7 +421,7 @@ static int nilfs_rename(struct mnt_idmap *idmap,
err = nilfs_add_link(new_dentry, old_inode);
if (err)
goto out_dir;
- if (dir_de) {
+ if (old_is_dir) {
inc_nlink(new_dir);
nilfs_mark_inode_dirty(new_dir);
}
@@ -434,9 +435,10 @@ static int nilfs_rename(struct mnt_idmap *idmap,
err = nilfs_delete_entry(old_de, old_folio);
if (likely(!err)) {
- if (dir_de) {
- err = nilfs_set_link(old_inode, dir_de, dir_folio,
- new_dir);
+ if (old_is_dir) {
+ if (old_dir != new_dir)
+ err = nilfs_set_link(old_inode, dir_de,
+ dir_folio, new_dir);
drop_nlink(old_dir);
}
nilfs_mark_inode_dirty(old_dir);
--
2.43.0
prev parent reply other threads:[~2025-01-11 14:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-10 13:42 [syzbot] [nilfs?] kernel BUG in nilfs_set_link syzbot
2025-01-11 14:26 ` [PATCH 0/2] nilfs2: fix issues with rename operations Ryusuke Konishi
2025-01-11 14:26 ` [PATCH 1/2] nilfs2: handle errors that nilfs_prepare_chunk() may return Ryusuke Konishi
2025-01-11 14:26 ` Ryusuke Konishi [this message]
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=20250111143518.7901-3-konishi.ryusuke@gmail.com \
--to=konishi.ryusuke@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=syzbot+1097e95f134f37d9395c@syzkaller.appspotmail.com \
--cc=syzbot+32c3706ebf5d95046ea1@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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
all inboxes | Powered by JetHome®