From nobody Wed Jun 17 05:12:34 2026 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 2A964DDA9 for ; Tue, 28 Apr 2026 04:50:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777351824; cv=none; b=STCUuBNNgYfB6IaiG9REfpkFf1zusKGI88+qcgRiWCjX9Dgp1zPd0gz378voCeq0CBGqQZHWW4n9C5pPxlUnImz7hiehqt+PIJAsviJMIdZFzmHbrknb/a4tCV1oRJmIkYybH48hFs/+rA5JG7FnqtuD2ptrj5Jh4vNiQvHYNxI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777351824; c=relaxed/simple; bh=PZfBM/RAAiR0DQEga793uYji/UFaLgJj+Yu4RH/5tzY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=iZaYA9WwwoMlkxRuDkM9v/+loPXU5xPTfatw3ebyg5KGKSoU+lt4kbz7ec+lcJJl/RoxsVNsAR6/2BzATRksNyAKCOl2ZPCkgXWd+LCFCN2PBPz/964sx2mbmYazFrCLMng9+muQuRoBcKPEBzbrBL3DPYjX91iO0KRNtGxPJhY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=P4FDTs3/; arc=none smtp.client-ip=115.124.30.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="P4FDTs3/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1777351813; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=1HmIYKms2Pk20pKBvwG8hyZ867nq6aggCBcgiYGDzQM=; b=P4FDTs3/LNJ7BbxCBj5OfsjsHPyDgmxpgwImFR25SSgww12Dw8gGdIIgQb11z75HQ1YfPMYR5+XYYM6LTRvhQfiCvMfPQIylSiYC2EIvucsaMpcpifll2XmImiL20w/ypB1w8ik2NxNQAdF4wUATilTSMCg3thqP9ssllShf24g= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0X1tOy73_1777350872; Received: from x31i01179.sqa.na131.tbsite.net(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X1tOy73_1777350872 cluster:ay36) by smtp.aliyun-inc.com; Tue, 28 Apr 2026 12:34:36 +0800 From: Gao Xiang To: linux-erofs@lists.ozlabs.org Cc: Chao Yu , LKML , kernel@salutedevices.com, Gao Xiang , Arseniy Krasnov Subject: [PATCH] erofs: fix managed cache race for unaligned extents Date: Tue, 28 Apr 2026 12:34:31 +0800 Message-ID: <20260428043431.1883069-1-hsiangkao@linux.alibaba.com> X-Mailer: git-send-email 2.43.5 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" After unaligned compressed extents were introduced, the following race could occur: [Thread 1] [Thread 2] (z_erofs_fill_bio_vec) ... filemap_add_folio (1) (z_erofs_bind_cache) .. .. folio_attach_private (2) filemap_add_folio (3) again Since (1) is executed but (2) hasn't been executed yet, it's possible that another thread finds the same managed folio in z_erofs_bind_cache() for a different pcluster and calls filemap_add_folio() again since folio->private is still Z_EROFS_PREALLOCATED_FOLIO. Fix this by explicitly clearing folio->private before making the folio visible in the managed cache so that another pcluster can simply wait on the locked managed folio as what we did for other shared cases [1]. This only impacts unaligned data compression (`-E48bit` with zstd, for example). [1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of crafted images properly") was originally introduced to handle crafted overlapped extents, but it addresses unaligned extents as well. Fixes: 7361d1e3763b ("erofs: support unaligned encoded data") Reported-by: Arseniy Krasnov Closes: https://lore.kernel.org/r/4a2f3801-fac1-42fe-ae75-da315822e088@salu= tedevices.com Signed-off-by: Gao Xiang Tested-by: Arseniy Krasnov --- fs/erofs/zdata.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c index 8a0b15511931..6b647e75ec04 100644 --- a/fs/erofs/zdata.c +++ b/fs/erofs/zdata.c @@ -1509,8 +1509,15 @@ static void z_erofs_fill_bio_vec(struct bio_vec *bve= c, DBG_BUGON(z_erofs_is_shortlived_page(bvec->bv_page)); =20 folio =3D page_folio(zbv.page); - /* For preallocated managed folios, add them to page cache here */ + /* + * Preallocated folios are added to the managed cache here rather than + * in z_erofs_bind_cache() in order to keep these folios locked in + * increasing (physical) address order. + * Clear folio->private before these folios become visible to others in + * the managed cache to avoid duplicate additions for unaligned extents. + */ if (folio->private =3D=3D Z_EROFS_PREALLOCATED_FOLIO) { + folio->private =3D NULL; tocache =3D true; goto out_tocache; } @@ -1546,14 +1553,8 @@ static void z_erofs_fill_bio_vec(struct bio_vec *bve= c, } return; } - /* - * Already linked with another pcluster, which only appears in - * crafted images by fuzzers for now. But handle this anyway. - */ - tocache =3D false; /* use temporary short-lived pages */ } else { DBG_BUGON(1); /* referenced managed folios can't be truncated */ - tocache =3D true; } folio_unlock(folio); folio_put(folio); --=20 2.43.5