From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: kbuild@lists.01.org, lkp@intel.com, linux-erofs@lists.ozlabs.org,
kbuild-all@lists.01.org, linux-kernel@vger.kernel.org
Subject: Re: fs/erofs/zmap.c:394 z_erofs_get_extent_compressedlen() warn: should '1 << lclusterbits' be a 64 bit type?
Date: Wed, 9 Mar 2022 19:15:36 +0800 [thread overview]
Message-ID: <YiiMWCZS7bzeAFme@B-P7TQMD6M-0146.local> (raw)
In-Reply-To: <202203091002.lJVzsX6e-lkp@intel.com>
Hi Dan,
On Wed, Mar 09, 2022 at 01:27:08PM +0300, Dan Carpenter wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 92f90cc9fe0e7a984ea3d4bf3d120e30ba8a2118
> commit: cec6e93beadfd145758af2c0854fcc2abb8170cb erofs: support parsing big pcluster compress indexes
> config: i386-randconfig-m021-20220307 (https://download.01.org/0day-ci/archive/20220309/202203091002.lJVzsX6e-lkp@intel.com/config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> smatch warnings:
> fs/erofs/zmap.c:394 z_erofs_get_extent_compressedlen() warn: should '1 << lclusterbits' be a 64 bit type?
> fs/erofs/zmap.c:423 z_erofs_get_extent_compressedlen() warn: should 'm->compressedlcs << lclusterbits' be a 64 bit type?
>
> vim +394 fs/erofs/zmap.c
>
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 381 static int z_erofs_get_extent_compressedlen(struct z_erofs_maprecorder *m,
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 382 unsigned int initial_lcn)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 383 {
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 384 struct erofs_inode *const vi = EROFS_I(m->inode);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 385 struct erofs_map_blocks *const map = m->map;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 386 const unsigned int lclusterbits = vi->z_logical_clusterbits;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 387 unsigned long lcn;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 388 int err;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 389
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 390 DBG_BUGON(m->type != Z_EROFS_VLE_CLUSTER_TYPE_PLAIN &&
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 391 m->type != Z_EROFS_VLE_CLUSTER_TYPE_HEAD);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 392 if (!(map->m_flags & EROFS_MAP_ZIPPED) ||
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 393 !(vi->z_advise & Z_EROFS_ADVISE_BIG_PCLUSTER_1)) {
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 @394 map->m_plen = 1 << lclusterbits;
>
> 1ULL << lclusterbits?
Thanks for the report!
In practice, m_plen won't be larger than 1MiB due to on-disk constraint
for compression mode, so we're always safe here. m_plen only can be
larger than 4GiB for non-compression mode.
Yet we could update this on the static analysis side, I will submit a
patch later.
>
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 395 return 0;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 396 }
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 397
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 398 lcn = m->lcn + 1;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 399 if (m->compressedlcs)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 400 goto out;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 401 if (lcn == initial_lcn)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 402 goto err_bonus_cblkcnt;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 403
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 404 err = z_erofs_load_cluster_from_disk(m, lcn);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 405 if (err)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 406 return err;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 407
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 408 switch (m->type) {
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 409 case Z_EROFS_VLE_CLUSTER_TYPE_NONHEAD:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 410 if (m->delta[0] != 1)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 411 goto err_bonus_cblkcnt;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 412 if (m->compressedlcs)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 413 break;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 414 fallthrough;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 415 default:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 416 erofs_err(m->inode->i_sb,
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 417 "cannot found CBLKCNT @ lcn %lu of nid %llu",
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 418 lcn, vi->nid);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 419 DBG_BUGON(1);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 420 return -EFSCORRUPTED;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 421 }
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 422 out:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 @423 map->m_plen = m->compressedlcs << lclusterbits;
>
> Same thing here.
Ditto.
Thanks,
Gao Xiang
>
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 424 return 0;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 425 err_bonus_cblkcnt:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 426 erofs_err(m->inode->i_sb,
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 427 "bogus CBLKCNT @ lcn %lu of nid %llu",
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 428 lcn, vi->nid);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 429 DBG_BUGON(1);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 430 return -EFSCORRUPTED;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 431 }
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: kbuild-all@lists.01.org, kbuild@lists.01.org,
linux-erofs@lists.ozlabs.org, lkp@intel.com,
linux-kernel@vger.kernel.org
Subject: Re: fs/erofs/zmap.c:394 z_erofs_get_extent_compressedlen() warn: should '1 << lclusterbits' be a 64 bit type?
Date: Wed, 9 Mar 2022 19:15:36 +0800 [thread overview]
Message-ID: <YiiMWCZS7bzeAFme@B-P7TQMD6M-0146.local> (raw)
In-Reply-To: <202203091002.lJVzsX6e-lkp@intel.com>
Hi Dan,
On Wed, Mar 09, 2022 at 01:27:08PM +0300, Dan Carpenter wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 92f90cc9fe0e7a984ea3d4bf3d120e30ba8a2118
> commit: cec6e93beadfd145758af2c0854fcc2abb8170cb erofs: support parsing big pcluster compress indexes
> config: i386-randconfig-m021-20220307 (https://download.01.org/0day-ci/archive/20220309/202203091002.lJVzsX6e-lkp@intel.com/config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> smatch warnings:
> fs/erofs/zmap.c:394 z_erofs_get_extent_compressedlen() warn: should '1 << lclusterbits' be a 64 bit type?
> fs/erofs/zmap.c:423 z_erofs_get_extent_compressedlen() warn: should 'm->compressedlcs << lclusterbits' be a 64 bit type?
>
> vim +394 fs/erofs/zmap.c
>
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 381 static int z_erofs_get_extent_compressedlen(struct z_erofs_maprecorder *m,
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 382 unsigned int initial_lcn)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 383 {
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 384 struct erofs_inode *const vi = EROFS_I(m->inode);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 385 struct erofs_map_blocks *const map = m->map;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 386 const unsigned int lclusterbits = vi->z_logical_clusterbits;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 387 unsigned long lcn;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 388 int err;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 389
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 390 DBG_BUGON(m->type != Z_EROFS_VLE_CLUSTER_TYPE_PLAIN &&
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 391 m->type != Z_EROFS_VLE_CLUSTER_TYPE_HEAD);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 392 if (!(map->m_flags & EROFS_MAP_ZIPPED) ||
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 393 !(vi->z_advise & Z_EROFS_ADVISE_BIG_PCLUSTER_1)) {
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 @394 map->m_plen = 1 << lclusterbits;
>
> 1ULL << lclusterbits?
Thanks for the report!
In practice, m_plen won't be larger than 1MiB due to on-disk constraint
for compression mode, so we're always safe here. m_plen only can be
larger than 4GiB for non-compression mode.
Yet we could update this on the static analysis side, I will submit a
patch later.
>
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 395 return 0;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 396 }
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 397
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 398 lcn = m->lcn + 1;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 399 if (m->compressedlcs)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 400 goto out;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 401 if (lcn == initial_lcn)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 402 goto err_bonus_cblkcnt;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 403
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 404 err = z_erofs_load_cluster_from_disk(m, lcn);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 405 if (err)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 406 return err;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 407
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 408 switch (m->type) {
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 409 case Z_EROFS_VLE_CLUSTER_TYPE_NONHEAD:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 410 if (m->delta[0] != 1)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 411 goto err_bonus_cblkcnt;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 412 if (m->compressedlcs)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 413 break;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 414 fallthrough;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 415 default:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 416 erofs_err(m->inode->i_sb,
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 417 "cannot found CBLKCNT @ lcn %lu of nid %llu",
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 418 lcn, vi->nid);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 419 DBG_BUGON(1);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 420 return -EFSCORRUPTED;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 421 }
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 422 out:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 @423 map->m_plen = m->compressedlcs << lclusterbits;
>
> Same thing here.
Ditto.
Thanks,
Gao Xiang
>
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 424 return 0;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 425 err_bonus_cblkcnt:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 426 erofs_err(m->inode->i_sb,
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 427 "bogus CBLKCNT @ lcn %lu of nid %llu",
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 428 lcn, vi->nid);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 429 DBG_BUGON(1);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 430 return -EFSCORRUPTED;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 431 }
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: kbuild-all@lists.01.org
Subject: Re: fs/erofs/zmap.c:394 z_erofs_get_extent_compressedlen() warn: should '1 << lclusterbits' be a 64 bit type?
Date: Wed, 09 Mar 2022 19:15:36 +0800 [thread overview]
Message-ID: <YiiMWCZS7bzeAFme@B-P7TQMD6M-0146.local> (raw)
In-Reply-To: <202203091002.lJVzsX6e-lkp@intel.com>
[-- Attachment #1: Type: text/plain, Size: 6526 bytes --]
Hi Dan,
On Wed, Mar 09, 2022 at 01:27:08PM +0300, Dan Carpenter wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 92f90cc9fe0e7a984ea3d4bf3d120e30ba8a2118
> commit: cec6e93beadfd145758af2c0854fcc2abb8170cb erofs: support parsing big pcluster compress indexes
> config: i386-randconfig-m021-20220307 (https://download.01.org/0day-ci/archive/20220309/202203091002.lJVzsX6e-lkp(a)intel.com/config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> smatch warnings:
> fs/erofs/zmap.c:394 z_erofs_get_extent_compressedlen() warn: should '1 << lclusterbits' be a 64 bit type?
> fs/erofs/zmap.c:423 z_erofs_get_extent_compressedlen() warn: should 'm->compressedlcs << lclusterbits' be a 64 bit type?
>
> vim +394 fs/erofs/zmap.c
>
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 381 static int z_erofs_get_extent_compressedlen(struct z_erofs_maprecorder *m,
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 382 unsigned int initial_lcn)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 383 {
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 384 struct erofs_inode *const vi = EROFS_I(m->inode);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 385 struct erofs_map_blocks *const map = m->map;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 386 const unsigned int lclusterbits = vi->z_logical_clusterbits;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 387 unsigned long lcn;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 388 int err;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 389
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 390 DBG_BUGON(m->type != Z_EROFS_VLE_CLUSTER_TYPE_PLAIN &&
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 391 m->type != Z_EROFS_VLE_CLUSTER_TYPE_HEAD);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 392 if (!(map->m_flags & EROFS_MAP_ZIPPED) ||
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 393 !(vi->z_advise & Z_EROFS_ADVISE_BIG_PCLUSTER_1)) {
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 @394 map->m_plen = 1 << lclusterbits;
>
> 1ULL << lclusterbits?
Thanks for the report!
In practice, m_plen won't be larger than 1MiB due to on-disk constraint
for compression mode, so we're always safe here. m_plen only can be
larger than 4GiB for non-compression mode.
Yet we could update this on the static analysis side, I will submit a
patch later.
>
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 395 return 0;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 396 }
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 397
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 398 lcn = m->lcn + 1;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 399 if (m->compressedlcs)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 400 goto out;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 401 if (lcn == initial_lcn)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 402 goto err_bonus_cblkcnt;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 403
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 404 err = z_erofs_load_cluster_from_disk(m, lcn);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 405 if (err)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 406 return err;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 407
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 408 switch (m->type) {
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 409 case Z_EROFS_VLE_CLUSTER_TYPE_NONHEAD:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 410 if (m->delta[0] != 1)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 411 goto err_bonus_cblkcnt;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 412 if (m->compressedlcs)
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 413 break;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 414 fallthrough;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 415 default:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 416 erofs_err(m->inode->i_sb,
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 417 "cannot found CBLKCNT @ lcn %lu of nid %llu",
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 418 lcn, vi->nid);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 419 DBG_BUGON(1);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 420 return -EFSCORRUPTED;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 421 }
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 422 out:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 @423 map->m_plen = m->compressedlcs << lclusterbits;
>
> Same thing here.
Ditto.
Thanks,
Gao Xiang
>
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 424 return 0;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 425 err_bonus_cblkcnt:
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 426 erofs_err(m->inode->i_sb,
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 427 "bogus CBLKCNT @ lcn %lu of nid %llu",
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 428 lcn, vi->nid);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 429 DBG_BUGON(1);
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 430 return -EFSCORRUPTED;
> cec6e93beadfd1 fs/erofs/zmap.c Gao Xiang 2021-04-07 431 }
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
>
next prev parent reply other threads:[~2022-03-09 11:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 2:24 fs/erofs/zmap.c:394 z_erofs_get_extent_compressedlen() warn: should '1 << lclusterbits' be a 64 bit type? kernel test robot
2022-03-09 10:27 ` Dan Carpenter
2022-03-09 10:27 ` Dan Carpenter
2022-03-09 11:15 ` Gao Xiang [this message]
2022-03-09 11:15 ` Gao Xiang
2022-03-09 11:15 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YiiMWCZS7bzeAFme@B-P7TQMD6M-0146.local \
--to=hsiangkao@linux.alibaba.com \
--cc=dan.carpenter@oracle.com \
--cc=kbuild-all@lists.01.org \
--cc=kbuild@lists.01.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.