From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (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 3D9523EAC98 for ; Tue, 17 Mar 2026 15:28:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773761326; cv=none; b=Zo0zLMEizQW0y10dZ4wOLsSJ/4L3fzhN+JJ/4+Og/BXCTpwZFHp5llNRkkLNxUl7yQ/xKmypJL9x6EJJqOiR91yaLcYJ7ePluWa+GY9OVUH7T6yVEzyf/+LBt+Akir6LCwwilpKu2CIqdJ0RPCv2Gj2RXoi5alcUUkJhh0mC7gU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773761326; c=relaxed/simple; bh=0Qz3/23EgCQRsk7KJH/nR2CSAqH13QHY5Vyo+XAj/mY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=msgc3grlGbinZCetx42nO5AaEpY9fpHUEY13/7dG/o9FK4PhG6nyY5in+MkrblYdPiHUi+p9aHc2CLvW9eDLP8vjZiK/fkgAtZbZmzRZ5Ii2X3bTEyIItW0iUie2T47iFnGi8UqiN3j7o6plHITlvZeeiWVgLU4dOi4n48/ods0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=P0NRc3SE; arc=none smtp.client-ip=209.85.214.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="P0NRc3SE" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2aecab39ad2so4333615ad.2 for ; Tue, 17 Mar 2026 08:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773761324; x=1774366124; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=uyVz1/VY28BNGviPo4SJ7e0WzgpIsIL/HOrakd5K9SA=; b=P0NRc3SE6GkxjAs2evC1+YExc2bhlt2n1Exzo8pdGwgVQdD5yqsMjLhNTGanEeFYNJ n9ODvvcCQ+O4Tff8FGoI1VXAtx/OGHcSH1gKGJFsyQ0RWe/HDa0wHrJF8s79rz/1VdWy HMBOmS6i7ApBshBnPpFtKXkFuAluaCXTiAG6UF8QiVhJIs0MOqXCvBVwwExHEQzGp5wr EN0inlcNfDNe8M6qZ0ESsSZqRx2G1KOcrk0NdwE18Noki5ip6I0oBAAiyQEvr7BC7RQH vQw2kQbVWSK36ybM1lBcq5KUawO9l63vuuUWP2G8kwAMQ128uesbk4UOi/XQkqhDwyhW W1SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773761324; x=1774366124; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uyVz1/VY28BNGviPo4SJ7e0WzgpIsIL/HOrakd5K9SA=; b=mAUfW75bxqlufWrid5aUW6vCF9q/wyk5img0CslF8AyK1Lh6Yj3/XEcecyWWvA00k9 bRfcmoFoF74xfsEOsEI0Tr46BjY3ab82eYv8J2PDsvHR9KbkzEGLej2/CyP466Zi4hVQ BJTxVfSO0pOidDnc4pO0UN+Z3ehrE+vtIVt6ZZe7ZaVlYgaKiEKBftaLzTG+0teZhb3d ZvU/2U+0SfSNU9ET154jcxBTK77/gKnuIsYz2mp2VX8YBC9JPL028+mQ1Mzd6H18t8Gl F3iaR4eOhTBWVKMDLsN9R8+oogvzZnBWNG3/nG3DBBJF/Tg33o7Ie6yFTP8lZ6/+cPK4 O9aQ== X-Forwarded-Encrypted: i=1; AJvYcCUKVvvRd6aJkmtxXhZFJRqZgehjhMarSnu5XmZBq2JlFpIbfzcr+sDJ59b0TgoMxcKAxCvjNYX305CI6cg=@vger.kernel.org X-Gm-Message-State: AOJu0Yy5MKarJN1yONKoIuC4vz9MB0B6XOfRh5L3ckS76ryYW7Ym/Aze 0lRuk5R2x3TST++tukSGXgR3+0jrvJcUO/CTBT/llmEPCqsgHwHVXLn4 X-Gm-Gg: ATEYQzxHPwB5K1Ka4a/vU18oELOIHMqywtfTRcZ7W4ue/BbOinWaRS4cWDjHpnfzsHg 0Ch3J3Uree8KA5/Sutb/RO1MhcuM4t/VbdwsGhQDhVdEPN/kR/9vaVBIRZvJxY9F9butDje9w1r YcVW96NNpf06xQgVtoq4x7SUyGRXFeTteaNCuO2EPVpHzPiAt6B9Z20g/610kR2OZ+MVo58+2uo oMCIYP+Mab3SaXnfXfGKVZeobHfGXzXXsutgmkbQlK9eaM6zuRJwlypqDsWazfk8G4ZIIWZQpAy pIK9IndIqpma0j6DHvNutPFpv4t3aOAP7ETQhI9LIx+ZsHCoi1LO9iHu4bKNrQY2QD3aYhZxkja J7M4EBHFolKdsV8Tv5HzCO983sGsJWmdhoK4J/8zpaxqOWdp295mnhtk0bcFS7JygPDhOA8clkb Styq+4FcJCf5w7J2wdxoGNJ+Wc1wHF3Q== X-Received: by 2002:a17:903:1503:b0:2b0:5cac:2a7c with SMTP id d9443c01a7336-2b05cac3114mr40521775ad.8.1773761324515; Tue, 17 Mar 2026 08:28:44 -0700 (PDT) Received: from kt5965-NUC8i3BEH.. ([182.217.14.201]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aece83b35fsm159789725ad.80.2026.03.17.08.28.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 08:28:43 -0700 (PDT) From: kth5965@gmail.com To: Chao Yu , jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net Cc: syzbot+fc026e87558558f75c00@syzkaller.appspotmail.com, linux-kernel@vger.kernel.org Subject: Re: [f2fs-dev] [PATCH v2] f2fs: evict: truncate page cache before clear_inode Date: Wed, 18 Mar 2026 00:28:38 +0900 Message-ID: <20260317152838.26664-1-kth5965@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <9df7bc57-f0e1-4c7b-9ce1-0017eab62c2a@kernel.org> References: <9df7bc57-f0e1-4c7b-9ce1-0017eab62c2a@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Chao, I checked the repro again based on your comment and added some debug logs around the related paths. What I saw was roughly as follows. There was already an abnormal inline state in the read path: inline flag: set data_exist: clear blocks: present This case was not rejected by sanity_check_inode(). From what I saw, the inline sanity check does an early return when inode_has_blocks() is true, so I think this case was skipped there. I think this may also explain why there was no sanity warning in the log. After that, in the eviction path, i_size was already reduced to 0, but f2fs_truncate() still entered the inline conversion path, and f2fs_convert_inline_inode() created folio 0 in the page cache first. Then f2fs_convert_inline_folio() handled the empty inline case as success because of !f2fs_exist_data(inode), and the created folio 0 remained in the page cache. Because of this, nrpages stayed 1 right before clear_inode(). >From this, I think there may be two possible directions for fixing this: 1. prevent folio 0 from being created at all in the empty inline case, or delay folio creation until it is actually needed 2. detect or guard this abnormal inline state earlier, in sanity check or before that stage At this point, both directions seem possible to me. I wanted to ask which direction you think would be more appropriate. If there is anything else I should check, please let me know. Thanks.