Message ID | 20230719065459.60083-1-hsiangkao@linux.alibaba.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp2251922vqt; Wed, 19 Jul 2023 00:09:17 -0700 (PDT) X-Google-Smtp-Source: APBJJlHnrKL26PijFqNOgwbjf9TVQv+UoX6SYZ0ICBSqRNDZKErC337+Axo8bgKFFbon2kE+KmuJ X-Received: by 2002:a05:6830:1d75:b0:6b9:5810:84d2 with SMTP id l21-20020a0568301d7500b006b9581084d2mr16031728oti.6.1689750557416; Wed, 19 Jul 2023 00:09:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689750557; cv=none; d=google.com; s=arc-20160816; b=E7wtegHpZjhoBKdoTZguKbAr3AgAARRCBV3H7lk6s0HEt8A8pCPJTapz+uhay01YAu rClj5cqESQ9koQ6HEA3Ze/s3ehbvzjwHRJT6cW2UJLq0oJC3TH0bUupvpSruaGnIfhge a/agoXAv4D40CoP3F1Kuk6MQnpNFqkYQzCoUI+gLgVx3cJg8ZcjDoAMT5laXt94KeMVz 7uL1zsxdXzV/3QIjFPtBPCZXnuiQgwzUlcEJf5oZTmGNBer2ayMNm6Rnn/3y3ROk+d4I 1qzUVRFDGH09WVSYFuwTl55UNqN8+LG2EmsP7tQ3USemYjtsVYfhjwGB0+6dTGGlKqK/ Ml+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=zFj3qOYbdoEzV/7Ujma/NB8x+JG2bWeFKxjOMsqDpn8=; fh=vDNCtZfonx9omdPo5qwADj/ZvTphBKnKtHtK5q954Ds=; b=NTCRjbxPFH+lMaRK3LpLN3BYz44kTZPxBjKgffo3kYJMaJjGjaeIPd2U4AQ3XEiKXu vyMtKHhUeFtKLkvSCgu6GPy/H8bbKyR7MO9KarcLU6dAhYdXd4qkI6cNSyax4KgMag9R mko6vO9uqxiXkOb1WWTPsC+qbY6Q4wJvMo59eXsi4TuUkR6DV55NuscJQh0jVaWxOURO wsx/ix7rx1VowYbYeDInxNNxY2/T8kyaBcqwEbevDv+LhmJrHlXwEzI7oaP2K6VpQjck uPKrMu55O/J/5d172cObTrzSQe1/a354d0Srwfd8364MoFVC25kVST5jxc1xr7zl7KEz sz3g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 31-20020a63155f000000b00553e8d95742si2968337pgv.654.2023.07.19.00.09.04; Wed, 19 Jul 2023 00:09:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231205AbjGSGzN (ORCPT <rfc822;chrisben.tianve@gmail.com> + 99 others); Wed, 19 Jul 2023 02:55:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229590AbjGSGzK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Jul 2023 02:55:10 -0400 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 105B61BFC for <linux-kernel@vger.kernel.org>; Tue, 18 Jul 2023 23:55:08 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045170;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=4;SR=0;TI=SMTPD_---0Vnkhvgd_1689749700; Received: from e18g06460.et15sqa.tbsite.net(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0Vnkhvgd_1689749700) by smtp.aliyun-inc.com; Wed, 19 Jul 2023 14:55:06 +0800 From: Gao Xiang <hsiangkao@linux.alibaba.com> To: linux-erofs@lists.ozlabs.org Cc: LKML <linux-kernel@vger.kernel.org>, Gao Xiang <hsiangkao@linux.alibaba.com>, Shijie Sun <sunshijie@xiaomi.com> Subject: [PATCH] erofs: fix wrong primary bvec selection on deduplicated extents Date: Wed, 19 Jul 2023 14:54:59 +0800 Message-Id: <20230719065459.60083-1-hsiangkao@linux.alibaba.com> X-Mailer: git-send-email 2.24.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771831880718391808 X-GMAIL-MSGID: 1771831880718391808 |
Series |
erofs: fix wrong primary bvec selection on deduplicated extents
|
|
Commit Message
Gao Xiang
July 19, 2023, 6:54 a.m. UTC
When handling deduplicated compressed data, there can be multiple
decompressed extents pointing to the same compressed data in one shot.
In such cases, the bvecs which belong to the longest extent will be
selected as the primary bvecs for real decompressors to decode and the
other duplicated bvecs will be directly copied from the primary bvecs.
Previously, only relative offsets of the longest extent was checked to
decompress the primary bvecs. On rare occasions, it can be incorrect
if there are several extents with the same start relative offset.
As a result, some short bvecs could be selected for decompression and
then cause data corruption.
For example, as Shijie Sun reported off-list, considering the following
extents of a file:
117: 903345.. 915250 | 11905 : 385024.. 389120 | 4096
...
119: 919729.. 930323 | 10594 : 385024.. 389120 | 4096
...
124: 968881.. 980786 | 11905 : 385024.. 389120 | 4096
The start relative offset is the same: 2225, but extent 119 (919729..
930323) is shorter than the others.
Let's restrict the bvec length in addition to the start offset if bvecs
are not full.
Reported-by: Shijie Sun <sunshijie@xiaomi.com>
Fixes: 5c2a64252c5d ("erofs: introduce partial-referenced pclusters")
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
---
fs/erofs/zdata.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Comments
On Wed, 19 Jul 2023 14:54:59 +0800 Gao Xiang <hsiangkao@linux.alibaba.com> wrote: > When handling deduplicated compressed data, there can be multiple > decompressed extents pointing to the same compressed data in one shot. > > In such cases, the bvecs which belong to the longest extent will be > selected as the primary bvecs for real decompressors to decode and the > other duplicated bvecs will be directly copied from the primary bvecs. > > Previously, only relative offsets of the longest extent was checked to > decompress the primary bvecs. On rare occasions, it can be incorrect > if there are several extents with the same start relative offset. > As a result, some short bvecs could be selected for decompression and > then cause data corruption. > > For example, as Shijie Sun reported off-list, considering the following > extents of a file: > 117: 903345.. 915250 | 11905 : 385024.. 389120 | 4096 > ... > 119: 919729.. 930323 | 10594 : 385024.. 389120 | 4096 > ... > 124: 968881.. 980786 | 11905 : 385024.. 389120 | 4096 > > The start relative offset is the same: 2225, but extent 119 (919729.. > 930323) is shorter than the others. > > Let's restrict the bvec length in addition to the start offset if bvecs > are not full. > > Reported-by: Shijie Sun <sunshijie@xiaomi.com> > Fixes: 5c2a64252c5d ("erofs: introduce partial-referenced pclusters") > Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Yue Hu <huyue2@coolpad.com>
On 2023/7/19 14:54, Gao Xiang wrote: > When handling deduplicated compressed data, there can be multiple > decompressed extents pointing to the same compressed data in one shot. > > In such cases, the bvecs which belong to the longest extent will be > selected as the primary bvecs for real decompressors to decode and the > other duplicated bvecs will be directly copied from the primary bvecs. > > Previously, only relative offsets of the longest extent was checked to > decompress the primary bvecs. On rare occasions, it can be incorrect > if there are several extents with the same start relative offset. > As a result, some short bvecs could be selected for decompression and > then cause data corruption. > > For example, as Shijie Sun reported off-list, considering the following > extents of a file: > 117: 903345.. 915250 | 11905 : 385024.. 389120 | 4096 > ... > 119: 919729.. 930323 | 10594 : 385024.. 389120 | 4096 > ... > 124: 968881.. 980786 | 11905 : 385024.. 389120 | 4096 > > The start relative offset is the same: 2225, but extent 119 (919729.. > 930323) is shorter than the others. > > Let's restrict the bvec length in addition to the start offset if bvecs > are not full. > > Reported-by: Shijie Sun <sunshijie@xiaomi.com> > Fixes: 5c2a64252c5d ("erofs: introduce partial-referenced pclusters") > Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Chao Yu <chao@kernel.org> Thanks,
diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c index b69d89a11dd0..de4f12152b62 100644 --- a/fs/erofs/zdata.c +++ b/fs/erofs/zdata.c @@ -1144,10 +1144,11 @@ static void z_erofs_do_decompressed_bvec(struct z_erofs_decompress_backend *be, struct z_erofs_bvec *bvec) { struct z_erofs_bvec_item *item; + unsigned int pgnr; - if (!((bvec->offset + be->pcl->pageofs_out) & ~PAGE_MASK)) { - unsigned int pgnr; - + if (!((bvec->offset + be->pcl->pageofs_out) & ~PAGE_MASK) && + (bvec->end == PAGE_SIZE || + bvec->offset + bvec->end == be->pcl->length)) { pgnr = (bvec->offset + be->pcl->pageofs_out) >> PAGE_SHIFT; DBG_BUGON(pgnr >= be->nr_pages); if (!be->decompressed_pages[pgnr]) {