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 CFF9313AC1 for ; Fri, 24 Jan 2025 07:30:48 +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=1737703848; cv=none; b=Lb+4MjTtzjUBkeAtzKyZqo3pb+B2Ct5xKNRVcs/wExIlMLOWkOyYKYNlbdELHInoiyMYxIK9TnCpoKz3dR+9/FeCZ6XSv37sEzXRtt5J2gRgiD/v2FzDq+93A5XyWmkL5VoLgBu77rAIpUgKGlSLpjHwyMYDzIPF14mkZnFqb3Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737703848; c=relaxed/simple; bh=sCuoP9efc2REoQKmSVl+umUkhz7VP2sBjFztWdib3YQ=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=uzNTPJbeRGd9IhhCK0HzzpNdZDD2mfN0iR/7G/OeyuxNyzuLUdnfIVrUuI1rig250GL484muK/LHwZsRlF3++APMYeOnElg/d+RrsGBDyl0ngcwZpUGQe8ZtZTp6gpD9n8omlR0XHztjC5mtOaLSsGyhOX8dkBM6R5lH8YYmOCs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H2yTaqIS; 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="H2yTaqIS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF89AC4CEDD; Fri, 24 Jan 2025 07:30:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737703848; bh=sCuoP9efc2REoQKmSVl+umUkhz7VP2sBjFztWdib3YQ=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=H2yTaqISV5OLQiyUnbgsjXMIlsU5r8xyeTcSL1YBCV2nEZWtKZoZ+FhircWEEPp9d aClnSl+9O/dO1VZdLcOfkvdv1L17EUQfxpHC+BaERta5vAh4jdqsY1okEgIO4xNztl 7J//KNo39z9+08v97ryPPmQOvhlmxrVQv9deZ83QjMICNBSRyzNZQQL9/nMoHly+Dn edps7J2U+fpw5y13KYTqqA52xJ6glgFuvgHrd09ulY3wAE5bgnj31h/jJJxClssbuQ PIUcGYgSKdgFaew0cEWciCZ/iMpr0fW0bTTgAww010jvyc/w1eigq/Z+p0sBcLAiO6 2FFA22r/b91mA== Message-ID: <2e51d9c8-840d-486f-a1eb-f18500d2f252@kernel.org> Date: Fri, 24 Jan 2025 15:30:43 +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 v3] f2fs: fix inconsistent dirty state of atomic file To: Jianan Huang , linux-f2fs-devel@lists.sourceforge.net, jaegeuk@kernel.org References: <20250124015042.273336-1-huangjianan@xiaomi.com> <20250124055751.283198-1-huangjianan@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20250124055751.283198-1-huangjianan@xiaomi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/24/25 13:57, 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 Reviewed-by: Chao Yu Thanks,