From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FC3420B80B for ; Thu, 23 Jan 2025 09:49:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737625796; cv=none; b=YG9ZRvU/r4F+zZBM92CJUWTa+uF4QItq1BOMV2WqWPABHHkMjLDPBjmYXrWOXul3kviHm9dv9G9SFWSWoeT8uNOYPu1p6u/tja9A8qY4E5r3tEXQtBB9LvkpARSojINFL6DVw6TfU0yQmvGhlWoz/1aZ4r8CsGaiwKmFRxIanO0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737625796; c=relaxed/simple; bh=H5nbAN5NFrGqUqHlcHJE5RkqQzLHTc43wUGJosIhU7Y=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=E/8JcV/L00cCNesv1ZneJduCbKHWFZ2GHIjW6vFZ9wevcZD/K5ucb3OJZbkjJFpuBE03F6zRhALb/tgzH5oGPe/JxroVuHTuYtozSxw1mVNq7jUC/op7m0OFbsq4suSuqQnM9I3f1xqjJ4Nui4fWmdi5f+RrYG+JIYNGe/YO8Y0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aoIC5KpK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aoIC5KpK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32C5BC4CEE0; Thu, 23 Jan 2025 09:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737625795; bh=H5nbAN5NFrGqUqHlcHJE5RkqQzLHTc43wUGJosIhU7Y=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=aoIC5KpKy4yy4zmAaOQOZd2h/THfDm2FCcSNhDfktUEmr6qZvWtmMdqLJRwAMWK+d Ezk90P5QfVhq9ymm57aMdQyvkvep6cnz4NhO56g+PxVseTBdZpYlsfu0S4GNCmDQd3 mkyteN+g+IQq8UYM3D+m3hPVHCo01OvURMIUWeX6VUqUeRvHKmtS/UfgWc9DRPuW51 X903ERvW7iSMUz+gqqsSeM3b0d1ZKq1nnQOSWgDuZxQDZp8NwMasWx5TUrmfoNcGo5 I+icclRrTh/uXk+HQh+At3d9W53gp7KTeoy8qOny0qoUv0p+GujGZQVycHpglullof ZLzbfAcNrJkFQ== Message-ID: <8bee628f-69a4-419e-aaee-c72b7c7861f9@kernel.org> Date: Thu, 23 Jan 2025 17:49:52 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, daehojeong@google.com, jnhuang95@gmail.com, linux-kernel@vger.kernel.org, wanghui33@xiaomi.com, yudongbin@xiaomi.com Subject: Re: [f2fs-dev] [PATCH] f2fs: fix inconsistent dirty state of atomic file To: Jianan Huang , linux-f2fs-devel@lists.sourceforge.net, jaegeuk@kernel.org References: <20250123071417.253019-1-huangjianan@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20250123071417.253019-1-huangjianan@xiaomi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/23/25 15:14, Jianan Huang via Linux-f2fs-devel wrote: > When testing the atomic write fix patches, the f2fs_bug_on was > triggered as below: > > ------------[ cut here ]------------ > kernel BUG at fs/f2fs/inode.c:935! > Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI > CPU: 3 UID: 0 PID: 257 Comm: bash Not tainted 6.13.0-rc1-00033-gc283a70d3497 #5 > RIP: 0010:f2fs_evict_inode+0x50f/0x520 > Call Trace: > > ? __die_body+0x65/0xb0 > ? die+0x9f/0xc0 > ? do_trap+0xa1/0x170 > ? f2fs_evict_inode+0x50f/0x520 > ? f2fs_evict_inode+0x50f/0x520 > ? handle_invalid_op+0x65/0x80 > ? f2fs_evict_inode+0x50f/0x520 > ? exc_invalid_op+0x39/0x50 > ? asm_exc_invalid_op+0x1a/0x20 > ? __pfx_f2fs_get_dquots+0x10/0x10 > ? f2fs_evict_inode+0x50f/0x520 > ? f2fs_evict_inode+0x2e5/0x520 > evict+0x186/0x2f0 > prune_icache_sb+0x75/0xb0 > super_cache_scan+0x1a8/0x200 > do_shrink_slab+0x163/0x320 > shrink_slab+0x2fc/0x470 > drop_slab+0x82/0xf0 > drop_caches_sysctl_handler+0x4e/0xb0 > proc_sys_call_handler+0x183/0x280 > vfs_write+0x36d/0x450 > ksys_write+0x68/0xd0 > do_syscall_64+0xc8/0x1a0 > ? arch_exit_to_user_mode_prepare+0x11/0x60 > ? irqentry_exit_to_user_mode+0x7e/0xa0 > > The root cause is: f2fs uses FI_ATOMIC_DIRTIED to indicate dirty > atomic files during commit. If the inode is dirtied during commit, > such as by f2fs_i_pino_write, the vfs inode keeps clean and the > f2fs inode is set to FI_DIRTY_INODE. The FI_DIRTY_INODE flag cann't > be cleared by write_inode later due to the clean vfs inode. Finally, > f2fs_bug_on is triggered due to this inconsistent state when evict. > > To reproduce this situation: > - fd = open("/mnt/test.db", O_WRONLY) > - ioctl(fd, F2FS_IOC_START_ATOMIC_WRITE) > - mv /mnt/test.db /mnt/test1.db > - ioctl(fd, F2FS_IOC_COMMIT_ATOMIC_WRITE) > - echo 3 > /proc/sys/vm/drop_caches > > To fix this problem, clear FI_DIRTY_INODE after commit, then > f2fs_mark_inode_dirty_sync will ensure a consistent dirty state. > > Fixes: fccaa81de87e ("f2fs: prevent atomic file from being dirtied before commit") > Signed-off-by: Yunlei He > Signed-off-by: Jianan Huang > --- > fs/f2fs/segment.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > index dc1b47f9269a..71b509a31eae 100644 > --- a/fs/f2fs/segment.c > +++ b/fs/f2fs/segment.c > @@ -201,6 +201,7 @@ void f2fs_abort_atomic_write(struct inode *inode, bool clean) > clear_inode_flag(inode, FI_ATOMIC_FILE); > if (is_inode_flag_set(inode, FI_ATOMIC_DIRTIED)) { > clear_inode_flag(inode, FI_ATOMIC_DIRTIED); > + clear_inode_flag(inode, FI_DIRTY_INODE); Jianan, Can you please add comments for this change? otherwise it looks good to me. Thanks, > f2fs_mark_inode_dirty_sync(inode, true); > } > stat_dec_atomic_inode(inode);