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 E4BDD1D7999 for ; Fri, 24 Jan 2025 05:14:35 +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=1737695676; cv=none; b=TT8fJ6YUCoTXNcXOzrg+M8izMIy1kjc3GpiooE6t/I25snYDahmHQ3mIfnwgzMETgl2xy/H+pHUtdlZErss+wKYXB/qVXDk7oZ1gWhJ5SyElmWok8AKZ54kIBGxEiOQZLq2OwVPjMfvTFH6M7Ji0Xw+OhkraM3HGfQRih8iYPG4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737695676; c=relaxed/simple; bh=2jOEOLQybauA8dK++V0eJu8P7lO4XN/lHOd1F+peXeM=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=lReROpl3GsX2pt5rIjZYGPT49jh+gIg8XvR7olO+XcCVnOH9kO9ozMBw8FJ9bST6SRumcrje1PCxwd0UyTokRDxIjqaSY3zEQMqfsLnO20RpoUPoL/g+WZ7+wIydfp/Yx3jPkaRAqkIw4VOlSZGGFCyufuok9hzYps9G2C2Gk8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f5MZsM8m; 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="f5MZsM8m" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FB08C4CED2; Fri, 24 Jan 2025 05:14:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737695675; bh=2jOEOLQybauA8dK++V0eJu8P7lO4XN/lHOd1F+peXeM=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=f5MZsM8m7WrobiV+Roo+t6i7wbVHmOYs8zri5pl59TJQQvaWNMBjNgdHiWJG2H10N ZSCzOx9Fn6o9BbMaGoJ+/U+prxKpM01pRGmyc6Q3RdiQMpuK8GdY2oyAsr5ycIS8qY U6yR+2stU0YjNnXyXQJqDgaPZvOi0Vz4Y/QGOeihmCDBqXZzHJwlonW4NkQ+ZWmxgo VoX7iPXcs7pWXYDmn/lDorOWnigypVS2/6bFWHeabW6/okgUaeJXTGA2iL2hlaAB66 SM94dGZXCLFUIcj7pz0IhZtrPN6KUL7h0CXqbwvEwuWFTOY4zS5hJRxR91b0m7hPf+ uv1d0ccLy+aOQ== Message-ID: Date: Fri, 24 Jan 2025 13:14:31 +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, linux-kernel@vger.kernel.org, daehojeong@google.com, heyunlei@xiaomi.com, wanghui33@xiaomi.com, yudongbin@xiaomi.com, jnhuang95@gmail.com Subject: Re: [PATCH v2] 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> <20250124015042.273336-1-huangjianan@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20250124015042.273336-1-huangjianan@xiaomi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/24/25 09:50, Jianan Huang 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 > --- > Changes since v1: > - Add comments suggested by Chao. > - Add missing stat reduction. > > fs/f2fs/segment.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > index dc1b47f9269a..de1597110f76 100644 > --- a/fs/f2fs/segment.c > +++ b/fs/f2fs/segment.c > @@ -201,6 +201,15 @@ 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); > + /* > + * The vfs inode keeps clean during commit, but the f2fs inode > + * doesn't. So clear the dirty state after commit and let > + * f2fs_mark_inode_dirty_sync ensure a consistent dirty state. > + */ > + if (is_inode_flag_set(inode, FI_DIRTY_INODE)) { > + clear_inode_flag(inode, FI_DIRTY_INODE); > + stat_dec_dirty_inode(F2FS_I_SB(inode), DIRTY_META); > + } How about calling f2fs_inode_synced() directly? > f2fs_mark_inode_dirty_sync(inode, true); > } > stat_dec_atomic_inode(inode);