From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (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 CCD411552FD for ; Wed, 11 Feb 2026 08:46:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770799575; cv=none; b=hYf9+B2lhR4VECph3/LzU1+uNCQBFbdYTxMRnUUiUU22wnN7o0ICPM/KrRBKkdCrG5sO+DAiYwnM898yKd+cxBF6RBrvlvbpHL+r8INBGH6P6JiP2zzNK9wbyDF56nhLQN0R0irURjT/leDPLS1+tMzKdPeZtUtgfMe/Kyc5kvI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770799575; c=relaxed/simple; bh=AgjiBAL/bB2peoOWXUmxb1cv3G9xR0jZjWZkjeKRZcU=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=jlWwcv2n5dSyDxLFiNDovMZ09clG6A5BdQMa3OJZnWO8kV5DphXRMkkZXcbeefggGQboIsrGRRVENUNU/+aaZOPL25xsqYcIvc/tQsT4aOnTUvdUUVkOLC/TIy001adkLIEOrIAPvirEMAMz98dRJSLtqnfXXI52LLBwFLZ6Rhk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=j8WrBdP/; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="j8WrBdP/" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=qdcNhSHrowEuEYMYv+Z16qnzSkVK1+NEopaQdKqnxDM=; b=j8WrBdP/xe+yMdEgvaZ53beC+xEcFfXFOdoCpGa4QsLJjJg/jjFqb4ND53vskp8qHVpy9gxCi a/Li2K/ndYTAoTUwNAHDmmIAOUDE5klHVS0v8QDk8/Pi7W+KDUb1V2avGsvQ0aNBhxL4IpmE4IZ NselEtgkDUWSOlWWzSFr6Vc= Received: from mail.maildlp.com (unknown [172.19.162.223]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4f9sNT1DkQz1prRB; Wed, 11 Feb 2026 16:41:29 +0800 (CST) Received: from kwepemk500005.china.huawei.com (unknown [7.202.194.90]) by mail.maildlp.com (Postfix) with ESMTPS id F2D4D40561; Wed, 11 Feb 2026 16:46:09 +0800 (CST) Received: from [10.174.178.46] (10.174.178.46) by kwepemk500005.china.huawei.com (7.202.194.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 11 Feb 2026 16:46:08 +0800 Subject: Re: [PATCH] ubifs: prevent corrupted data write via error_remove_folio To: , CC: , , , , , , , References: <20260211154043158VVS6WEc8yD82HcqScmYUn@zte.com.cn> From: Zhihao Cheng Message-ID: Date: Wed, 11 Feb 2026 16:46:07 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20260211154043158VVS6WEc8yD82HcqScmYUn@zte.com.cn> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To kwepemk500005.china.huawei.com (7.202.194.90) 在 2026/2/11 15:40, fan.yu9@zte.com.cn 写道: > From: Jinpeng Cui > > When a memory corruption event triggers memory_failure, ext4 releases references to the affected dirty pages, > ensuring that no corrupted data is written to disk. However, ubifs currently lacks the error_remove_folio capability > and therefore cannot release references to faulty private memory. As a result, corrupted data may eventually be > written to flash storage. > > Add generic_error_remove_folio support to ubifs, preventing corrupted memory data from being persisted to flash. > > Signed-off-by: Jinpeng Cui > Signed-off-by: Fan Yu > Cc: Shengming Hu > --- > fs/ubifs/file.c | 1 + > 1 file changed, 1 insertion(+) > The 'error_remove_folio' was introduced in commit 257187362123f15d9d1("HWPOISON: Define a new error_remove_page address space op for async truncation") to distinguish the error handling behavior beteween metadata page and data page. Files' datapage will be truncated if memory error happens during page copy(eg. migration, mmap_cow). Then several filesystems(with '.migrate_page' implemtented) supportted it. So, I'm fine with this patch. Reviewed-by: Zhihao Cheng > diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c > index 3dc3ca1..34445b7 100644 > --- a/fs/ubifs/file.c > +++ b/fs/ubifs/file.c > @@ -1631,6 +1631,7 @@ static int ubifs_symlink_getattr(struct mnt_idmap *idmap, > .dirty_folio = ubifs_dirty_folio, > .migrate_folio = filemap_migrate_folio, > .release_folio = ubifs_release_folio, > + .error_remove_folio = generic_error_remove_folio, > }; > > const struct inode_operations ubifs_file_inode_operations = { > -- > 1.8.3.1 > . >