From: Al Viro <viro@zeniv.linux.org.uk>
To: Lizhi Xu <lizhi.xu@windriver.com>
Cc: syzbot+80e60df48923e1b7691d@syzkaller.appspotmail.com,
aivazian.tigran@gmail.com, linux-kernel@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] bfs: put a inode if link count is 0
Date: Thu, 9 Jan 2025 06:22:16 +0000 [thread overview]
Message-ID: <20250109062216.GQ1977892@ZenIV> (raw)
In-Reply-To: <20250109034946.1386748-1-lizhi.xu@windriver.com>
On Thu, Jan 09, 2025 at 11:49:46AM +0800, Lizhi Xu wrote:
>
> The reproducer performs the rename operation on the file twice in succession
> and changes the file to the same file name. After the first rename operation,
> the number of links in the inode is set to 0. In the second execution, the
> same inode is used, resulting in a 0 value warning for i_nlink.
>
> To avoid this issue, put the target inode before exiting the bfs_rename.
This is completely insane - you get an extra drop of in-core inode
refcount, which *will* end up with dangling pointer and memory corruption.
Besides, there is a perfectly legitimate case when you open a file and
rename something on top of it. It MUST remain open and alive until the
last in-core reference to inode goes away, which must not happen before
close().
Frankly, if you do not understand why that is wrong, you should not
mess with anything filesystem-related until you learn the area enough.
NAK.
next prev parent reply other threads:[~2025-01-09 6:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-02 15:51 [syzbot] [bfs?] WARNING in bfs_rename syzbot
2025-01-09 3:49 ` [PATCH] bfs: put a inode if link count is 0 Lizhi Xu
2025-01-09 6:22 ` Al Viro [this message]
2025-01-09 6:39 ` Lizhi Xu
2025-01-09 7:32 ` Al Viro
2025-01-09 7:39 ` Lizhi Xu
2025-01-17 1:46 ` [PATCH V2] bfs: prevent rename a target of " Lizhi Xu
2025-01-10 6:24 ` [PATCH] bfs: put a inode if " kernel test robot
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=20250109062216.GQ1977892@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=aivazian.tigran@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizhi.xu@windriver.com \
--cc=syzbot+80e60df48923e1b7691d@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 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.