From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f69.google.com (mail-ot1-f69.google.com [209.85.210.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5F032D978A for ; Sat, 6 Dec 2025 06:55:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.69 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765004156; cv=none; b=iq7WXujgLpvt28v3ZNsmmCgQsM8hM8ANv/8zVtqzTYAPT97YQOX02NegE04SedhwrHkCe3PFg4C5JjIvQiopizaz0iuRb4FnzJtMhSi2jskjEZ9IxRXU095dAPK7kAFkk+WEt9D49rvQk6SSSDsKJmCxHJlA3ot3mqe5lxNiRsc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765004156; c=relaxed/simple; bh=q5kb2QMUOZQ9RXSgtLJC6gFngrkG0FqfTqYLhROW6o8=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=qByhzg7HpA1p7vRAzvgcmo5z319Ibw0nLmgXVec12LVVpT8jUhwT0iaF9EIL6xfCKuO4HdJ0y6oSj3jM2B1UoUif+8Z3KzZMsebhhvipkQFd5GGNfn87WC3B+jfW8ugiFtbBPOykPxr3tA9BqYD5IY66YlJfxRKRQItJ7UzqLQ4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.210.69 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-ot1-f69.google.com with SMTP id 46e09a7af769-7c76977192eso6248138a34.3 for ; Fri, 05 Dec 2025 22:55:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765004154; x=1765608954; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=afeVOEm+bDmmQfeOPip7AH4c7NgavRosi5dWGCXhU4E=; b=eOUXsmURTOTIu0Al0iChv7V/egxI0Kuum19jTMSyBsTi5sVsD4pgm2pTONDTgXooCJ RVSYp3+pEsC4/ZeeZE821zxgWV2S5unWncSygtTtvFisuJsIvCxLx3RgehGs/asJsz09 umHs0MYtztoWNViWhX9EC7zaosx7uSfvn0fKoN8fznOxYhzR81ftCJsJ3k+K2fTHIRsk wEiSJPyFzb9tVK6ASRejR+Vb0TsGxpR917owmcZ0Of9LhPrvJqvae3OiQl+6W+lw8qmp IuaVBixoKbeBg0B7b4ZAt0BiSU7z0IwELQU9vSqJiULO/+3Je6EE8RTdHps4FkOmCgEL L3IA== X-Gm-Message-State: AOJu0YwqOHOdDtmbT8ffCcP4KFPU/8dDMl7feZNBlrspyVMWVI6smFHF 541M/AGf+Rs/A03Vu2gQ4FgAu7q+cki7xWIb7h7EscsPWJCmzp7/DzZ6PwwwX+A4jcftpo7vMFd CUI9CKRoGWJXjzdWfOcz855TiuU6q8k1ZucqH8/zppS7OxhI5Sa91H0cEZJw= X-Google-Smtp-Source: AGHT+IGf3ovsgYCMT9B62FxeT0tItXJVl3us00ADE3rqXhUCaJdE5lVkJTVSkDQ7CBZMmWNl72qGExIWw5iTpqWYOwo/UosYaxvF Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:220d:b0:659:9a49:8f19 with SMTP id 006d021491bc7-6599a94b99emr698170eaf.42.1765004154151; Fri, 05 Dec 2025 22:55:54 -0800 (PST) Date: Fri, 05 Dec 2025 22:55:54 -0800 In-Reply-To: <69332cf9.a70a0220.243dc6.0011.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <6933d37a.a70a0220.38f243.0017.GAE@google.com> Subject: Forwarded: [PATCH] f2fs: fix hung task in block_operations during checkpoint From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] f2fs: fix hung task in block_operations during checkpoint Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master f2fs_sync_inode_meta() can return 0 (success) even when f2fs_update_inode_page() fails and triggers f2fs_stop_checkpoint(). This happens because the error flag check only occurs at the start of each loop iteration, not after f2fs_update_inode_page() returns. When I/O errors occur: 1. f2fs_update_inode_page() retries 8 times then calls f2fs_stop_checkpoint(), which sets CP_ERROR_FLAG 2. f2fs_sync_inode_meta() returns 0 without checking the error flag 3. block_operations() sees success and loops back to retry_flush_quotas 4. Dirty inodes remain on list (sync failed), loop repeats forever 5. Checkpoint never completes, waiters block indefinitely This causes hung tasks when operations like unlink wait for checkpoint completion while holding locks that other tasks need. Fix by checking f2fs_cp_error() after processing each inode in f2fs_sync_inode_meta() to detect errors from f2fs_update_inode_page(). Reported-by: syzbot+4235e4d7b6fd75704528@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4235e4d7b6fd75704528 Signed-off-by: Deepanshu Kartikey --- fs/f2fs/inode.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index f1cda1900658..8deeb865dbb1 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -763,6 +763,10 @@ void f2fs_update_inode_page(struct inode *inode) struct folio *node_folio; int count = 0; retry: + if (unlikely(f2fs_cp_error(sbi))) { + printk("f2fs: f2fs_update_inode_page bailing out due to cp_error\n"); + goto stop_checkpoint; + } node_folio = f2fs_get_inode_folio(sbi, inode->i_ino); if (IS_ERR(node_folio)) { int err = PTR_ERR(node_folio); -- 2.43.0