subject:"bug report"

Re: [bug report] btrfs: add helper function check device delete able

2018-07-20 Thread Anand Jain




Noted. Thanks Dan.

-Anand

On 07/19/2018 04:10 PM, Dan Carpenter wrote:

Hello Anand Jain,

The patch a6500c9ef8ac: "btrfs: add helper function check device
delete able" from Jul 10, 2018, leads to the following static checker
warning:

fs/btrfs/volumes.c:1871 btrfs_device_delete_able()
error: passing non negative 4 to ERR_PTR

fs/btrfs/volumes.c:1876 btrfs_device_delete_able()
error: passing non negative 6 to ERR_PTR

fs/btrfs/volumes.c:1879 btrfs_device_delete_able()
error: passing non negative 5 to ERR_PTR

fs/btrfs/volumes.c:1883 btrfs_device_delete_able()
error: passing non negative 7 to ERR_PTR

fs/btrfs/volumes.c
   1861  static struct btrfs_device *btrfs_device_delete_able(
   1862  struct btrfs_fs_info *fs_info,
   1863  const char *device_path, u64 devid)
   1864  {
   1865  int ret;
   1866  struct btrfs_device *device;
   1867
   1868  ret = btrfs_check_raid_min_devices(fs_info,
   1869 btrfs_num_devices(fs_info) 
- 1);
   1870  if (ret)
   1871  return ERR_PTR(ret);
^^^
This is a btrfs_err_code enum, not a negative error code.  It leads to
a NULL dereference in the caller.

   1872
   1873  ret = btrfs_find_device_by_devspec(fs_info, devid, device_path,
   1874 );
   1875  if (ret)
   1876  return ERR_PTR(ret);
^^^
   1877
   1878  if (test_bit(BTRFS_DEV_STATE_REPLACE_TGT, >dev_state))
   1879  return ERR_PTR(BTRFS_ERROR_DEV_TGT_REPLACE);
^^^
Same only even more so.

   1880
   1881  if (test_bit(BTRFS_DEV_STATE_WRITEABLE, >dev_state) &&
   1882  fs_info->fs_devices->rw_devices == 1)
   1883  return ERR_PTR(BTRFS_ERROR_DEV_ONLY_WRITABLE);
^
   1884
   1885  return device;
   1886  }

See also:

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [bug report] btrfs: Add type check when reading a chunk

2018-07-19 Thread Gu, Jinxiang



> -Original Message-
> From: David Sterba [mailto:dste...@suse.cz]
> Sent: Thursday, July 19, 2018 6:14 PM
> To: dste...@suse.cz; Gu, Jinxiang/顾 金香 ; Dan Carpenter 
> ;
> linux-btrfs@vger.kernel.org
> Subject: Re: [bug report] btrfs: Add type check when reading a chunk
> 
> On Thu, Jul 19, 2018 at 11:22:01AM +0200, David Sterba wrote:
> > On Thu, Jul 19, 2018 at 08:18:25AM +, Gu, Jinxiang wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > > > Sent: Thursday, July 19, 2018 4:11 PM
> > > > To: Gu, Jinxiang/顾 金香 
> > > > Cc: linux-btrfs@vger.kernel.org
> > > > Subject: [bug report] btrfs: Add type check when reading a chunk
> > > >
> > > > Hello Gu Jinxiang,
> > > >
> > > > The patch 72e75ed03c8d: "btrfs: Add type check when reading a chunk"
> > > > from Jul 4, 2018, leads to the following static checker warning:
> > > >
> > > > fs/btrfs/volumes.c:6388 btrfs_check_chunk_valid()
> > > > warn: AND to zero '0x4 & 0x1'
> > > >
> > > > fs/btrfs/volumes.c
> > > >   6356  if (!is_power_of_2(stripe_len) || stripe_len != 
> > > > BTRFS_STRIPE_LEN) {
> > > >   6357  btrfs_err(fs_info, "invalid chunk stripe 
> > > > length: %llu",
> > > >   6358stripe_len);
> > > >   6359  return -EIO;
> > > >   6360  }
> > > >   6361  if (~(BTRFS_BLOCK_GROUP_TYPE_MASK | 
> > > > BTRFS_BLOCK_GROUP_PROFILE_MASK) &
> > > >   6362  type) {
> > > >   6363  btrfs_err(fs_info, "unrecognized chunk type: 
> > > > %llu",
> > > >   6364~(BTRFS_BLOCK_GROUP_TYPE_MASK |
> > > >   6365  BTRFS_BLOCK_GROUP_PROFILE_MASK) &
> > > >   6366btrfs_chunk_type(leaf, chunk));
> > > >   6367  return -EIO;
> > > >   6368  }
> > > >   6369
> > > >   6370  if ((type & BTRFS_BLOCK_GROUP_TYPE_MASK) == 0) {
> > > >   6371  btrfs_err(fs_info, "missing chunk type flag: 
> > > > %llu", type);
> > > >   6372  return -EIO;
> > > >   6373  }
> > > >   6374
> > > >   6375  if ((type & BTRFS_BLOCK_GROUP_SYSTEM) &&
> > > >   6376  (type & (BTRFS_BLOCK_GROUP_METADATA | 
> > > > BTRFS_BLOCK_GROUP_DATA))) {
> > > >   6377  btrfs_err(fs_info,
> > > >   6378  "system chunk with data or metadata 
> > > > type: %llu", type);
> > > >   6379  return -EIO;
> > > >   6380  }
> > > >   6381
> > > >   6382  features = 
> > > > btrfs_super_incompat_flags(fs_info->super_copy);
> > > >   6383  if (features & BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS)
> > > >   6384  mixed = 1;
> > > >   6385
> > > >   6386  if (!mixed) {
> > > >   6387  if (type &
> > > >   6388  (BTRFS_BLOCK_GROUP_METADATA & 
> > > > BTRFS_BLOCK_GROUP_DATA)) {
> > > >  
> > > > ^^^
> > > > Was this supposed to be | or perhaps check that both are set?
> > > Yes. It should be |.
> > > Thank you, I'll send a patch to fix it.
> >
> > Not needed, I'll fix the patch directly.
> 
> And that leads to failed mount:
> 
> [   10.867868] BTRFS error (device vda): mixed chunk type in non-mixed mode: 1
> [   10.871084] BTRFS error (device vda): failed to read chunk tree: -5
> [   10.908541] BTRFS error (device vda): open_ctree failed
> 
> Please send fixed version.

I send a patch to fix this.
Patch: btrfs: fix bug of chunk type check
And, if possible, please just fold it into 72e75ed03c8d: "btrfs: Add type check 
when reading a chunk".

Thanks, Gu Jinxiang

>

Re: [bug report] btrfs: Add type check when reading a chunk

2018-07-19 Thread David Sterba

On Thu, Jul 19, 2018 at 11:22:01AM +0200, David Sterba wrote:
> On Thu, Jul 19, 2018 at 08:18:25AM +, Gu, Jinxiang wrote:
> > 
> > 
> > > -Original Message-
> > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > > Sent: Thursday, July 19, 2018 4:11 PM
> > > To: Gu, Jinxiang/顾 金香 
> > > Cc: linux-btrfs@vger.kernel.org
> > > Subject: [bug report] btrfs: Add type check when reading a chunk
> > > 
> > > Hello Gu Jinxiang,
> > > 
> > > The patch 72e75ed03c8d: "btrfs: Add type check when reading a chunk"
> > > from Jul 4, 2018, leads to the following static checker warning:
> > > 
> > >   fs/btrfs/volumes.c:6388 btrfs_check_chunk_valid()
> > >   warn: AND to zero '0x4 & 0x1'
> > > 
> > > fs/btrfs/volumes.c
> > >   6356  if (!is_power_of_2(stripe_len) || stripe_len != 
> > > BTRFS_STRIPE_LEN) {
> > >   6357  btrfs_err(fs_info, "invalid chunk stripe length: 
> > > %llu",
> > >   6358stripe_len);
> > >   6359  return -EIO;
> > >   6360  }
> > >   6361  if (~(BTRFS_BLOCK_GROUP_TYPE_MASK | 
> > > BTRFS_BLOCK_GROUP_PROFILE_MASK) &
> > >   6362  type) {
> > >   6363  btrfs_err(fs_info, "unrecognized chunk type: 
> > > %llu",
> > >   6364~(BTRFS_BLOCK_GROUP_TYPE_MASK |
> > >   6365  BTRFS_BLOCK_GROUP_PROFILE_MASK) &
> > >   6366btrfs_chunk_type(leaf, chunk));
> > >   6367  return -EIO;
> > >   6368  }
> > >   6369
> > >   6370  if ((type & BTRFS_BLOCK_GROUP_TYPE_MASK) == 0) {
> > >   6371  btrfs_err(fs_info, "missing chunk type flag: 
> > > %llu", type);
> > >   6372  return -EIO;
> > >   6373  }
> > >   6374
> > >   6375  if ((type & BTRFS_BLOCK_GROUP_SYSTEM) &&
> > >   6376  (type & (BTRFS_BLOCK_GROUP_METADATA | 
> > > BTRFS_BLOCK_GROUP_DATA))) {
> > >   6377  btrfs_err(fs_info,
> > >   6378  "system chunk with data or metadata type: 
> > > %llu", type);
> > >   6379  return -EIO;
> > >   6380  }
> > >   6381
> > >   6382  features = 
> > > btrfs_super_incompat_flags(fs_info->super_copy);
> > >   6383  if (features & BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS)
> > >   6384  mixed = 1;
> > >   6385
> > >   6386  if (!mixed) {
> > >   6387  if (type &
> > >   6388  (BTRFS_BLOCK_GROUP_METADATA & 
> > > BTRFS_BLOCK_GROUP_DATA)) {
> > >  
> > > ^^^
> > > Was this supposed to be | or perhaps check that both are set?
> > Yes. It should be |.
> > Thank you, I'll send a patch to fix it.
> 
> Not needed, I'll fix the patch directly.

And that leads to failed mount:

[   10.867868] BTRFS error (device vda): mixed chunk type in non-mixed mode: 1
[   10.871084] BTRFS error (device vda): failed to read chunk tree: -5
[   10.908541] BTRFS error (device vda): open_ctree failed

Please send fixed version.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [bug report] btrfs: Add type check when reading a chunk

2018-07-19 Thread David Sterba

On Thu, Jul 19, 2018 at 08:18:25AM +, Gu, Jinxiang wrote:
> 
> 
> > -Original Message-
> > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > Sent: Thursday, July 19, 2018 4:11 PM
> > To: Gu, Jinxiang/顾 金香 
> > Cc: linux-btrfs@vger.kernel.org
> > Subject: [bug report] btrfs: Add type check when reading a chunk
> > 
> > Hello Gu Jinxiang,
> > 
> > The patch 72e75ed03c8d: "btrfs: Add type check when reading a chunk"
> > from Jul 4, 2018, leads to the following static checker warning:
> > 
> > fs/btrfs/volumes.c:6388 btrfs_check_chunk_valid()
> > warn: AND to zero '0x4 & 0x1'
> > 
> > fs/btrfs/volumes.c
> >   6356  if (!is_power_of_2(stripe_len) || stripe_len != 
> > BTRFS_STRIPE_LEN) {
> >   6357  btrfs_err(fs_info, "invalid chunk stripe length: 
> > %llu",
> >   6358stripe_len);
> >   6359  return -EIO;
> >   6360  }
> >   6361  if (~(BTRFS_BLOCK_GROUP_TYPE_MASK | 
> > BTRFS_BLOCK_GROUP_PROFILE_MASK) &
> >   6362  type) {
> >   6363  btrfs_err(fs_info, "unrecognized chunk type: %llu",
> >   6364~(BTRFS_BLOCK_GROUP_TYPE_MASK |
> >   6365  BTRFS_BLOCK_GROUP_PROFILE_MASK) &
> >   6366btrfs_chunk_type(leaf, chunk));
> >   6367  return -EIO;
> >   6368  }
> >   6369
> >   6370  if ((type & BTRFS_BLOCK_GROUP_TYPE_MASK) == 0) {
> >   6371  btrfs_err(fs_info, "missing chunk type flag: %llu", 
> > type);
> >   6372  return -EIO;
> >   6373  }
> >   6374
> >   6375  if ((type & BTRFS_BLOCK_GROUP_SYSTEM) &&
> >   6376  (type & (BTRFS_BLOCK_GROUP_METADATA | 
> > BTRFS_BLOCK_GROUP_DATA))) {
> >   6377  btrfs_err(fs_info,
> >   6378  "system chunk with data or metadata type: 
> > %llu", type);
> >   6379  return -EIO;
> >   6380  }
> >   6381
> >   6382  features = btrfs_super_incompat_flags(fs_info->super_copy);
> >   6383  if (features & BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS)
> >   6384  mixed = 1;
> >   6385
> >   6386  if (!mixed) {
> >   6387  if (type &
> >   6388  (BTRFS_BLOCK_GROUP_METADATA & 
> > BTRFS_BLOCK_GROUP_DATA)) {
> >  
> > ^^^
> > Was this supposed to be | or perhaps check that both are set?
> Yes. It should be |.
> Thank you, I'll send a patch to fix it.

Not needed, I'll fix the patch directly.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [bug report] btrfs: Add type check when reading a chunk

2018-07-19 Thread Gu, Jinxiang



> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Thursday, July 19, 2018 4:11 PM
> To: Gu, Jinxiang/顾 金香 
> Cc: linux-btrfs@vger.kernel.org
> Subject: [bug report] btrfs: Add type check when reading a chunk
> 
> Hello Gu Jinxiang,
> 
> The patch 72e75ed03c8d: "btrfs: Add type check when reading a chunk"
> from Jul 4, 2018, leads to the following static checker warning:
> 
>   fs/btrfs/volumes.c:6388 btrfs_check_chunk_valid()
>   warn: AND to zero '0x4 & 0x1'
> 
> fs/btrfs/volumes.c
>   6356  if (!is_power_of_2(stripe_len) || stripe_len != 
> BTRFS_STRIPE_LEN) {
>   6357  btrfs_err(fs_info, "invalid chunk stripe length: 
> %llu",
>   6358stripe_len);
>   6359  return -EIO;
>   6360  }
>   6361  if (~(BTRFS_BLOCK_GROUP_TYPE_MASK | 
> BTRFS_BLOCK_GROUP_PROFILE_MASK) &
>   6362  type) {
>   6363  btrfs_err(fs_info, "unrecognized chunk type: %llu",
>   6364~(BTRFS_BLOCK_GROUP_TYPE_MASK |
>   6365  BTRFS_BLOCK_GROUP_PROFILE_MASK) &
>   6366btrfs_chunk_type(leaf, chunk));
>   6367  return -EIO;
>   6368  }
>   6369
>   6370  if ((type & BTRFS_BLOCK_GROUP_TYPE_MASK) == 0) {
>   6371  btrfs_err(fs_info, "missing chunk type flag: %llu", 
> type);
>   6372  return -EIO;
>   6373  }
>   6374
>   6375  if ((type & BTRFS_BLOCK_GROUP_SYSTEM) &&
>   6376  (type & (BTRFS_BLOCK_GROUP_METADATA | 
> BTRFS_BLOCK_GROUP_DATA))) {
>   6377  btrfs_err(fs_info,
>   6378  "system chunk with data or metadata type: 
> %llu", type);
>   6379  return -EIO;
>   6380  }
>   6381
>   6382  features = btrfs_super_incompat_flags(fs_info->super_copy);
>   6383  if (features & BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS)
>   6384  mixed = 1;
>   6385
>   6386  if (!mixed) {
>   6387  if (type &
>   6388  (BTRFS_BLOCK_GROUP_METADATA & 
> BTRFS_BLOCK_GROUP_DATA)) {
>  
> ^^^
> Was this supposed to be | or perhaps check that both are set?
Yes. It should be |.
Thank you, I'll send a patch to fix it.

> 
>   6389  btrfs_err(fs_info,
>   6390  "mixed chunk type in non-mixed mode: %llu", 
> type);
>   6391  return -EIO;
>   6392  }
>   6393  }
> 
> regards,
> dan carpenter
>

[bug report] btrfs: Add type check when reading a chunk

2018-07-19 Thread Dan Carpenter

Hello Gu Jinxiang,

The patch 72e75ed03c8d: "btrfs: Add type check when reading a chunk"
from Jul 4, 2018, leads to the following static checker warning:

fs/btrfs/volumes.c:6388 btrfs_check_chunk_valid()
warn: AND to zero '0x4 & 0x1'

fs/btrfs/volumes.c
  6356  if (!is_power_of_2(stripe_len) || stripe_len != 
BTRFS_STRIPE_LEN) {
  6357  btrfs_err(fs_info, "invalid chunk stripe length: %llu",
  6358stripe_len);
  6359  return -EIO;
  6360  }
  6361  if (~(BTRFS_BLOCK_GROUP_TYPE_MASK | 
BTRFS_BLOCK_GROUP_PROFILE_MASK) &
  6362  type) {
  6363  btrfs_err(fs_info, "unrecognized chunk type: %llu",
  6364~(BTRFS_BLOCK_GROUP_TYPE_MASK |
  6365  BTRFS_BLOCK_GROUP_PROFILE_MASK) &
  6366btrfs_chunk_type(leaf, chunk));
  6367  return -EIO;
  6368  }
  6369  
  6370  if ((type & BTRFS_BLOCK_GROUP_TYPE_MASK) == 0) {
  6371  btrfs_err(fs_info, "missing chunk type flag: %llu", 
type);
  6372  return -EIO;
  6373  }
  6374  
  6375  if ((type & BTRFS_BLOCK_GROUP_SYSTEM) &&
  6376  (type & (BTRFS_BLOCK_GROUP_METADATA | 
BTRFS_BLOCK_GROUP_DATA))) {
  6377  btrfs_err(fs_info,
  6378  "system chunk with data or metadata type: 
%llu", type);
  6379  return -EIO;
  6380  }
  6381  
  6382  features = btrfs_super_incompat_flags(fs_info->super_copy);
  6383  if (features & BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS)
  6384  mixed = 1;
  6385  
  6386  if (!mixed) {
  6387  if (type &
  6388  (BTRFS_BLOCK_GROUP_METADATA & 
BTRFS_BLOCK_GROUP_DATA)) {
 ^^^
Was this supposed to be | or perhaps check that both are set?

  6389  btrfs_err(fs_info,
  6390  "mixed chunk type in non-mixed mode: %llu", 
type);
  6391  return -EIO;
  6392  }
  6393  }

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[bug report] btrfs: add helper function check device delete able

2018-07-19 Thread Dan Carpenter

Hello Anand Jain,

The patch a6500c9ef8ac: "btrfs: add helper function check device
delete able" from Jul 10, 2018, leads to the following static checker
warning:

fs/btrfs/volumes.c:1871 btrfs_device_delete_able()
error: passing non negative 4 to ERR_PTR

fs/btrfs/volumes.c:1876 btrfs_device_delete_able()
error: passing non negative 6 to ERR_PTR

fs/btrfs/volumes.c:1879 btrfs_device_delete_able()
error: passing non negative 5 to ERR_PTR

fs/btrfs/volumes.c:1883 btrfs_device_delete_able()
error: passing non negative 7 to ERR_PTR

fs/btrfs/volumes.c
  1861  static struct btrfs_device *btrfs_device_delete_able(
  1862  struct btrfs_fs_info *fs_info,
  1863  const char *device_path, u64 devid)
  1864  {
  1865  int ret;
  1866  struct btrfs_device *device;
  1867  
  1868  ret = btrfs_check_raid_min_devices(fs_info,
  1869 btrfs_num_devices(fs_info) - 
1);
  1870  if (ret)
  1871  return ERR_PTR(ret);
   ^^^
This is a btrfs_err_code enum, not a negative error code.  It leads to
a NULL dereference in the caller.

  1872  
  1873  ret = btrfs_find_device_by_devspec(fs_info, devid, device_path,
  1874 );
  1875  if (ret)
  1876  return ERR_PTR(ret);
   ^^^
  1877  
  1878  if (test_bit(BTRFS_DEV_STATE_REPLACE_TGT, >dev_state))
  1879  return ERR_PTR(BTRFS_ERROR_DEV_TGT_REPLACE);
   ^^^
Same only even more so.

  1880  
  1881  if (test_bit(BTRFS_DEV_STATE_WRITEABLE, >dev_state) &&
  1882  fs_info->fs_devices->rw_devices == 1)
  1883  return ERR_PTR(BTRFS_ERROR_DEV_ONLY_WRITABLE);
   ^
  1884  
  1885  return device;
  1886  }

See also:

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [bug report] btrfs: Add unprivileged version of ino_lookup ioctl

2018-05-30 Thread Misono Tomohiro

Thanks for the reporting.
I will update the patch.

Regards,
Tomohiro Misono

On 2018/05/30 19:19, Dan Carpenter wrote:
> Hello Tomohiro Misono,
> 
> The patch 56bfce6502b7: "btrfs: Add unprivileged version of
> ino_lookup ioctl" from May 16, 2018, leads to the following static
> checker warning:
> 
>   fs/btrfs/ioctl.c:2478 btrfs_search_path_in_tree_user()
>   error: 'temp_inode' dereferencing possible ERR_PTR()
> 
> fs/btrfs/ioctl.c
>   2469  l = path->nodes[0];
>   2470  slot = path->slots[0];
>   2471  btrfs_item_key_to_cpu(l, , slot);
>   2472  if (key2.objectid != dirid) {
>   2473  ret = -ENOENT;
>   2474  goto out;
>   2475  }
>   2476  
>   2477  temp_inode = btrfs_iget(sb, , root, 
> NULL);
> ^^^
>   2478  ret = inode_permission(temp_inode, MAY_READ | 
> MAY_EXEC);
>^^
>   2479  iput(temp_inode);
>   2480  if (ret) {
>   2481  ret = -EACCES;
>   2482  goto out;
>   2483  }
>   2484  
> 
> 
> regards,
> dan carpenter
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[bug report] btrfs: Add unprivileged version of ino_lookup ioctl

2018-05-30 Thread Dan Carpenter

Hello Tomohiro Misono,

The patch 56bfce6502b7: "btrfs: Add unprivileged version of
ino_lookup ioctl" from May 16, 2018, leads to the following static
checker warning:

fs/btrfs/ioctl.c:2478 btrfs_search_path_in_tree_user()
error: 'temp_inode' dereferencing possible ERR_PTR()

fs/btrfs/ioctl.c
  2469  l = path->nodes[0];
  2470  slot = path->slots[0];
  2471  btrfs_item_key_to_cpu(l, , slot);
  2472  if (key2.objectid != dirid) {
  2473  ret = -ENOENT;
  2474  goto out;
  2475  }
  2476  
  2477  temp_inode = btrfs_iget(sb, , root, NULL);
^^^
  2478  ret = inode_permission(temp_inode, MAY_READ | 
MAY_EXEC);
   ^^
  2479  iput(temp_inode);
  2480  if (ret) {
  2481  ret = -EACCES;
  2482  goto out;
  2483  }
  2484  


regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [bug report] btrfs fail when run xfstests-dev/btrfs/007

2018-04-20 Thread Filipe Manana

On Fri, Apr 20, 2018 at 10:23 AM, Gu, Jinxiang <g...@cn.fujitsu.com> wrote:
> Hi,
>
> Here's a bug report.
> Kernel v4.17-rc1 failed xfstests-dev/btrfs/007.
> It is not always happens.( occurred times/test times: 1/20)

You don't need to check how many times it fails... You have a fsstress
seed from the .full file, that's all that matters.

I'll take a look at it, it's due to a missing truncate operation.

thanks

>
> And I confirmed this test using kernel v4.16-rc1.
> It also occurred sometimes.
>
> LOG when using kernel v4.17-rc1.
> btrfs/007[failed, exit status 1] - output mismatch (see 
> /home/gujx/xfstests-dev/results//btrfs/007.out.bad)
> --- tests/btrfs/007.out 2017-08-18 12:45:06.560413266 +0800
> +++ /home/gujx/xfstests-dev/results//btrfs/007.out.bad  2018-04-17 
> 13:24:06.887089998 +0800
> @@ -1,4 +1,5 @@
>  QA output created by 007
>  *** test send / receive
> -*** done
> +failed: '/home/gujx/xfstests-dev/src/fssum -r 
> /tmp/tmp.SkEUIXw683/incr.fssum /mnt/scratch/incr'
> +(see /home/gujx/xfstests-dev/results//btrfs/007.full for details)
>  *** unmount
> ...
> (Run 'diff -u tests/btrfs/007.out 
> /home/gujx/xfstests-dev/results//btrfs/007.out.bad'  to see the entire diff)
>
> And the detail can be found in the attachment.
>
> Thanks, Gu Jinxiang
>
>



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[bug report] btrfs fail when run xfstests-dev/btrfs/007

2018-04-20 Thread Gu, Jinxiang

Hi,

Here's a bug report.
Kernel v4.17-rc1 failed xfstests-dev/btrfs/007.
It is not always happens.( occurred times/test times: 1/20)

And I confirmed this test using kernel v4.16-rc1.
It also occurred sometimes.

LOG when using kernel v4.17-rc1.
btrfs/007[failed, exit status 1] - output mismatch (see 
/home/gujx/xfstests-dev/results//btrfs/007.out.bad)
--- tests/btrfs/007.out 2017-08-18 12:45:06.560413266 +0800
+++ /home/gujx/xfstests-dev/results//btrfs/007.out.bad  2018-04-17 
13:24:06.887089998 +0800
@@ -1,4 +1,5 @@
 QA output created by 007
 *** test send / receive
-*** done
+failed: '/home/gujx/xfstests-dev/src/fssum -r 
/tmp/tmp.SkEUIXw683/incr.fssum /mnt/scratch/incr'
+(see /home/gujx/xfstests-dev/results//btrfs/007.full for details)
 *** unmount
... 
(Run 'diff -u tests/btrfs/007.out 
/home/gujx/xfstests-dev/results//btrfs/007.out.bad'  to see the entire diff)

And the detail can be found in the attachment.

Thanks, Gu Jinxiang




007.full
Description: 007.full

Re: [Bug report] BTRFS partition re-mounted as read-only after few minutes of use

2018-02-28 Thread Qu Wenruo



On 2018年03月01日 02:36, Filipe Manana wrote:
> On Wed, Feb 28, 2018 at 5:50 PM, David Sterba  wrote:
>> On Wed, Feb 28, 2018 at 05:43:40PM +0100, peteryuchu...@gmail.com wrote:
>>> On my laptop, which has just been switched to BTRFS, the root partition
>>> (a BTRFS partition inside an encrypted LVM. The drive is an NVMe) is
>>> re-mounted as read-only few minutes after boot.
>>>
>>> Trace:
>>
>> By any chance, are there other messages from btrfs above the line?
>>>
>>> [  199.974591] [ cut here ]
>>> [  199.974593] BTRFS: Transaction aborted (error -95)
>>
>> -95 is EOPNOTSUPP, ie operation not supported
>>
>>> [  199.974647] WARNING: CPU: 0 PID: 324 at fs/btrfs/inode.c:3042 
>>> btrfs_finish_ordered_io+0x7ab/0x850 [btrfs]
>>
>> btrfs_finish_ordered_io::
>>
>>  3038 btrfs_ordered_update_i_size(inode, 0, ordered_extent);
>>  3039 ret = btrfs_update_inode_fallback(trans, root, inode);
>>  3040 if (ret) {
>>  3041 btrfs_abort_transaction(trans, ret);
>>  3042 goto out;
>>  3043 }
> 
> I don't know what's exactly in Arch's kernel, but looking at the
> 4.15.5 stable tag from kernel.org:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/fs/btrfs/inode.c?h=v4.15.5#n3042
> 
> The -EOPNOTSUPP error can come from btrfs_drop_extents() through the
> call to insert_reserved_file_extent().

__btrfs_drop_extents() will return -EOPNOTSUPP if we're dropping part of
an inline extent.

Could be something wrong with convert inline extent generator.


> We've had several reports of this kind of error in this location in
> the past and they happened to be on filesystems converted from extN to
> btrfs.
> I don't know however if this filesystem was from such a conversion nor
> if those old bugs in the conversion tool were fixed.

And since the user is using Arch and kernel is latest, it normally means
the btrfs-progs is also latest.

I need to double check about the convert inline extent code to ensure we
don't create too large inline extent.

Thanks,
Qu

> 
> 
>>
>> the return code is unexpected here. And seeing 'operation not supported'
>> after a inode size change looks strange but EOPNOTSUPP could be returned
>> from some places.
>>
>> The transaction is aborted from a thread that finalizes some processing
>> so we don't have enough information here to see how it started. I
>> suspect there's a file that gets modified short after boot and hits the
>> problem. I don't think the EOPNOTSUPP is returned from the lower layers
>> (lvm encryption or nvme), so at this point seems like a btrfs bug.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [Bug report] BTRFS partition re-mounted as read-only after few minutes of use

2018-02-28 Thread peteryuchuang

On Wed, 2018-02-28 at 18:36 +, Filipe Manana wrote:
> On Wed, Feb 28, 2018 at 5:50 PM, David Sterba 
> wrote:
> > On Wed, Feb 28, 2018 at 05:43:40PM +0100, peteryuchu...@gmail.com
> > wrote:
> > > On my laptop, which has just been switched to BTRFS, the root
> > > partition
> > > (a BTRFS partition inside an encrypted LVM. The drive is an NVMe)
> > > is
> > > re-mounted as read-only few minutes after boot.
> > > 
> > > Trace:
> > 
> > By any chance, are there other messages from btrfs above the line?
> > > 
> > > [  199.974591] [ cut here ]
> > > [  199.974593] BTRFS: Transaction aborted (error -95)
> > 
> > -95 is EOPNOTSUPP, ie operation not supported
> > 
> > > [  199.974647] WARNING: CPU: 0 PID: 324 at fs/btrfs/inode.c:3042
> > > btrfs_finish_ordered_io+0x7ab/0x850 [btrfs]
> > 
> > btrfs_finish_ordered_io::
> > 
> >  3038 btrfs_ordered_update_i_size(inode, 0,
> > ordered_extent);
> >  3039 ret = btrfs_update_inode_fallback(trans, root,
> > inode);
> >  3040 if (ret) {
> >  3041 btrfs_abort_transaction(trans, ret);
> >  3042 goto out;
> >  3043 }
> 
> I don't know what's exactly in Arch's kernel, but looking at the
> 4.15.5 stable tag from kernel.org:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.g
> it/tree/fs/btrfs/inode.c?h=v4.15.5#n3042
> 
> The -EOPNOTSUPP error can come from btrfs_drop_extents() through the
> call to insert_reserved_file_extent().
> We've had several reports of this kind of error in this location in
> the past and they happened to be on filesystems converted from extN
> to
> btrfs.
> I don't know however if this filesystem was from such a conversion
> nor
> if those old bugs in the conversion tool were fixed.
> 
> 

Indeed it was converted from ext4. I may try to rebuild the system from
scratch when I have more time, but I'm afraid I have to revert back to
ext4 for now.

> > 
> > the return code is unexpected here. And seeing 'operation not
> > supported'
> > after a inode size change looks strange but EOPNOTSUPP could be
> > returned
> > from some places.
> > 
> > The transaction is aborted from a thread that finalizes some
> > processing
> > so we don't have enough information here to see how it started. I
> > suspect there's a file that gets modified short after boot and hits
> > the
> > problem. I don't think the EOPNOTSUPP is returned from the lower
> > layers
> > (lvm encryption or nvme), so at this point seems like a btrfs bug.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> > btrfs" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug report] BTRFS partition re-mounted as read-only after few minutes of use

2018-02-28 Thread Filipe Manana

On Wed, Feb 28, 2018 at 5:50 PM, David Sterba  wrote:
> On Wed, Feb 28, 2018 at 05:43:40PM +0100, peteryuchu...@gmail.com wrote:
>> On my laptop, which has just been switched to BTRFS, the root partition
>> (a BTRFS partition inside an encrypted LVM. The drive is an NVMe) is
>> re-mounted as read-only few minutes after boot.
>>
>> Trace:
>
> By any chance, are there other messages from btrfs above the line?
>>
>> [  199.974591] [ cut here ]
>> [  199.974593] BTRFS: Transaction aborted (error -95)
>
> -95 is EOPNOTSUPP, ie operation not supported
>
>> [  199.974647] WARNING: CPU: 0 PID: 324 at fs/btrfs/inode.c:3042 
>> btrfs_finish_ordered_io+0x7ab/0x850 [btrfs]
>
> btrfs_finish_ordered_io::
>
>  3038 btrfs_ordered_update_i_size(inode, 0, ordered_extent);
>  3039 ret = btrfs_update_inode_fallback(trans, root, inode);
>  3040 if (ret) {
>  3041 btrfs_abort_transaction(trans, ret);
>  3042 goto out;
>  3043 }

I don't know what's exactly in Arch's kernel, but looking at the
4.15.5 stable tag from kernel.org:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/fs/btrfs/inode.c?h=v4.15.5#n3042

The -EOPNOTSUPP error can come from btrfs_drop_extents() through the
call to insert_reserved_file_extent().
We've had several reports of this kind of error in this location in
the past and they happened to be on filesystems converted from extN to
btrfs.
I don't know however if this filesystem was from such a conversion nor
if those old bugs in the conversion tool were fixed.


>
> the return code is unexpected here. And seeing 'operation not supported'
> after a inode size change looks strange but EOPNOTSUPP could be returned
> from some places.
>
> The transaction is aborted from a thread that finalizes some processing
> so we don't have enough information here to see how it started. I
> suspect there's a file that gets modified short after boot and hits the
> problem. I don't think the EOPNOTSUPP is returned from the lower layers
> (lvm encryption or nvme), so at this point seems like a btrfs bug.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug report] BTRFS partition re-mounted as read-only after few minutes of use

2018-02-28 Thread David Sterba

On Wed, Feb 28, 2018 at 05:43:40PM +0100, peteryuchu...@gmail.com wrote:
> On my laptop, which has just been switched to BTRFS, the root partition
> (a BTRFS partition inside an encrypted LVM. The drive is an NVMe) is
> re-mounted as read-only few minutes after boot. 
> 
> Trace:

By any chance, are there other messages from btrfs above the line?
> 
> [  199.974591] [ cut here ]
> [  199.974593] BTRFS: Transaction aborted (error -95)

-95 is EOPNOTSUPP, ie operation not supported

> [  199.974647] WARNING: CPU: 0 PID: 324 at fs/btrfs/inode.c:3042 
> btrfs_finish_ordered_io+0x7ab/0x850 [btrfs]

btrfs_finish_ordered_io::

 3038 btrfs_ordered_update_i_size(inode, 0, ordered_extent);
 3039 ret = btrfs_update_inode_fallback(trans, root, inode);
 3040 if (ret) {
 3041 btrfs_abort_transaction(trans, ret);
 3042 goto out;
 3043 }

the return code is unexpected here. And seeing 'operation not supported'
after a inode size change looks strange but EOPNOTSUPP could be returned
from some places.

The transaction is aborted from a thread that finalizes some processing
so we don't have enough information here to see how it started. I
suspect there's a file that gets modified short after boot and hits the
problem. I don't think the EOPNOTSUPP is returned from the lower layers
(lvm encryption or nvme), so at this point seems like a btrfs bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug report] BTRFS partition re-mounted as read-only after few minutes of use

2018-02-28 Thread peteryuchuang

Hi,

On my laptop, which has just been switched to BTRFS, the root partition
(a BTRFS partition inside an encrypted LVM. The drive is an NVMe) is
re-mounted as read-only few minutes after boot. 

Trace:

[  199.974591] [ cut here ]
[  199.974593] BTRFS: Transaction aborted (error -95)
[  199.974647] WARNING: CPU: 0 PID: 324 at fs/btrfs/inode.c:3042
btrfs_finish_ordered_io+0x7ab/0x850 [btrfs]
[  199.974648] Modules linked in: tun fuse cmac rfcomm bnep
snd_hda_codec_hdmi ip6t_REJECT snd_hda_codec_generic nf_reject_ipv6
nf_log_ipv6 xt_hl nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_rt ipt_REJECT
nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_tcpudp
nls_iso8859_1 nls_cp437 vfat fat nf_conntrack_ipv4 nf_defrag_ipv4
xt_addrtype xt_conntrack snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core
snd_soc_sst_dsp snd_soc_sst_ipc snd_soc_acpi brcmfmac snd_soc_core
ip6table_filter ip6_tables brcmutil nf_conntrack_netbios_ns
snd_compress nf_conntrack_broadcast nf_nat_ftp ac97_bus cfg80211
snd_pcm_dmaengine nf_nat nf_conntrack_ftp nf_conntrack libcrc32c
crc32c_generic thunderbolt iptable_filter iTCO_wdt mmc_core
iTCO_vendor_support crypto_user msr intel_rapl x86_pkg_temp_thermal
intel_powerclamp coretemp
[  199.974675]  kvm_intel snd_hda_intel snd_hda_codec kvm snd_hda_core
applesmc snd_hwdep input_polldev irqbypass snd_pcm intel_cstate
snd_timer intel_uncore intel_rapl_perf pcspkr i915 snd i2c_i801
soundcore joydev mousedev input_leds i2c_algo_bit drm_kms_helper
hci_uart btbcm btqca btintel drm bluetooth mei_me 8250_dw intel_gtt mei
agpgart acpi_als shpchp syscopyarea idma64 sysfillrect sbs sysimgblt
fb_sys_fops ecdh_generic rfkill kfifo_buf sbshc industrialio rtc_cmos
evdev mac_hid ac apple_bl facetimehd(O) videobuf2_dma_sg
videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media ip_tables
x_tables btrfs xor zstd_decompress zstd_compress xxhash raid6_pq
dm_crypt algif_skcipher af_alg dm_mod crct10dif_pclmul crc32_pclmul
crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64
crypto_simd
[  199.974710]  glue_helper cryptd xhci_pci xhci_hcd usbcore usb_common
applespi(O) crc16 led_class intel_lpss_pci intel_lpss
spi_pxa2xx_platform
[  199.974718] CPU: 0 PID: 324 Comm: kworker/u8:6 Tainted:
G U O 4.15.5-1-ARCH #1
[  199.974718] Hardware name: Apple Inc. MacBookPro14,1/Mac-
B4831CEBD52A0C4C, BIOS MBP141.88Z.0169.B00.1712141501 12/14/2017
[  199.974734] Workqueue: btrfs-endio-write btrfs_endio_write_helper
[btrfs]
[  199.974746] RIP: 0010:btrfs_finish_ordered_io+0x7ab/0x850 [btrfs]
[  199.974747] RSP: 0018:b3310128bdc8 EFLAGS: 00010286
[  199.974749] RAX:  RBX: a25b1e150b60 RCX:
0001
[  199.974749] RDX: 8001 RSI: 9fe47fd0 RDI:

[  199.974750] RBP: a25a2df7dad0 R08: 0001 R09:
0412
[  199.974751] R10:  R11:  R12:
a25a2df7d8e0
[  199.974752] R13: a25a2df7d8c0 R14: a25b1f037f78 R15:
0001
[  199.974753] FS:  () GS:a25b2ec0()
knlGS:
[  199.974754] CS:  0010 DS:  ES:  CR0: 80050033
[  199.974755] CR2: 7fd9cc5dd3e7 CR3: 6300a002 CR4:
003606f0
[  199.974756] DR0:  DR1:  DR2:

[  199.974756] DR3:  DR6: fffe0ff0 DR7:
0400
[  199.974757] Call Trace:
[  199.974774]  normal_work_helper+0x39/0x370 [btrfs]
[  199.974779]  process_one_work+0x1ce/0x410
[  199.974782]  worker_thread+0x2b/0x3d0
[  199.974784]  ? process_one_work+0x410/0x410
[  199.974785]  kthread+0x113/0x130
[  199.974787]  ? kthread_create_on_node+0x70/0x70
[  199.974789]  ? do_syscall_64+0x74/0x190
[  199.974791]  ? SyS_exit_group+0x10/0x10
[  199.974793]  ret_from_fork+0x35/0x40
[  199.974795] Code: 08 01 e9 a4 fb ff ff 49 8b 46 60 f0 0f ba a8 50 12
00 00 02 72 17 8b 74 24 10 83 fe fb 74 32 48 c7 c7 38 a7 6c c0 e8 85 7a
a3 de <0f> 0b 8b 4c 24 10 ba e2 0b 00 00 eb b1 4c 8b 23 4c 8b 53 10 41 
[  199.974820] ---[ end trace c8ed62ff6a525901 ]---
[  199.974822] BTRFS: error (device dm-2) in
btrfs_finish_ordered_io:3042: errno=-95 unknown
[  199.974824] BTRFS info (device dm-2): forced readonly
[  199.976696] BTRFS error (device dm-2): pending csums is 6447104

Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=198945
Kernel version: 4.15.5
Distro: Arch Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bug report: mounting the same device to different mount points in parallel may fail

2018-01-17 Thread Misono, Tomohiro

Although I think this rarely happens in the real world, mounting 
the same device to different mount points in parallel may fail:

- kernel 4.15.0-rc8

- Procedure
[mount.sh]
#!/bin/bash
for i in `seq 1 1000`; do
  echo $i
  mount $1 $2
  umount $2
  if [ $? -ne 0 ]; then
exit 1;
  fi
done

$ mkfs.btrfs -f /dev/sde
$ ./mount.sh /dev/sde /mnt
$ ./mount.sh /dev/sde /mnt2 (on the different terminal)

- stdout
mount: /mnt2: wrong fs type, bad option, bad superblock on 
/dev/sde, missing codepage or helper program, or other error.

- dmesg
[  108.122576] BTRFS error (device sde): super_total_bytes 199481098240 
mismatch with fs_devices total_rw_bytes 398962196480
[  108.122647] BTRFS error (device sde): failed to read chunk tree: -22
[  108.150060] BTRFS error (device sde): open_ctree failed

xfs or ext4 works fine.

Regards,
Tomohiro Misono

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [bug report] btrfs: cleanup device states define BTRFS_DEV_STATE_IN_FS_METADATA

2017-12-10 Thread Anand Jain




On 12/08/2017 07:08 PM, Dan Carpenter wrote:

Hello Anand Jain,

The patch 2dcfcdc43524: "btrfs: cleanup device states define
BTRFS_DEV_STATE_IN_FS_METADATA" from Dec 4, 2017, leads to the
following static checker warning:

fs/btrfs/super.c:2007 btrfs_calc_avail_data_space()
warn: test_bit() takes a bit number

fs/btrfs/super.c
   2004
   2005  rcu_read_lock();
   2006  list_for_each_entry_rcu(device, _devices->devices, 
dev_list) {
   2007  if (!test_bit(BTRFS_DEV_STATE_IN_FS_METADATA,
   ^^
This BTRFS_DEV_STATE_IN_FS_METADATA define is BIT(1) but for test_bit()
we should just take 1.  In other words we are doing double BIT(BIT(1)).

   2008  >dev_state) ||
   2009  !device->bdev ||
   2010  test_bit(BTRFS_DEV_STATE_REPLACE_TGT, 
>dev_state))
   2011  continue;
   2012
   2013  if (i >= nr_devices)
   2014  break;
   2015


 Thanks Dan. I fixed all these in v3.

- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[bug report] btrfs: cleanup device states define BTRFS_DEV_STATE_IN_FS_METADATA

2017-12-08 Thread Dan Carpenter

Hello Anand Jain,

The patch 2dcfcdc43524: "btrfs: cleanup device states define
BTRFS_DEV_STATE_IN_FS_METADATA" from Dec 4, 2017, leads to the
following static checker warning:

fs/btrfs/super.c:2007 btrfs_calc_avail_data_space()
warn: test_bit() takes a bit number

fs/btrfs/super.c
  2004  
  2005  rcu_read_lock();
  2006  list_for_each_entry_rcu(device, _devices->devices, dev_list) 
{
  2007  if (!test_bit(BTRFS_DEV_STATE_IN_FS_METADATA,
  ^^
This BTRFS_DEV_STATE_IN_FS_METADATA define is BIT(1) but for test_bit()
we should just take 1.  In other words we are doing double BIT(BIT(1)).

  2008  >dev_state) ||
  2009  !device->bdev ||
  2010  test_bit(BTRFS_DEV_STATE_REPLACE_TGT, 
>dev_state))
  2011  continue;
  2012  
  2013  if (i >= nr_devices)
  2014  break;
  2015  

I get a bunch of these warnings.

drivers/md/md-bitmap.c:1993 bitmap_copy_from_slot() warn: 
'bitmap_file_test_bit(bitmap, block)' returns positive and negative
[ I threw this one is as a bonus.  The warning is because are we
  handling the -EINVAL return from bitmap_file_test_bit() correctly?
  I have no idea. ]

fs/btrfs/super.c:2007 btrfs_calc_avail_data_space() warn: test_bit() takes a 
bit number
fs/btrfs/super.c:2010 btrfs_calc_avail_data_space() warn: test_bit() takes a 
bit number
fs/btrfs/super.c:2315 btrfs_show_devname() warn: test_bit() takes a bit number
fs/btrfs/disk-io.c:3351 write_dev_flush() warn: test_bit() takes a bit number
fs/btrfs/disk-io.c:3361 wait_dev_flush() warn: test_bit() takes a bit number
fs/btrfs/disk-io.c:3364 wait_dev_flush() warn: test_bit() takes a bit number
fs/btrfs/disk-io.c:3392 barrier_all_devices() warn: test_bit() takes a bit 
number
fs/btrfs/disk-io.c:3396 barrier_all_devices() warn: test_bit() takes a bit 
number
fs/btrfs/disk-io.c:3397 barrier_all_devices() warn: test_bit() takes a bit 
number
fs/btrfs/disk-io.c:3406 barrier_all_devices() warn: test_bit() takes a bit 
number
fs/btrfs/disk-io.c:3412 barrier_all_devices() warn: test_bit() takes a bit 
number
fs/btrfs/disk-io.c:3413 barrier_all_devices() warn: test_bit() takes a bit 
number
fs/btrfs/disk-io.c:3510 write_all_supers() warn: test_bit() takes a bit number
fs/btrfs/disk-io.c:3511 write_all_supers() warn: test_bit() takes a bit number
fs/btrfs/disk-io.c:3550 write_all_supers() warn: test_bit() takes a bit number
fs/btrfs/disk-io.c:3551 write_all_supers() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:695 btrfs_open_one_device() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:699 btrfs_open_one_device() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:701 btrfs_open_one_device() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:709 btrfs_open_one_device() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:713 btrfs_open_one_device() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:829 device_list_add() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:831 device_list_add() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:913 btrfs_close_extra_devices() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:915 btrfs_close_extra_devices() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:935 btrfs_close_extra_devices() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:945 btrfs_close_extra_devices() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:947 btrfs_close_extra_devices() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:948 btrfs_close_extra_devices() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:980 btrfs_close_bdev() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:997 btrfs_prepare_close_one_device() warn: test_bit() takes 
a bit number
fs/btrfs/volumes.c:1003 btrfs_prepare_close_one_device() warn: test_bit() takes 
a bit number
fs/btrfs/volumes.c:1258 btrfs_account_dev_extents_size() warn: test_bit() takes 
a bit number
fs/btrfs/volumes.c:1437 find_free_dev_extent_start() warn: test_bit() takes a 
bit number
fs/btrfs/volumes.c:1644 btrfs_alloc_dev_extent() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:1645 btrfs_alloc_dev_extent() warn: test_bit() takes a bit 
number
fs/btrfs/volumes.c:1891 btrfs_find_next_active_device() warn: test_bit() takes 
a bit number
fs/btrfs/volumes.c:1953 btrfs_rm_device() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:1958 btrfs_rm_device() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:1964 btrfs_rm_device() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:1986 btrfs_rm_device() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:2006 btrfs_rm_device() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:2026 btrfs_rm_device() warn: test_bit() takes a bit number
fs/btrfs/volumes.c:2053

Re: [bug report] btrfs: error out if btrfs_attach_transaction() fails

2017-10-12 Thread Anand Jain




  Thanks Dan! You are right. Will fix it.

Anand


On 10/13/2017 04:39 AM, Dan Carpenter wrote:

Hello Anand Jain,

The patch 1eea2715ca9b: "btrfs: error out if
btrfs_attach_transaction() fails" from Sep 28, 2017, leads to the
following static checker warning:

fs/btrfs/volumes.c:2502 btrfs_init_new_device()
error: 'trans' dereferencing possible ERR_PTR()

fs/btrfs/volumes.c
   2479  ret = btrfs_relocate_sys_chunks(fs_info);
   2480  if (ret < 0)
   2481  btrfs_handle_fs_error(fs_info, ret,
   2482  "Failed to relocate sys chunks after device 
initialization. This can be fixed using the \"btrfs balance\" command.");
   2483  trans = btrfs_attach_transaction(root);
   2484  if (IS_ERR(trans)) {
   2485  if (PTR_ERR(trans) == -ENOENT)
   2486  return 0;
   2487  ret = PTR_ERR(trans);
   2488  goto error_sysfs;
 
We used to have a direct return here.

   2489  }
   2490  ret = btrfs_commit_transaction(trans);
   2491  }
   2492
   2493  /* Update ctime/mtime for libblkid */
   2494  update_dev_time(device_path);
   2495  return ret;
   2496
   2497  error_sysfs:
   2498  btrfs_sysfs_rm_device_link(fs_info->fs_devices, device);
   2499  error_trans:
   2500  if (seeding_dev)
   2501  sb->s_flags |= MS_RDONLY;
   2502  btrfs_end_transaction(trans);
   ^^
But now it's dereferencing an error pointer inside this function.

   2503  rcu_string_free(device->name);
   2504  kfree(device);
   2505  error:
   2506  blkdev_put(bdev, FMODE_EXCL);
   2507  if (seeding_dev && !unlocked) {
   2508  mutex_unlock(_mutex);
   2509  up_write(>s_umount);
   2510  }
   2511  return ret;
   2512  }

regards,
dan carpenter


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[bug report] btrfs: error out if btrfs_attach_transaction() fails

2017-10-12 Thread Dan Carpenter

Hello Anand Jain,

The patch 1eea2715ca9b: "btrfs: error out if
btrfs_attach_transaction() fails" from Sep 28, 2017, leads to the
following static checker warning:

fs/btrfs/volumes.c:2502 btrfs_init_new_device()
error: 'trans' dereferencing possible ERR_PTR()

fs/btrfs/volumes.c
  2479  ret = btrfs_relocate_sys_chunks(fs_info);
  2480  if (ret < 0)
  2481  btrfs_handle_fs_error(fs_info, ret,
  2482  "Failed to relocate sys chunks 
after device initialization. This can be fixed using the \"btrfs balance\" 
command.");
  2483  trans = btrfs_attach_transaction(root);
  2484  if (IS_ERR(trans)) {
  2485  if (PTR_ERR(trans) == -ENOENT)
  2486  return 0;
  2487  ret = PTR_ERR(trans);
  2488  goto error_sysfs;

We used to have a direct return here.

  2489  }
  2490  ret = btrfs_commit_transaction(trans);
  2491  }
  2492  
  2493  /* Update ctime/mtime for libblkid */
  2494  update_dev_time(device_path);
  2495  return ret;
  2496  
  2497  error_sysfs:
  2498  btrfs_sysfs_rm_device_link(fs_info->fs_devices, device);
  2499  error_trans:
  2500  if (seeding_dev)
  2501  sb->s_flags |= MS_RDONLY;
  2502  btrfs_end_transaction(trans);
  ^^
But now it's dereferencing an error pointer inside this function.

  2503  rcu_string_free(device->name);
  2504  kfree(device);
  2505  error:
  2506  blkdev_put(bdev, FMODE_EXCL);
  2507  if (seeding_dev && !unlocked) {
  2508  mutex_unlock(_mutex);
  2509  up_write(>s_umount);
  2510  }
  2511  return ret;
  2512  }

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [bug report] btrfs: get fs_info from eb in btrfs_print_leaf, remove argument

2017-07-19 Thread David Sterba

On Wed, Jul 19, 2017 at 04:13:07PM +0300, Dan Carpenter wrote:
> Hello David Sterba,
> 
> This is a semi-automatic email about new static checker warnings.
> 
> The patch c042dd070450: "btrfs: get fs_info from eb in
> btrfs_print_leaf, remove argument" from Jun 29, 2017, leads to the
> following Smatch complaint:
> 
> fs/btrfs/print-tree.c:181 btrfs_print_leaf()
> warn: variable dereferenced before check 'l' (see line 166)
> 
> fs/btrfs/print-tree.c
>165{
>166struct btrfs_fs_info *fs_info = l->fs_info;
> ^^
> New dereference.
> 
>167int i;
>168u32 type, nr;
>169struct btrfs_item *item;
>170struct btrfs_root_item *ri;
>171struct btrfs_dir_item *di;
>172struct btrfs_inode_item *ii;
>173struct btrfs_block_group_item *bi;
>174struct btrfs_file_extent_item *fi;
>175struct btrfs_extent_data_ref *dref;
>176struct btrfs_shared_data_ref *sref;
>177struct btrfs_dev_extent *dev_extent;
>178struct btrfs_key key;
>179struct btrfs_key found_key;
>180
>181if (!l)
> ^^
> Checked too late.

Thanks, I've moved the fs_info initialization after this check. In both
patches (btrfs_print_leaf and btrfs_print_tree).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[bug report] btrfs: get fs_info from eb in btrfs_print_leaf, remove argument

2017-07-19 Thread Dan Carpenter

Hello David Sterba,

This is a semi-automatic email about new static checker warnings.

The patch c042dd070450: "btrfs: get fs_info from eb in
btrfs_print_leaf, remove argument" from Jun 29, 2017, leads to the
following Smatch complaint:

fs/btrfs/print-tree.c:181 btrfs_print_leaf()
warn: variable dereferenced before check 'l' (see line 166)

fs/btrfs/print-tree.c
   165  {
   166  struct btrfs_fs_info *fs_info = l->fs_info;
^^
New dereference.

   167  int i;
   168  u32 type, nr;
   169  struct btrfs_item *item;
   170  struct btrfs_root_item *ri;
   171  struct btrfs_dir_item *di;
   172  struct btrfs_inode_item *ii;
   173  struct btrfs_block_group_item *bi;
   174  struct btrfs_file_extent_item *fi;
   175  struct btrfs_extent_data_ref *dref;
   176  struct btrfs_shared_data_ref *sref;
   177  struct btrfs_dev_extent *dev_extent;
   178  struct btrfs_key key;
   179  struct btrfs_key found_key;
   180  
   181  if (!l)
^^
Checked too late.

   182  return;
   183  

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[bug report] Btrfs: replace tree->mapping with tree->private_data

2017-06-28 Thread Dan Carpenter

Hello Josef Bacik,

The patch c6100a4b4e3d: "Btrfs: replace tree->mapping with
tree->private_data" from May 5, 2017, leads to the following static
checker warning:

fs/btrfs/extent_io.c:3424 __extent_writepage_io()
error: we previously assumed 'tree->ops' could be null (see line 3334)

fs/btrfs/extent_io.c
  3404   * compressed extents
  3405   */
  3406  if (!compressed && tree->ops &&
   ^
This function consistently check tree->ops before dereferencing it.

  3407  tree->ops->writepage_end_io_hook)
  3408  tree->ops->writepage_end_io_hook(page, 
cur,
  3409   cur + iosize - 
1,
  3410   NULL, 1);
  3411  else if (compressed) {
  3412  /* we don't want to end_page_writeback 
on
  3413   * a compressed extent.  this happens
  3414   * elsewhere
  3415   */
  3416  nr++;
  3417  }
  3418  
  3419  cur += iosize;
  3420  pg_offset += iosize;
  3421  continue;
  3422  }
  3423  
  3424  set_range_writeback(tree, cur, cur + iosize - 1);

The patch adds a new unchecked dereference.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [bug report] btrfs: root->fs_info cleanup, add fs_info convenience variables

2016-12-22 Thread Jeff Mahoney

On 12/22/16 7:53 AM, Dan Carpenter wrote:
> Hello Jeff Mahoney,
> 
> This is a semi-automatic email about new static checker warnings.

Hi Dan -

Thanks for the report.  We've already seen this one and the right fix is
to remove the checks in btrfs_get_name since exportfs won't pass
negative dentries.  The original reporter has submitted a patch for that.

-Jeff

> The patch 0b246afa62b0: "btrfs: root->fs_info cleanup, add fs_info 
> convenience variables" from Jun 22, 2016, leads to the following 
> Smatch complaint:
> 
> fs/btrfs/export.c:238 btrfs_get_name()
>warn: variable dereferenced before check 'inode' (see line 226)
> 
> fs/btrfs/export.c
>225struct inode *dir = d_inode(parent);
>226struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
>  ^^^
> Patch adds dereference.
> 
>227struct btrfs_path *path;
>228struct btrfs_root *root = BTRFS_I(dir)->root;
>229struct btrfs_inode_ref *iref;
>230struct btrfs_root_ref *rref;
>231struct extent_buffer *leaf;
>232unsigned long name_ptr;
>233struct btrfs_key key;
>234int name_len;
>235int ret;
>236u64 ino;
>237
>238if (!dir || !inode)
>  ^
> Old code checked for NULL.
> 
>239return -EINVAL;
>240
> 
> regards,
> dan carpenter
> 


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

[bug report] btrfs: root->fs_info cleanup, add fs_info convenience variables

2016-12-22 Thread Dan Carpenter

Hello Jeff Mahoney,

This is a semi-automatic email about new static checker warnings.

The patch 0b246afa62b0: "btrfs: root->fs_info cleanup, add fs_info 
convenience variables" from Jun 22, 2016, leads to the following 
Smatch complaint:

fs/btrfs/export.c:238 btrfs_get_name()
 warn: variable dereferenced before check 'inode' (see line 226)

fs/btrfs/export.c
   225  struct inode *dir = d_inode(parent);
   226  struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
 ^^^
Patch adds dereference.

   227  struct btrfs_path *path;
   228  struct btrfs_root *root = BTRFS_I(dir)->root;
   229  struct btrfs_inode_ref *iref;
   230  struct btrfs_root_ref *rref;
   231  struct extent_buffer *leaf;
   232  unsigned long name_ptr;
   233  struct btrfs_key key;
   234  int name_len;
   235  int ret;
   236  u64 ino;
   237  
   238  if (!dir || !inode)
 ^
Old code checked for NULL.

   239  return -EINVAL;
   240  

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[bug report] btrfs: Expoert and move leaf/subtree qgroup helpers to qgroup.c

2016-11-10 Thread Dan Carpenter

Hello Qu Wenruo,

The patch 4c98cc4b6d12: "btrfs: Expoert and move leaf/subtree qgroup
helpers to qgroup.c" from Oct 18, 2016, leads to the following static
checker warning:

fs/btrfs/qgroup.c:1682 btrfs_qgroup_trace_subtree()
error: buffer overflow 'path->nodes' 8 <= 8

fs/btrfs/qgroup.c
  1641  int btrfs_qgroup_trace_subtree(struct btrfs_trans_handle *trans,
  1642 struct btrfs_root *root,
  1643 struct extent_buffer *root_eb,
  1644 u64 root_gen, int root_level)
  1645  {
  1646  int ret = 0;
  1647  int level;
  1648  struct extent_buffer *eb = root_eb;
  1649  struct btrfs_path *path = NULL;
  1650  
  1651  BUG_ON(root_level < 0 || root_level > BTRFS_MAX_LEVEL);

You didn't really introduce the warning, just made it show up as a new
warning by moving the code around.  Still, this should be
>= BTRFS_MAX_LEVEL shouldn't it?


  1652  BUG_ON(root_eb == NULL);
  1653  
  1654  if (!test_bit(BTRFS_FS_QUOTA_ENABLED, >fs_info->flags))
  1655  return 0;
  1656  
  1657  if (!extent_buffer_uptodate(root_eb)) {
  1658  ret = btrfs_read_buffer(root_eb, root_gen);
  1659  if (ret)
  1660  goto out;
  1661  }
  1662  
  1663  if (root_level == 0) {
  1664  ret = btrfs_qgroup_trace_leaf_items(trans, root, 
root_eb);
  1665  goto out;
  1666  }
  1667  
  1668  path = btrfs_alloc_path();
  1669  if (!path)
  1670  return -ENOMEM;
  1671  
  1672  /*
  1673   * Walk down the tree.  Missing extent blocks are filled in as
  1674   * we go. Metadata is accounted every time we read a new
  1675   * extent block.
  1676   *
  1677   * When we reach a leaf, we account for file extent items in it,
  1678   * walk back up the tree (adjusting slot pointers as we go)
  1679   * and restart the search process.
  1680   */
  1681  extent_buffer_get(root_eb); /* For path */
  1682  path->nodes[root_level] = root_eb;

Otherwise, we're off by one.

  1683  path->slots[root_level] = 0;
  1684  path->locks[root_level] = 0; /* so release_path doesn't try to 
unlock */
  1685  walk_down:

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bug report about patch "Btrfs: kill the btree_inode"

2016-09-09 Thread Josef Bacik


On 09/09/2016 04:28 AM, Wang Xiaoguang wrote:

hello,

When we rebase dedupe patches to David's for-next-20160906 branch,
we found below panic. By bisect, it seems that "Btrfs: kill the btree_inode"
causing this bug, please check.
Fstests case btrfs/060 can easily reproduce this bug.


Oops forgot to run with SCRATCH_DEV_POOL.  Thanks I'll fix this up and send out 
the corrected patch,


Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bug report about patch "Btrfs: kill the btree_inode"

2016-09-09 Thread Wang Xiaoguang


hello,

When we rebase dedupe patches to David's for-next-20160906 branch,
we found below panic. By bisect, it seems that "Btrfs: kill the btree_inode"
causing this bug, please check.
Fstests case btrfs/060 can easily reproduce this bug.

localhost login: [   43.694734] BUG: unable to handle kernel NULL 
pointer dereference at 0070

[   43.695812] IP: [] list_lru_destroy+0x11/0xe0
[   43.696526] PGD 0
[   43.696765] Oops:  [#1] SMP
[   43.697105] Modules linked in: uinput fuse ip6t_rpfilter ip6t_REJECT 
nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat 
ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat 
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle 
ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
iptable_mangle iptable_security iptable_raw iptable_filter dm_mirror 
dm_region_hash dm_log dm_mod snd_hda_codec_generic crct10dif_pclmul 
crc32_pclmul ext4 snd_hda_intel ppdev snd_hda_codec jbd2 btrfs 
ghash_clmulni_intel mbcache snd_hwdep snd_hda_core snd_seq xor 
snd_seq_device aesni_intel glue_helper lrw raid6_pq snd_pcm gf128mul 
ablk_helper cryptd parport_pc snd_timer pcspkr virtio_balloon snd 
parport soundcore sg i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace 
sunrpc ip_tables xfs libcrc32c sr_mod cdrom sd_mod ata_generic pata_acpi 
qxl virtio_console drm_kms_helper 8139too syscopyarea sysfillrect ahci 
sysimgblt fb_sys_fops ttm libahci ata_piix drm libata crc32c_intel 
serio_raw virtio_pci i2c_core virtio_ring virtio 8139cp mii floppy

[   43.709009] CPU: 0 PID: 8267 Comm: mount Not tainted 4.8.0-rc5+ #50
[   43.709680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
BIOS 1.8.2-20150714_191134- 04/01/2014

[   43.710691] task: 880074e3ab80 task.stack: 88006c1e8000
[   43.711322] RIP: 0010:[] [] 
list_lru_destroy+0x11/0xe0

[   43.712227] RSP: 0018:88006c1ebb88  EFLAGS: 00010246
[   43.712796] RAX:  RBX:  RCX: 
dead0200
[   43.713552] RDX: 81c78d78 RSI: 880074e3ab80 RDI: 
0070
[   43.714314] RBP: 88006c1ebba0 R08: 88006c1ebb00 R09: 
88003337e000
[   43.715074] R10:  R11: 000a282f3176 R12: 
0070
[   43.715948] R13: 8800738b6000 R14: 88007b028680 R15: 
8800769b0a80
[   43.716709] FS:  7fd734456880() GS:88007de0() 
knlGS:

[   43.717570] CS:  0010 DS:  ES:  CR0: 80050033
[   43.718187] CR2: 0070 CR3: 77b8d000 CR4: 
000406f0

[   43.718954] Stack:
[   43.719177]   a05f31a0 8800738b6000 
88006c1ebc80
[   43.720018]  a052a1fe c9abea50 00080294 
00017b403b01
[   43.720862]  88006c1ebbd8 813640ae 88006c1ebc08 
811b8b4e

[   43.721675] Call Trace:
[   43.721968]  [] btrfs_mount+0xb6e/0xfc0 [btrfs]
[   43.722676]  [] ? find_next_zero_bit+0x1e/0x20
[   43.723321]  [] ? pcpu_next_unpop+0x3e/0x50
[   43.723938]  [] ? find_next_bit+0x19/0x20
[   43.724537]  [] mount_fs+0x39/0x160
[   43.725085]  [] ? __alloc_percpu+0x15/0x20
[   43.725696]  [] vfs_kern_mount+0x67/0x100
[   43.726332]  [] btrfs_mount+0x19d/0xfc0 [btrfs]
[   43.726992]  [] ? find_next_zero_bit+0x1e/0x20
[   43.727646]  [] mount_fs+0x39/0x160
[   43.728192]  [] ? __alloc_percpu+0x15/0x20
[   43.728881]  [] vfs_kern_mount+0x67/0x100
[   43.729480]  [] do_mount+0x1e2/0xca0
[   43.730036]  [] ? kmem_cache_alloc_trace+0x14b/0x1b0
[   43.730742]  [] SyS_mount+0x83/0xd0
[   43.731290]  [] do_syscall_64+0x67/0x160
[   43.731888]  [] entry_SYSCALL64_slow_path+0x25/0x25
[   43.732575] Code: 4d 8b 26 4c 89 e7 e8 9f 64 03 00 5b 41 5c 41 5d 41 
5e 5d c3 66 0f 1f 44 00 00 66 66 66 66 90 55 48 89 e5 41 55 41 54 49 89 
fc 53 <48> 83 3f 00 0f 84 b2 00 00 00 e8 50 9a 04 00 48 c7 c7 20 34 c9

[   43.735379] RIP  [] list_lru_destroy+0x11/0xe0
[   43.736043]  RSP 
[   43.736421] CR2: 0070
[   43.737102] ---[ end trace 7f226c7f270332f0 ]---
[   43.737837] Kernel panic - not syncing: Fatal exception
[   43.738430] Kernel Offset: disabled
[   43.738735] ---[ end Kernel panic - not syncing: Fatal exception

Regards,
Xiaoguang Wang


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[bug report] btrfs: root->fs_info cleanup, add fs_info convenience variables

2016-07-08 Thread Dan Carpenter

Hello Jeff Mahoney,

This is a semi-automatic email about new static checker warnings.

The patch b286384aac32: "btrfs: root->fs_info cleanup, add fs_info
convenience variables" from Jun 22, 2016, leads to the following
Smatch complaint:

fs/btrfs/export.c:238 btrfs_get_name()
 warn: variable dereferenced before check 'inode' (see line 226)

fs/btrfs/export.c
   225  struct inode *dir = d_inode(parent);
   226  struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
 ^^^
New dereference.

   227  struct btrfs_path *path;
   228  struct btrfs_root *root = BTRFS_I(dir)->root;
   229  struct btrfs_inode_ref *iref;
   230  struct btrfs_root_ref *rref;
   231  struct extent_buffer *leaf;
   232  unsigned long name_ptr;
   233  struct btrfs_key key;
   234  int name_len;
   235  int ret;
   236  u64 ino;
   237  
   238  if (!dir || !inode)
 ^
Old code assumed it can be NULL.

   239  return -EINVAL;
   240  

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug Report: btrfs hangs / freezes on 4.3

2015-12-02 Thread Martin Tippmann

Hi,

just saw this in the logs on a few machines, Kernel 4.3.0, Mount options:

/dev/sda /media/storage1 btrfs
rw,noatime,compress=lzo,space_cache,subvolid=5,subvol=/ 0 0

[414675.258270] INFO: task java:19267 blocked for more than 120 seconds.
[414675.258312]   Not tainted 4.3.0-040300-generic #201511020846
[414675.258353] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[414675.258429] javaD 88081f996980 0 19267  18965 0x
[414675.258436]  880337d67bb8 0082 88081c2f3800
880019be9c00
[414675.258438]  880337d68000 88101b7627bc 880019be9c00

[414675.258440]  88101b7627c0 880337d67bd0 817af3f3
88101b7627b8
[414675.258442] Call Trace:
[414675.258445]  [] schedule+0x33/0x80
[414675.258450]  [] schedule_preempt_disabled+0xe/0x10
[414675.258454]  [] __mutex_lock_slowpath+0x95/0x110
[414675.258458]  [] mutex_lock+0x1f/0x30
[414675.258470]  []
btrfs_wait_ordered_roots+0x42/0x1d0 [btrfs]
[414675.258480]  []
btrfs_check_data_free_space+0x1ff/0x2f0 [btrfs]
[414675.258491]  [] __btrfs_buffered_write+0x13f/0x5a0 [btrfs]
[414675.258495]  [] ? tcp_recvmsg+0x3d1/0xb70
[414675.258505]  [] btrfs_file_write_iter+0x171/0x560 [btrfs]
[414675.258510]  [] ? set_next_entity+0x9c/0xb0
[414675.258515]  [] __vfs_write+0xa7/0xf0
[414675.258520]  [] vfs_write+0xa6/0x1a0
[414675.258524]  [] SyS_write+0x46/0xa0
[414675.258528]  [] entry_SYSCALL_64_fastpath+0x16/0x75
[414675.258533] INFO: task java:19268 blocked for more than 120 seconds.
[414675.258576]   Not tainted 4.3.0-040300-generic #201511020846
[414675.258616] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[414675.258684] javaD 88081f996980 0 19268  18965 0x
[414675.258692]  880634f23bb8 0082 88081c2f3800
880019beaa00
[414675.258704]  880634f24000 88101b7627bc 880019beaa00

[414675.258715]  88101b7627c0 880634f23bd0 817af3f3
88101b7627b8
[414675.258727] Call Trace:
[414675.258732]  [] schedule+0x33/0x80
[414675.258736]  [] schedule_preempt_disabled+0xe/0x10
[414675.258741]  [] __mutex_lock_slowpath+0x95/0x110
[414675.258745]  [] mutex_lock+0x1f/0x30
[414675.258756]  []
btrfs_wait_ordered_roots+0x42/0x1d0 [btrfs]
[414675.258764]  []
btrfs_check_data_free_space+0x1ff/0x2f0 [btrfs]
[414675.258772]  [] __btrfs_buffered_write+0x13f/0x5a0 [btrfs]
[414675.258774]  [] ? tcp_recvmsg+0x3d1/0xb70
[414675.258783]  [] btrfs_file_write_iter+0x171/0x560 [btrfs]
[414675.258785]  [] ? sock_recvmsg+0x3b/0x50
[414675.258787]  [] __vfs_write+0xa7/0xf0
[414675.258790]  [] vfs_write+0xa6/0x1a0
[414675.258791]  [] ? ktime_get_ts64+0x45/0xf0
[414675.258793]  [] SyS_write+0x46/0xa0
[414675.258795]  [] entry_SYSCALL_64_fastpath+0x16/0x75
[414675.258812] INFO: task java:19067 blocked for more than 120 seconds.
[414675.258856]   Not tainted 4.3.0-040300-generic #201511020846
[414675.258898] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[414675.258964] javaD 88081f8d6980 0 19067   2602 0x
[414675.258967]  880056957bb8 0082 88081c2c6200
8810188e
[414675.258968]  880056958000 88101b7627bc 8810188e

[414675.258970]  88101b7627c0 880056957bd0 817af3f3
88101b7627b8
[414675.258972] Call Trace:
[414675.258975]  [] schedule+0x33/0x80
[414675.258977]  [] schedule_preempt_disabled+0xe/0x10
[414675.258979]  [] __mutex_lock_slowpath+0x95/0x110
[414675.258981]  [] mutex_lock+0x1f/0x30
[414675.258992]  []
btrfs_wait_ordered_roots+0x42/0x1d0 [btrfs]
[414675.259003]  []
btrfs_check_data_free_space+0x1ff/0x2f0 [btrfs]
[414675.259013]  [] __btrfs_buffered_write+0x13f/0x5a0 [btrfs]
[414675.259019]  [] ? security_inode_need_killpriv+0x33/0x50
[414675.259029]  [] btrfs_file_write_iter+0x171/0x560 [btrfs]
[414675.259035]  [] __vfs_write+0xa7/0xf0
[414675.259040]  [] vfs_write+0xa6/0x1a0
[414675.259046]  [] ? __do_page_fault+0x1b4/0x400
[414675.259051]  [] SyS_write+0x46/0xa0
[414675.259055]  [] entry_SYSCALL_64_fastpath+0x16/0x75

regards
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs is amazing! (a lack-of-bug report)

2015-08-20 Thread Austin S Hemmelgarn


On 2015-08-20 07:52, Austin S Hemmelgarn wrote:

On 2015-08-19 13:24, Tyler Bletsch wrote:

Thanks.  I'd consider raid6, but since I'll be backing up to a second
btrfs raid5 array, I think I have sufficient redundancy, since
equivalent to raid 5+1 on paper. I'm doing that rather than something
like raid10 in a single box because I want the redundancy of a second
physical server so I can failover in the event of a system-level
component failure.

(And of course, failover means continue being able to watch TV shows
and stuff)

A question about what you said -- when you say people have hit bugs in
the raid56 code, which flavor do these bugs tend to be? Are they
minding my own business and suddenly it falls over bugs or I tried to
do something weird with btrfs and it screwed up bugs?

More along the lines of 'I tried to do something that works fine with
the other raid profiles and it kind of messed up the filesystem'.  In
general, you should be safe as long as you are using at least Linux 4.0
and the most recent version of btrfs-progs.  It's been a while since I
saw any raid56 related bugs that caused actual data loss.  If you are
using this on SSD's though, I would wait, there are known issues with
DISCARD/TRIM not working correctly on btrfs right now (nothing involving
data loss, just problems with it not properly trimming free space and
therefore causing issues with wear-leveling), and it looks like the fix
won't be in 4.2 as of right now.



On second thought, you might want to wait until 4.3, I just saw this thread:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/47321/focus=47325



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Btrfs is amazing! (a lack-of-bug report)

2015-08-20 Thread Austin S Hemmelgarn


On 2015-08-19 13:24, Tyler Bletsch wrote:

Thanks.  I'd consider raid6, but since I'll be backing up to a second
btrfs raid5 array, I think I have sufficient redundancy, since
equivalent to raid 5+1 on paper. I'm doing that rather than something
like raid10 in a single box because I want the redundancy of a second
physical server so I can failover in the event of a system-level
component failure.

(And of course, failover means continue being able to watch TV shows
and stuff)

A question about what you said -- when you say people have hit bugs in
the raid56 code, which flavor do these bugs tend to be? Are they
minding my own business and suddenly it falls over bugs or I tried to
do something weird with btrfs and it screwed up bugs?
More along the lines of 'I tried to do something that works fine with 
the other raid profiles and it kind of messed up the filesystem'.  In 
general, you should be safe as long as you are using at least Linux 4.0 
and the most recent version of btrfs-progs.  It's been a while since I 
saw any raid56 related bugs that caused actual data loss.  If you are 
using this on SSD's though, I would wait, there are known issues with 
DISCARD/TRIM not working correctly on btrfs right now (nothing involving 
data loss, just problems with it not properly trimming free space and 
therefore causing issues with wear-leveling), and it looks like the fix 
won't be in 4.2 as of right now.





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Btrfs is amazing! (a lack-of-bug report)

2015-08-20 Thread Tyler Bletsch


(Resending to list as plaintext (*correctly* this time))

I see. I'll probably make the backup array a raid10 then.

If/when I do see a disk failure on the raid5, are there any specific 
steps it would be helpful for me to take to capture the state so you 
folks can have a useful bug report?


I plan to run the latest stock kernel from the mainline kernel ppa on 
Ubuntu, with btrfs-progs coming from the git.


- Tyler

On 8/20/2015 8:16 AM, Donald Pearson wrote:


Raid56 works fine until you have a drive with problems which really 
means it doesn't work because you only use parity to handle the case 
of a drive with problems.


Maintenance procedures such as scrubs are also a magnitude of order 
slower than the other raid profiles.


I would use the raid10 profile on at least one of your pools.

On Aug 20, 2015 7:03 AM, Austin S Hemmelgarn ahferro...@gmail.com 
mailto:ahferro...@gmail.com wrote:


On 2015-08-20 07:52, Austin S Hemmelgarn wrote:

On 2015-08-19 13:24, Tyler Bletsch wrote:

Thanks.  I'd consider raid6, but since I'll be backing up
to a second
btrfs raid5 array, I think I have sufficient redundancy, since
equivalent to raid 5+1 on paper. I'm doing that rather
than something
like raid10 in a single box because I want the redundancy
of a second
physical server so I can failover in the event of a
system-level
component failure.

(And of course, failover means continue being able to
watch TV shows
and stuff)

A question about what you said -- when you say people have
hit bugs in
the raid56 code, which flavor do these bugs tend to be?
Are they
minding my own business and suddenly it falls over bugs
or I tried to
do something weird with btrfs and it screwed up bugs?

More along the lines of 'I tried to do something that works
fine with
the other raid profiles and it kind of messed up the
filesystem'.  In
general, you should be safe as long as you are using at least
Linux 4.0
and the most recent version of btrfs-progs.  It's been a while
since I
saw any raid56 related bugs that caused actual data loss. If
you are
using this on SSD's though, I would wait, there are known
issues with
DISCARD/TRIM not working correctly on btrfs right now (nothing
involving
data loss, just problems with it not properly trimming free
space and
therefore causing issues with wear-leveling), and it looks
like the fix
won't be in 4.2 as of right now.


On second thought, you might want to wait until 4.3, I just saw
this thread:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/47321/focus=47325



--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs is amazing! (a lack-of-bug report)

2015-08-19 Thread Tyler Bletsch

Thanks.  I'd consider raid6, but since I'll be backing up to a second 
btrfs raid5 array, I think I have sufficient redundancy, since 
equivalent to raid 5+1 on paper. I'm doing that rather than something 
like raid10 in a single box because I want the redundancy of a second 
physical server so I can failover in the event of a system-level 
component failure.


(And of course, failover means continue being able to watch TV shows 
and stuff)


A question about what you said -- when you say people have hit bugs in 
the raid56 code, which flavor do these bugs tend to be? Are they 
minding my own business and suddenly it falls over bugs or I tried to 
do something weird with btrfs and it screwed up bugs?


Thanks,
Tyler

On 8/18/2015 7:42 AM, Austin S Hemmelgarn wrote:

On 2015-08-17 15:18, Tyler Bletsch wrote:

Thanks. I will be trying raid5 in production, but production in this
case just means my home file server, with btrfs snapshot+sync for all
data and appropriate offsite non-btrfs backups for critical data. If it
hoses up, I'll post a bug report.
So far, that's been my use case for btrfs raid6, and (barring one bug 
I found involving an interaction between btrfs and thinly provisioned 
storage that shouldn't be an issue for you if you're not using LVM 
thin pools) I have yet to hit any bugs, although based on the lists, 
I've probably been _very_ lucky in that respect.  If you're willing to 
take a marginal performance hit (about 1-3% in my experience, which is 
notably less than the performance difference between MD-RAID5 and 
MD-RAID6), and have at least four disks, I'd suggest using btrfs's 
raid6 profile instead of raid5, they use exactly the same code, it's 
just that raid6 has one more calculation involved and provides better 
protection against data corruption due to the double parity.


Going to try to avoid LVM, since half the appeal of btrfs for me is
getting away from the multiple duct-taped layers of indirection that I
you get currently with ext4/MD/LVM setups.
Understandable, my main reasons for having LVM are storing virtual 
machine disk images and the fact that MD/DM raid is still ridiculously 
fast compared to btrfs raid (many of my btrfs raid volumes are 
themselves on top of LVM managed software raid0 or raid1 volumes).





--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs is amazing! (a lack-of-bug report)

2015-08-18 Thread Austin S Hemmelgarn


On 2015-08-17 15:18, Tyler Bletsch wrote:

Thanks. I will be trying raid5 in production, but production in this
case just means my home file server, with btrfs snapshot+sync for all
data and appropriate offsite non-btrfs backups for critical data. If it
hoses up, I'll post a bug report.
So far, that's been my use case for btrfs raid6, and (barring one bug I 
found involving an interaction between btrfs and thinly provisioned 
storage that shouldn't be an issue for you if you're not using LVM thin 
pools) I have yet to hit any bugs, although based on the lists, I've 
probably been _very_ lucky in that respect.  If you're willing to take a 
marginal performance hit (about 1-3% in my experience, which is notably 
less than the performance difference between MD-RAID5 and MD-RAID6), and 
have at least four disks, I'd suggest using btrfs's raid6 profile 
instead of raid5, they use exactly the same code, it's just that raid6 
has one more calculation involved and provides better protection against 
data corruption due to the double parity.


Going to try to avoid LVM, since half the appeal of btrfs for me is
getting away from the multiple duct-taped layers of indirection that I
you get currently with ext4/MD/LVM setups.
Understandable, my main reasons for having LVM are storing virtual 
machine disk images and the fact that MD/DM raid is still ridiculously 
fast compared to btrfs raid (many of my btrfs raid volumes are 
themselves on top of LVM managed software raid0 or raid1 volumes).





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Btrfs is amazing! (a lack-of-bug report)

2015-08-17 Thread Austin S Hemmelgarn


On 2015-08-16 23:35, Tyler Bletsch wrote:

I just wanted to drop you guys a line to say that I am stunned with how
excellent btrfs is. I did some testing, and the things that it did were
amazing. I took a 4-disk RAID 5 and walked it all the way down to a
one-disk volume and back again, mixed in devices of different sizes in
different modes, balanced it in every direction, trashed data on drives
without the OS knowing, and did every other form of torture I could
think of, all while looping file integrity tests, and it was perfect.

The ease of use and simplicity were great.  I was dreading having to
administer ZFS in order to get snapshots and other features, but now I
don't have to. With the exception of enterprisey features like SSD
intent logs and stuff, it is hands down far better than ZFS.

Thanks for the great work!

It's nice to hear success stories for once.  I would suggest being 
careful of using BTRFS raid5 or raid6 in production, there are probably 
still bugs that haven't yet been discovered.  Secondarily, if you can 
deal with slightly more setup and maintenance overhead, BTRFS works 
_very_ well on top of LVM (it makes online data migration much easier, 
and provides easy ways to do layered RAID setups).





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Btrfs is amazing! (a lack-of-bug report)

2015-08-17 Thread Tyler Bletsch

Thanks. I will be trying raid5 in production, but production in this 
case just means my home file server, with btrfs snapshot+sync for all 
data and appropriate offsite non-btrfs backups for critical data. If it 
hoses up, I'll post a bug report.


Going to try to avoid LVM, since half the appeal of btrfs for me is 
getting away from the multiple duct-taped layers of indirection that I 
you get currently with ext4/MD/LVM setups.


- Tyler

On 8/17/2015 7:48 AM, Austin S Hemmelgarn wrote:

On 2015-08-16 23:35, Tyler Bletsch wrote:

I just wanted to drop you guys a line to say that I am stunned with how
excellent btrfs is. I did some testing, and the things that it did were
amazing. I took a 4-disk RAID 5 and walked it all the way down to a
one-disk volume and back again, mixed in devices of different sizes in
different modes, balanced it in every direction, trashed data on drives
without the OS knowing, and did every other form of torture I could
think of, all while looping file integrity tests, and it was perfect.

The ease of use and simplicity were great.  I was dreading having to
administer ZFS in order to get snapshots and other features, but now I
don't have to. With the exception of enterprisey features like SSD
intent logs and stuff, it is hands down far better than ZFS.

Thanks for the great work!

It's nice to hear success stories for once.  I would suggest being 
careful of using BTRFS raid5 or raid6 in production, there are 
probably still bugs that haven't yet been discovered. Secondarily, if 
you can deal with slightly more setup and maintenance overhead, BTRFS 
works _very_ well on top of LVM (it makes online data migration much 
easier, and provides easy ways to do layered RAID setups).





--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Btrfs is amazing! (a lack-of-bug report)

2015-08-16 Thread Tyler Bletsch

I just wanted to drop you guys a line to say that I am stunned with how 
excellent btrfs is. I did some testing, and the things that it did were 
amazing. I took a 4-disk RAID 5 and walked it all the way down to a 
one-disk volume and back again, mixed in devices of different sizes in 
different modes, balanced it in every direction, trashed data on drives 
without the OS knowing, and did every other form of torture I could 
think of, all while looping file integrity tests, and it was perfect.


The ease of use and simplicity were great.  I was dreading having to 
administer ZFS in order to get snapshots and other features, but now I 
don't have to. With the exception of enterprisey features like SSD 
intent logs and stuff, it is hands down far better than ZFS.


Thanks for the great work!

Regards,
Tyler Bletsch
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug report - btrfs hanging

2015-08-03 Thread Chris Murphy

On Mon, Aug 3, 2015 at 12:09 PM, Alex alexinbeij...@gmail.com wrote:

 20:03 ~ % uname -a
 Linux alex-ThinkPad-L530 4.1.0-rc3+ #2 SMP Sun Jul 5 22:24:05 CAT 2015
 x86_64 x86_64 x86_64 GNU/Linux

4.1.0 is not mainline anymore, so I don't see a mid release candidate
of it being relevant because those rc's become old inside of a
couple weeks. I suggest using 4.1.4 which is the current stable
version of that series, and it has quite a few Btrfs patches.

4.2.0rc5 is current mainline and you could test against that too if you wish.


-- 
Chris Murphy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fwd: Bug report - btrfs hanging

2015-08-03 Thread Alex

Dear Btrfs devs,

I have an external HD formatted with btrfs, and have noticed that
various operations (copying files, deleting files, etc) hang from time
to time. Here's debug output from the latest hang:

dmesg output:

[496960.834080] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[496960.834192] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[496960.834261] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[496960.834334] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[496960.834357] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[496960.834658] pci_bus :01: Allocating resources
[496960.834719] pci_bus :06: Allocating resources
[496960.834777] pci_bus :07: Allocating resources
[496960.834807] pci_bus :0c: Allocating resources
[496960.834833] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[496960.834976] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[496960.835140] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[501706.637861] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[501706.638005] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[501706.638114] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[501706.638224] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[501706.638261] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[501706.638650] pci_bus :01: Allocating resources
[501706.638760] pci_bus :06: Allocating resources
[501706.638821] pci_bus :07: Allocating resources
[501706.638851] pci_bus :0c: Allocating resources
[501706.638878] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[501706.639022] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[501706.639226] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]
has bogus alignment
[503148.505218] usb 4-1.5: new high-speed USB device number 4 using ehci-pci
[503148.659324] usb 4-1.5: New USB device found, idVendor=0480, idProduct=a200
[503148.659332] usb 4-1.5: New USB device strings: Mfr=2, Product=3,
SerialNumber=1
[503148.659336] usb 4-1.5: Product: External USB 3.0
[503148.659340] usb 4-1.5: Manufacturer: TOSHIBA
[503148.659343] usb 4-1.5: SerialNumber: 20140919001100F
[503148.659996] usb-storage 4-1.5:1.0: USB Mass Storage device detected
[503148.660322] scsi host10: usb-storage 4-1.5:1.0
[503149.659297] scsi 10:0:0:0: Direct-Access TOSHIBA  External USB
3.0 0PQ: 0 ANSI: 6
[503149.660108] sd 10:0:0:0: Attached scsi generic sg2 type 0
[503151.230437] sd 10:0:0:0: [sdb] 1953525168 512-byte logical blocks:
(1.00 TB/931 GiB)
[503151.231640] sd 10:0:0:0: [sdb] Write Protect is off
[503151.231658] sd 10:0:0:0: [sdb] Mode Sense: 43 00 00 00
[503151.232815] sd 10:0:0:0: [sdb] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[503151.255437] sd 10:0:0:0: [sdb] Attached SCSI disk
[503151.491833] BTRFS: device label AlexEHD devid 1 transid 889 /dev/sdb
[503151.876617] BTRFS info (device sdb): disk space caching is enabled
[503371.659804] INFO: task cinnamon-settin:2211 blocked for more than
120 seconds.
[503371.659817]   Not tainted 4.1.0-rc3+ #2
[503371.659821] echo 0  /proc/sys/kernel/hung_task_timeout_secs
disables this message.
[503371.659835] cinnamon-settin D 880213cdbca8 0  2211   2117 0x
[503371.659848]  880213cdbca8 880215e56480 8802032e1920
88015afb6054
[503371.659856]  880213cdc000 880207f3be4c 8802032e1920

[503371.659863]  880207f3be50 880213cdbcc8 8179bd27
8802030bc000
[503371.659868] Call Trace:
[503371.659882]  [8179bd27] schedule+0x37/0x90
[503371.659898]  [8179c05e] schedule_preempt_disabled+0xe/0x10
[503371.659903]  [8179dc45] __mutex_lock_slowpath+0x95/0x110
[503371.659908]  [8179dce3] mutex_lock+0x23/0x37
[503371.659946]  [a027efcb] btrfs_show_devname+0x2b/0xe0 [btrfs]
[503371.659953]  [81229ccf] show_vfsmnt+0x3f/0x150
[503371.659958]  [81209846] m_show+0x16/0x20
[503371.659962]  [8120ee18] seq_read+0x218/0x370
[503371.659968]  [811ea568] __vfs_read+0x28/0xe0
[503371.659973]  [8130cc74] ? security_file_permission+0x84/0xa0
[503371.659977]  [811eaac6] ? rw_verify_area+0x56/0xe0
[503371.659982]  [811eabd6] vfs_read+0x86/0x140
[503371.659986]  [811eba56] SyS_read+0x46/0xb0
[503371.659992]  [81177903] ? context_tracking_user_enter+0x13/0x20
[503371.659997]  [81024bb5] ? syscall_trace_leave+0xa5/0x120
[503371.660001]  [8179ffb2] system_call_fastpath+0x16/0x75
[503371.660064] INFO: task btrfs-transacti:32320 blocked for more than
120 seconds.
[503371.660069]   Not tainted

Bug Report Data Rescue: btrfs send ... btrfs set prop on linux 3.18-2 on Arch Linux

2015-01-26 Thread Juergen Sauer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Moin,

this weekend a ssd disk got an problem.

No Problem, I thought... but real word acts sometime other the you think :)

1. Szenario
I got an media Error on a ssd disk. So, I think trimming the whole
device may work.
Mounting the btrfs in rw is not possible anymore. Because the system is
going to write on damaged blocks.

Mounting ro is possible.
So I tried to
mount -o ro,subvol=/ /dev/sdl1 /mnt - worked.

The Try to send the ro-mounted subvol rootfs, which I want to recover
did not work:
btrfs send -f /srv/backup/rootfs.btrfs rootfs
ERROR: /mnt/rootfs is not read-only

The try to change the ro-flag
btrfs prop set rootfs ro true
ERROR: failed to set flags for rootfs. Read-only file system

was impossible.

I think this is an Bug in btrfs send, not to check if an btrfs
filesystem is mounted ro for refusing working.

It may be much more easier to recover damaged systems, if such annoying
thngs would not occour.

mit freundlichen Grüßen
Jürgen Sauer
- -- 
Jürgen Sauer - automatiX GmbH,
+49-4209-4699, juergen.sa...@automatix.de
Geschäftsführer: Jürgen Sauer,
Gerichtstand: Amtsgericht Walsrode • HRB 120986
Ust-Id: DE191468481 • St.Nr.: 36/211/08000
GPG Public Key zur Signaturprüfung:
http://www.automatix.de/juergen_sauer_publickey.gpg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlTGMCEACgkQW7UKI9EqarG8QwCgu80ihnBxKrnjy4rzzbrz6Riu
wS0AoIEiNicS/6Zz12ct7T4fZncW5xsP
=3PPi
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug Report Data Rescue: btrfs send ... btrfs set prop on linux 3.18-2 on Arch Linux

2015-01-26 Thread Duncan

Juergen Sauer posted on Mon, 26 Jan 2015 13:16:33 +0100 as excerpted:

 I think this is an Bug in btrfs send, not to check if an btrfs
 filesystem is mounted ro for refusing working.
 
 It may be much more easier to recover damaged systems, if such annoying
 thngs would not occour.

That has been noted before, and is indeed considered a bug.

The problem is that in normal circumstances, a read-only mount wasn't 
considered secure enough, because the user could make it writable while 
the send was underway, causing the send to fail.

But at minimum, there needs to be a way to do a send from a forced-read-
only filesystem, you are correct, thus the bug.

I don't know whether they plan to relax the requirement and live with the 
chance of a user making it writable (admin responsibility, admin breaks 
the send, admin gets to keep the pieces), or if they plan to add an 
attribute to force-read-only so it can be distinguished from user-mounted-
read-only, in which case forced-read-only could be considered sufficient 
for a send.

But indeed, the current situation is acknowledged to be less than ideal 
by the devs, which will probably do something about it at some point, 
based on comments.  I don't know how soon that some point might be, 
however...

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bug report: softlockup hung task

2014-04-21 Thread ylet ylet

Does anyone encounter this problem? and dose anyone have solution to it?

Today, I have changed the compress max size from 512KB to 16KB:

in cow_file_range_async function,

cur_end = min(end, start + 512 * 1024 - 1);
--
cur_end = min(end, start + 16 * 1024 - 1);

This bug can be reproduced almost every time in my environment.

2014-04-19 20:13 GMT+08:00 ylet ylet levin.fr...@gmail.com:
 I tried the latest git pull for linus(2014-04-12). The softlockup bug still
 exists.

 I ran IOZONE in performance test with zlib mount option:
 mount -t btrfs -o nospace_cache -o compress-force=zlib -o enospc_debug
 /dev/sdb /mnt/btrfs

 My PC has i5 4-core CPU, 8GB mem and a 256GB SSD.

  The iozone configuration is as follow:
 ./iozone -s 16g -i 0 -i 1 -i 2 -t 4 -r 4k -+w 50 -+y 20 -+C 60 -F
 /mnt/btrfs/test1 /mnt/btrfs/test2 /mnt/btrfs/test3 /mnt/btrfs/test

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bug report: softlockup hung task

2014-04-19 Thread ylet ylet

I tried the latest git pull for linus(2014-04-12). The softlockup bug
still exists.

I ran IOZONE in performance test with zlib mount option:
mount -t btrfs -o nospace_cache -o compress-force=zlib -o enospc_debug
/dev/sdb /mnt/btrfs

My PC has i5 4-core CPU, 8GB mem and a 256GB SSD.

 The iozone configuration is as follow:
./iozone -s 16g -i 0 -i 1 -i 2 -t 4 -r 4k -+w 50 -+y 20 -+C 60 -F
/mnt/btrfs/test1 /mnt/btrfs/test2 /mnt/btrfs/test3 /mnt/btrfs/test

2014-04-19 20:13 GMT+08:00 ylet ylet levin.fr...@gmail.com:
 I tried the latest git pull for linus(2014-04-12). The softlockup bug still
 exists.

 I ran IOZONE in performance test with zlib mount option:
 mount -t btrfs -o nospace_cache -o compress-force=zlib -o enospc_debug
 /dev/sdb /mnt/btrfs

 My PC has i5 4-core CPU, 8GB mem and a 256GB SSD.

  The iozone configuration is as follow:
 ./iozone -s 16g -i 0 -i 1 -i 2 -t 4 -r 4k -+w 50 -+y 20 -+C 60 -F
 /mnt/btrfs/test1 /mnt/btrfs/test2 /mnt/btrfs/test3 /mnt/btrfs/test

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bedup bug report

2014-02-12 Thread Marc MERLIN

Does anyone know who the maintainer to send bug reports to, is?

On Sat, Feb 08, 2014 at 09:19:36PM -0800, Marc MERLIN wrote:
 kernel 3.12.7, python 2.7.6-5, debian testing/unstable, bedup installed as per
 pip install --user bedup
 
 I tried installing the git version, but the error is the same:
 
 Anyway, with the other bedup, I get:
 gargamel:/mnt/dshelf2/backup# bedup show
 Traceback (most recent call last):
   File /usr/local/bin/bedup, line 9, in module
 load_entry_point('bedup==0.9.0', 'console_scripts', 'bedup')()
   File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 
 483, in script_main
 sys.exit(main(sys.argv))
   File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 
 472, in main
 return args.action(args)
   File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 70, 
 in cmd_show_vols
 sess = get_session(args)
   File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 
 105, in get_session
 upgrade_schema(engine, database_exists)
   File /root/.local/lib/python2.7/site-packages/bedup/migrations.py, line 
 38, in upgrade_schema
 context = MigrationContext.configure(engine.connect())
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/engine/base.py, 
 line 1678, in connect
 return self._connection_cls(self, **kwargs)
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/engine/base.py, 
 line 59, in __init__
 self.__connection = connection or engine.raw_connection()
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/engine/base.py, 
 line 1747, in raw_connection
 return self.pool.unique_connection()
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 
 272, in unique_connection
 return _ConnectionFairy._checkout(self)
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 
 608, in _checkout
 fairy = _ConnectionRecord.checkout(pool)
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 
 425, in checkout
 rec = pool._do_get()
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 
 838, in _do_get
 c = self._create_connection()
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 
 277, in _create_connection
 return _ConnectionRecord(self)
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 
 402, in __init__
 pool.dispatch.connect(self.connection, self)
   File /root/.local/lib/python2.7/site-packages/sqlalchemy/event/attr.py, 
 line 247, in __call__
 fn(*args, **kw)
   File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 89, 
 in sql_setup
 assert val == ('wal',), val
 AssertionError: (u'delete',)
 
 gargamel:/mnt/dshelf2/backup# bedup dedup --db-path dedup --defrag .
 also fails the same way
 
 Last thing that happens is
 open(/usr/lib/python2.7/lib-tk/_sqlite3module.so, O_RDONLY|O_LARGEFILE) = 
 -1 ENOENT (No such file or directory)
 open(/usr/lib/python2.7/lib-tk/_sqlite3.py, O_RDONLY|O_LARGEFILE) = -1 
 ENOENT (No such file or directory)
 open(/usr/lib/python2.7/lib-tk/_sqlite3.pyc, O_RDONLY|O_LARGEFILE) = -1 
 ENOENT (No such file or directory)
 stat64(/usr/lib/python2.7/lib-dynload/_sqlite3, 0xff921890) = -1 ENOENT (No 
 such file or directory)
 open(/usr/lib/python2.7/lib-dynload/_sqlite3.i386-linux-gnu.so, 
 O_RDONLY|O_LARGEFILE) = 5
 open(/usr/lib/python2.7/lib-dynload/_sqlite3.i386-linux-gnu.so, 
 O_RDONLY|O_CLOEXEC) = 6
 open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 6
 access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or 
 directory)
 open(/usr/lib/libsqlite3.so.0, O_RDONLY|O_CLOEXEC) = 6
 getcwd(/mnt/dshelf2/backup, 1024) = 20
 stat64(/mnt/dshelf2/backup/dedup, {st_mode=S_IFREG|0644, st_size=0, ...}) =  0
 open(/mnt/dshelf2/backup/dedup, O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3
 Traceback (most recent call last):
   File /usr/local/bin/bedup, line 9, in module
 open(/usr/local/bin/bedup, O_RDONLY|O_LARGEFILE) = 4
 load_entry_point('bedup==0.9.0', 'console_scripts', 'bedup')()
   File 
 /root/.local/lib/python2.7/site-packages/bedup-0.9.0-py2.7-linux-x86_64.egg/bedup/__main__.py,
  line 487, in script_main
 (...)
 
 Any suggestions?
 
 Thanks,
 Marc
 -- 
 A mouse is a device used to point at the xterm you want to type in - A.S.R.
 Microsoft is to operating systems 
    what McDonalds is to gourmet 
 cooking
 Home page: http://marc.merlins.org/  
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
To

Re: Bedup bug report

2014-02-12 Thread David Sterba

On Wed, Feb 12, 2014 at 05:46:02AM -0800, Marc MERLIN wrote:
 Does anyone know who the maintainer to send bug reports to, is?

g2p.c...@gmail.com
https://github.com/g2p/bedup
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bedup bug report

2014-02-08 Thread Marc MERLIN

kernel 3.12.7, python 2.7.6-5, debian testing/unstable, bedup installed as per
pip install --user bedup

I tried installing the git version, but the error is the same:

Anyway, with the other bedup, I get:
gargamel:/mnt/dshelf2/backup# bedup show
Traceback (most recent call last):
  File /usr/local/bin/bedup, line 9, in module
load_entry_point('bedup==0.9.0', 'console_scripts', 'bedup')()
  File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 483, 
in script_main
sys.exit(main(sys.argv))
  File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 472, 
in main
return args.action(args)
  File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 70, 
in cmd_show_vols
sess = get_session(args)
  File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 105, 
in get_session
upgrade_schema(engine, database_exists)
  File /root/.local/lib/python2.7/site-packages/bedup/migrations.py, line 38, 
in upgrade_schema
context = MigrationContext.configure(engine.connect())
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/engine/base.py, 
line 1678, in connect
return self._connection_cls(self, **kwargs)
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/engine/base.py, 
line 59, in __init__
self.__connection = connection or engine.raw_connection()
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/engine/base.py, 
line 1747, in raw_connection
return self.pool.unique_connection()
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 272, 
in unique_connection
return _ConnectionFairy._checkout(self)
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 608, 
in _checkout
fairy = _ConnectionRecord.checkout(pool)
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 425, 
in checkout
rec = pool._do_get()
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 838, 
in _do_get
c = self._create_connection()
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 277, 
in _create_connection
return _ConnectionRecord(self)
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/pool.py, line 402, 
in __init__
pool.dispatch.connect(self.connection, self)
  File /root/.local/lib/python2.7/site-packages/sqlalchemy/event/attr.py, 
line 247, in __call__
fn(*args, **kw)
  File /root/.local/lib/python2.7/site-packages/bedup/__main__.py, line 89, 
in sql_setup
assert val == ('wal',), val
AssertionError: (u'delete',)

gargamel:/mnt/dshelf2/backup# bedup dedup --db-path dedup --defrag .
also fails the same way

Last thing that happens is
open(/usr/lib/python2.7/lib-tk/_sqlite3module.so, O_RDONLY|O_LARGEFILE) = -1 
ENOENT (No such file or directory)
open(/usr/lib/python2.7/lib-tk/_sqlite3.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT 
(No such file or directory)
open(/usr/lib/python2.7/lib-tk/_sqlite3.pyc, O_RDONLY|O_LARGEFILE) = -1 
ENOENT (No such file or directory)
stat64(/usr/lib/python2.7/lib-dynload/_sqlite3, 0xff921890) = -1 ENOENT (No 
such file or directory)
open(/usr/lib/python2.7/lib-dynload/_sqlite3.i386-linux-gnu.so, 
O_RDONLY|O_LARGEFILE) = 5
open(/usr/lib/python2.7/lib-dynload/_sqlite3.i386-linux-gnu.so, 
O_RDONLY|O_CLOEXEC) = 6
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 6
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/usr/lib/libsqlite3.so.0, O_RDONLY|O_CLOEXEC) = 6
getcwd(/mnt/dshelf2/backup, 1024) = 20
stat64(/mnt/dshelf2/backup/dedup, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open(/mnt/dshelf2/backup/dedup, O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3
Traceback (most recent call last):
  File /usr/local/bin/bedup, line 9, in module
open(/usr/local/bin/bedup, O_RDONLY|O_LARGEFILE) = 4
load_entry_point('bedup==0.9.0', 'console_scripts', 'bedup')()
  File 
/root/.local/lib/python2.7/site-packages/bedup-0.9.0-py2.7-linux-x86_64.egg/bedup/__main__.py,
 line 487, in script_main
(...)

Any suggestions?

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG REPORT] Kernel panic on 3.9.0-rc7-4-gbb33db7

2013-04-19 Thread Tejun Heo

On Thu, Apr 18, 2013 at 10:57:54PM -0700, Tejun Heo wrote:
 No wonder this thing crashes.  Chris, can't the original bio carry
 bbio in bi_private and let end_bio_extent_readpage() free the bbio
 instead of abusing bi_bdev like this?

BTW, I think it's a bit too late to fix this properly from btrfs side
unless we're gonna do -rc8, so let's revert the TP patch for now and
sort this out in the next devel cycle.  AFAICS, while disturbingly
(ha|yu)cky, the bi_bdev trick should be okay without the new TP.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG REPORT] Kernel panic on 3.9.0-rc7-4-gbb33db7

2013-04-19 Thread Wanlong Gao

On 04/19/2013 02:17 PM, Tejun Heo wrote:
 On Thu, Apr 18, 2013 at 10:57:54PM -0700, Tejun Heo wrote:
 No wonder this thing crashes.  Chris, can't the original bio carry
 bbio in bi_private and let end_bio_extent_readpage() free the bbio
 instead of abusing bi_bdev like this?
 
 BTW, I think it's a bit too late to fix this properly from btrfs side
 unless we're gonna do -rc8, so let's revert the TP patch for now and
 sort this out in the next devel cycle.  AFAICS, while disturbingly
 (ha|yu)cky, the bi_bdev trick should be okay without the new TP.

Thank you for investigating this. And sorry for my incompleted panic picture
before that let you detour. :-(

Regards,
Wanlong Gao

 
 Thanks.
 

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG REPORT] Kernel panic on 3.9.0-rc7-4-gbb33db7

2013-04-19 Thread Jan Schmidt

On Fri, April 19, 2013 at 07:57 (+0200), Tejun Heo wrote:
 (cc'ing btrfs people)
 
 On Fri, Apr 19, 2013 at 11:33:20AM +0800, Wanlong Gao wrote:
 RIP: 0010:[812484d3]  [812484d3] 
 ftrace_raw_event_block_bio_complete+0x73/0xf0
 ...
  [811b6c10] bio_endio+0x80/0x90
  [a0790d26] btrfs_end_bio+0xf6/0x190 [btrfs]
  [811b6bcd] bio_endio+0x3d/0x90
  [81249873] req_bio_endio+0xa3/0xe0
 
 Ugh
 
 In fs/btrfs/volumes.c
 
   static void bbio_error(struct btrfs_bio *bbio, struct bio *bio, u64 logical)
   {
   ...
   bio-bi_bdev = (struct block_device *)
  (unsigned long)bbio-mirror_num;
   ...
   }
 
   static void btrfs_end_bio(struct bio *bio, int err)
   {
   ...
   bio-bi_bdev = (struct block_device *)
   (unsigned long)bbio-mirror_num;
   
   ...
   }
 
 In fs/btrfs/extent_io.c
 
   static void end_bio_extent_readpage(struct bio *bio, int err)
   {
   int mirror;
   ...
   mirror = (int)(unsigned long)bio-bi_bdev;
   ...
   }
 
 Ewweehh
 
 No wonder this thing crashes.  Chris, can't the original bio carry
 bbio in bi_private and let end_bio_extent_readpage() free the bbio
 instead of abusing bi_bdev like this?

Oops.

It's been my patch back in 2011 (commit 2774b2ca3), sent as an RFC-Patch and
just slipped in without further discussion of that exact change. Hackish, yes -
my reasoning was because the block layer changed bio-bi_bdev anyway, no one
would want to look into it after the bio returned (and in fact it didn't hurt
for like two years now). Although the block layer changes bi_bdev, it stays a
valid bdev pointer, I admit.

One way around this would be what you suggest, however that would mean the
caller of (btrfs|btree)_submit_bio_hook gets its completion called in the end,
but must know that the private is in fact a bbio which in turn carries the
caller's private. Doesn't sound clean to me, either.

The best idea I currently have is to add a dispatcher function that does the
freeing of bbio and calls the actual completion with mirror_num as a separate
parameter. That would make all the btrfs completions incompatible with
bio_end_io_t, but it shouldn't hurt.

At least now I know I wasn't invited to LSF for a good reason :-)

-Jan
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG REPORT] Kernel panic on 3.9.0-rc7-4-gbb33db7

2013-04-19 Thread Chris Mason

Quoting Tejun Heo (2013-04-19 01:57:54)
 
 Ewweehh
 
 No wonder this thing crashes.  Chris, can't the original bio carry
 bbio in bi_private and let end_bio_extent_readpage() free the bbio
 instead of abusing bi_bdev like this?

Yes, we can definitely carry bbio up higher in the stack.  I'll patch it
up right now.  I do agree that it'll be too big for -final, but we'll
have it either way.

-chris

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG REPORT] Kernel panic on 3.9.0-rc7-4-gbb33db7

2013-04-19 Thread Jens Axboe

On Thu, Apr 18 2013, Tejun Heo wrote:
 On Thu, Apr 18, 2013 at 10:57:54PM -0700, Tejun Heo wrote:
  No wonder this thing crashes.  Chris, can't the original bio carry
  bbio in bi_private and let end_bio_extent_readpage() free the bbio
  instead of abusing bi_bdev like this?
 
 BTW, I think it's a bit too late to fix this properly from btrfs side
 unless we're gonna do -rc8, so let's revert the TP patch for now and
 sort this out in the next devel cycle.  AFAICS, while disturbingly
 (ha|yu)cky, the bi_bdev trick should be okay without the new TP.

The tracing commit was already backed out yesterday, so no problems
there. I figured it'd be a bit too late to fix something this nasty in a
suitably clean and straight forward fashion.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG REPORT] Kernel panic on 3.9.0-rc7-4-gbb33db7

2013-04-19 Thread Jens Axboe

On Thu, Apr 18 2013, Tejun Heo wrote:
 (cc'ing btrfs people)
 
 On Fri, Apr 19, 2013 at 11:33:20AM +0800, Wanlong Gao wrote:
  RIP: 0010:[812484d3]  [812484d3] 
  ftrace_raw_event_block_bio_complete+0x73/0xf0
 ...
   [811b6c10] bio_endio+0x80/0x90
   [a0790d26] btrfs_end_bio+0xf6/0x190 [btrfs]
   [811b6bcd] bio_endio+0x3d/0x90
   [81249873] req_bio_endio+0xa3/0xe0
 
 Ugh
 
 In fs/btrfs/volumes.c
 
   static void bbio_error(struct btrfs_bio *bbio, struct bio *bio, u64 logical)
   {
   ...
   bio-bi_bdev = (struct block_device *)
  (unsigned long)bbio-mirror_num;
   ...
   }
 
   static void btrfs_end_bio(struct bio *bio, int err)
   {
   ...
   bio-bi_bdev = (struct block_device *)
   (unsigned long)bbio-mirror_num;
   
   ...
   }
 
 In fs/btrfs/extent_io.c
 
   static void end_bio_extent_readpage(struct bio *bio, int err)
   {
   int mirror;
   ...
   mirror = (int)(unsigned long)bio-bi_bdev;
   ...
   }
 
 Ewweehh
 
 No wonder this thing crashes.  Chris, can't the original bio carry
 bbio in bi_private and let end_bio_extent_readpage() free the bbio
 instead of abusing bi_bdev like this?

Ugh, wtf.

Chris, time for a swim in the bay :-)

-- 
Jens Axboe

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG REPORT] Kernel panic on 3.9.0-rc7-4-gbb33db7

2013-04-19 Thread Chris Mason

Quoting Jens Axboe (2013-04-19 09:32:50)
  
  No wonder this thing crashes.  Chris, can't the original bio carry
  bbio in bi_private and let end_bio_extent_readpage() free the bbio
  instead of abusing bi_bdev like this?
 
 Ugh, wtf.
 
 Chris, time for a swim in the bay :-)

Yeah, I can't really defend this one.  We needed a space for an int and
I assumed end_io meant the FS was free to do horrible things.

Really though, I'll just take a quick dip in the lake and patch this out
of btrfs. 

Jan is probably right about changing around our endio callbacks to
explicitly pass the mirror, it should be less complex and cleaner.

Many thanks to everyone here that tracked it down.

-chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bug report

2012-09-01 Thread Manoel Pedro

Sep  1 20:24:07 sa kernel: [ 8034.244618] [ cut here ]
Sep  1 20:24:07 sa kernel: [ 8034.244638] WARNING: at
/home/abuild/rpmbuild/BUILD/kernel-desktop-3.5.3/linux-3.5/fs/btrfs/extent-tree.c:6221
use_block_rsv+0x15e/0x170 [btrfs]()
Sep  1 20:24:07 sa kernel: [ 8034.244640] Hardware name: Latitude 120L
Sep  1 20:24:07 sa kernel: [ 8034.244642] Modules linked in: loop
af_packet fuse arc4 cpufreq_conservative cpufreq_userspace
cpufreq_powersave b43 mac80211 cfg80211 rfkill bcma iTCO_wdt gpio_ich
iTCO_vendor_support sr_mod cdrom sg b44 dell_laptop usb_storage dcdbas
uas joydev ssb snd_hda_codec_idt mmc_core pcmcia pcmcia_core pcspkr
lpc_ich mfd_core snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
snd_timer battery ac snd soundcore snd_page_alloc acpi_cpufreq mperf
microcode binfmt_misc pciehp pci_hotplug autofs4 i915 drm_kms_helper
drm i2c_algo_bit thermal button video processor thermal_sys
scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh btrfs
zlib_deflate libcrc32c ata_generic ata_piix
Sep  1 20:24:07 sa kernel: [ 8034.244690] Pid: 314, comm:
btrfs-balance Tainted: GW3.5.3-40-desktop #1
Sep  1 20:24:07 sa kernel: [ 8034.244692] Call Trace:
Sep  1 20:24:07 sa kernel: [ 8034.244698]  [c02055b3]
try_stack_unwind+0x173/0x180
Sep  1 20:24:07 sa kernel: [ 8034.244704]  [c02042c7] dump_trace+0x47/0xf0
Sep  1 20:24:07 sa kernel: [ 8034.244709]  [c020560b]
show_trace_log_lvl+0x4b/0x60
Sep  1 20:24:07 sa kernel: [ 8034.244714]  [c0205638] show_trace+0x18/0x20
Sep  1 20:24:07 sa kernel: [ 8034.244720]  [c070e144] dump_stack+0x6d/0x72
Sep  1 20:24:07 sa kernel: [ 8034.244725]  [c0234ea8]
warn_slowpath_common+0x78/0xb0
Sep  1 20:24:07 sa kernel: [ 8034.244730]  [c0234efb]
warn_slowpath_null+0x1b/0x20
Sep  1 20:24:07 sa kernel: [ 8034.244750]  [f7cd8a2e]
use_block_rsv+0x15e/0x170 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.244817]  [f7cdc92c]
btrfs_alloc_free_block+0x3c/0x2a0 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.244888]  [f7cc7ba8]
__btrfs_cow_block+0x158/0x5c0 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.244931]  [f7cc80e9]
btrfs_cow_block+0xd9/0x250 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.244982]  [f7d392e7]
do_relocation+0x447/0x500 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.251298]  [f7d395bc]
relocate_tree_block+0x21c/0x260 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.251567]  [f7d3da8d]
relocate_tree_blocks+0x11d/0x180 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.251841]  [f7d3e89e]
relocate_block_group+0x1fe/0x5a0 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.252125]  [f7d3edea]
btrfs_relocate_block_group+0x1aa/0x300 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.252397]  [f7d19b35]
btrfs_relocate_chunk.isra.51+0x55/0x410 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.252613]  [f7d1e6b2]
btrfs_shrink_device+0x262/0x480 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.252834]  [f7d1e9a1]
__btrfs_balance+0xd1/0x4a0 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.257807]  [f7d1f0f7]
btrfs_balance+0x387/0x550 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.259855]  [f7d1f330]
balance_kthread+0x70/0x80 [btrfs]
Sep  1 20:24:07 sa kernel: [ 8034.260082]  [c02545fe] kthread+0x6e/0x80
Sep  1 20:24:07 sa kernel: [ 8034.260092]  [c072bf66]
kernel_thread_helper+0x6/0xd
Sep  1 20:24:07 sa kernel: [ 8034.260098] ---[ end trace dc79c5cfcfeff6c9 ]---
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: “Bug”-report: inconsistency kernel - tools

2012-08-31 Thread Goffredo Baroncelli


On 08/30/2012 08:24 PM, Goffredo Baroncelli wrote:


And magically the filesystem is now composed by three disks. However 4
physical devices are show. This because the disk /dev/vdi superblock
says that the disk is still valid (after the btrfs device del the disk
is not touched any more)


I have to correct myself. When a device is removed its superblock is 
zero-ed (from btrfs_rm_device():


[...]
/*
 * at this point, the device is zero sized.  We want to
 * remove it from the devices list and zero out the old super
 */
if (clear_super) {
/* make sure this device isn't detected as part of
 * the FS anymore
 */
memset(disk_super-magic, 0, sizeof(disk_super-magic));
set_buffer_dirty(bh);
sync_dirty_buffer(bh);
}
[...]


clear_super is set to true when the device is writeable.



However making a test I found both the behaviours: sometime the removed 
disk disappears from the output of btrfs fi show and sometime not...


May be that there is a bug somewhere...

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[BTRFS-PROGS][BUG][PATCH] Incorrect detection of a removed device [was Re: “Bug”-report: inconsistency kernel - tools]

2012-08-31 Thread Goffredo Baroncelli


Hi all, Yan,

On 08/31/2012 09:08 PM, Goffredo Baroncelli wrote:

However making a test I found both the behaviours: sometime the removed
disk disappears from the output of btrfs fi show and sometime not...

May be that there is a bug somewhere...



I became crazy looking at this bug. I found that a debian package raises 
the bug, but when I compiled the source by hand the bug disappeared... 
Finally I discovered that this bug depends by an uninitialized variable; 
this lead to the unpredictable behaviour.


The problem is that when a device is removed, the function 
btrfs_read_dev_super() should ignore it. In fact the kernel clear the 
magic number in the *first* superblock. However the function 
btrfs_read_dev_super() checks also the backup superblocks and when it 
found a valid one, the function returns success.


Lukely (?) this function fails very often because the fsid of the backup 
superblock are checked against an uninitialized buffer. However when 
this check has success this device is considered suitable even tough it 
was removed.


The BUG is in the function btrfs_read_dev_super():


int btrfs_read_dev_super(int fd, struct btrfs_super_block *sb, u64 
sb_bytenr)

{
u8 fsid[BTRFS_FSID_SIZE];
[...]

line 933:

for (i = 0; i  BTRFS_SUPER_MIRROR_MAX; i++) {
bytenr = btrfs_sb_offset(i);
ret = pread64(fd, buf, sizeof(buf), bytenr);
if (ret  sizeof(buf))
break;

if (btrfs_super_bytenr(buf) != bytenr ||
strncmp((char *)(buf.magic), BTRFS_MAGIC,
sizeof(buf.magic)))
continue;

if (i == 0)
memcpy(fsid, buf.fsid, sizeof(fsid));
else if (memcmp(fsid, buf.fsid, sizeof(fsid)))
continue;

if (btrfs_super_generation(buf)  transid) {
memcpy(sb, buf, sizeof(*sb));
transid = btrfs_super_generation(buf);
}
}


When a device is removed, the *first* superblock magic field is zeroed 
so the first check strncmp((char *)(buf.magic), BTRFS_MAGIC,... fails 
, i is increased, and the continue statement is execute.
Then the check memcmp(fsid became unreliable in the next iteration 
because the fsid variable is not initialized.


To me the test is unclear: what is the purpose to continue when the 
superblocks (the original one and its backup) refer to different fsid: 
there is something wrong which require an user decision...
May be that Yan added this check (see commit 
50860d6e31c28cf4789ef099729dfbce2108620a ) to converting from different 
format ? Yan do you remember something about this code ?


The enclosed patch corrects the initialization of the fsid variable; 
morover if the fsid are different between the superblocks (the original 
one and its backup) the function fails because the device cannot be 
trusted. Finally it is handled the special case when the magic fields is 
zeroed in the *first* superblock. In this case the device is skipped.


BR
G.Baroncelli

--
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it

diff --git a/disk-io.c b/disk-io.c
index b21a87f..82fc3b8 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -910,6 +910,7 @@ struct btrfs_root *open_ctree_fd(int fp, const char 
*path, u64 sb_bytenr,
 int btrfs_read_dev_super(int fd, struct btrfs_super_block *sb, u64 
sb_bytenr)

 {
u8 fsid[BTRFS_FSID_SIZE];
+   int fsid_is_initialized = 0;
struct btrfs_super_block buf;
int i;
int ret;
@@ -936,15 +937,26 @@ int btrfs_read_dev_super(int fd, struct 
btrfs_super_block *sb, u64 sb_bytenr)

if (ret  sizeof(buf))
break;

-   if (btrfs_super_bytenr(buf) != bytenr ||
-   strncmp((char *)(buf.magic), BTRFS_MAGIC,
+   if (btrfs_super_bytenr(buf) != bytenr )
+   continue;
+   /* if magic is NULL, the device was removed */
+   if (buf.magic == 0  i==0)
+   return -1;
+   if (strncmp((char *)(buf.magic), BTRFS_MAGIC,
sizeof(buf.magic)))
continue;

-   if (i == 0)
+   if (!fsid_is_initialized){
memcpy(fsid, buf.fsid, sizeof(fsid));
-   else if (memcmp(fsid, buf.fsid, sizeof(fsid)))
-   continue;
+   fsid_is_initialized = 1;
+   } else if (memcmp(fsid, buf.fsid, sizeof(fsid))) {
+   /*
+* the superblocks (the original one and
+* its backups) contain data of different
+* filesystems - the disk cannot be trusted
+*/
+   return -1;
+   }

if (btrfs_super_generation(buf)

Re: “Bug”-report: inconsistency kernel - tools

2012-08-30 Thread Goffredo Baroncelli


On 08/28/2012 09:52 PM, M G Berberich wrote:

Hello,

We had set up a btrfs-fs over 6 hot-plugable SAS-disks for
testing and got it into a state where kernel and btrfs-tools do not
agree any more about the state of the filesystem.

We do not remember exaclty what we did, but roughly it was something
like this (on the running system). THIS IS FROM MEMORY!

(1) pulled out one disk
(2) removed disk from btrfs
(3) rebalanced btrfs
(4) pulled out another disk
(5) removed disk from btrfs
(6) rebalanced btrfs

This went fine sofar.

(7) reinserted disk (and rebooted)
 At some point before reboot the first 10 sectors of one disk
 were zeroed to test if the disk gets removed from the btrfs.


IIRC the superblock is not placed at the beginning of the disk. On the 
basis of [1] it should be near the 64KB (around the sector #128)



[1] 
https://btrfs.wiki.kernel.org/index.php/User:Wtachi/On-disk_Format#Superblock


Now btrfs-tools showed:

---
# btrfs fi show
failed to read /dev/sr0
Label: 'BTRFS_RAID'  uuid: 807193fd-17de-4088-9a54-3e7cacdc89db
 Total devices 6 FS bytes used 3.07GB
 devid4 size 931.00GB used 75.00GB path /dev/sdf
 devid5 size 931.00GB used 324.03GB path /dev/sde
 devid6 size 931.00GB used 83.03GB path /dev/sdd
 devid3 size 931.00GB used 326.03GB path /dev/sdc
 devid2 size 931.00GB used 326.03GB path /dev/sdb
 devid1 size 931.00GB used 324.04GB path /dev/sda


btrfs filesystem show shows the content of the disks, which could be 
unrelated to the kernel status. Pay attention that if the data is not 
flushed to the disk the report of btrfs fi show could be unreliable.


I posted few days ago a patch which adds the sysfs support to btrfs. 
With this support it is possible to know the real state of the disks.


For example I have a filesystem with 4 disks (note Total devices 4):

  ghigo@emulato:~$ sudo btrfs fi show
  Label: 'btrfs3'  uuid: 2a66286d-63e9-4ed5-b347-5af5e4ada814
Total devices 4 FS bytes used 284.00KB
devid4 size 100.00GB used 8.01GB path /dev/vdj
devid3 size 100.00GB used 6.04GB path /dev/vdi
devid5 size 100.00GB used 0.00 path /dev/vdh
devid1 size 100.00GB used 7.05GB path /dev/vdg

  Btrfs Btrfs v0.19

My sysfs interface says that the filesystem is composed by 4 disks:

  ghigo@emulato:~$ cat /sys/fs/btrfs/filesystems/2a66286d-
  63e9-4ed5b347-5af5e4ada814/fs_devices/open_devices
  4

Then I remove 1 disk

  ghigo@emulato:~$ sudo btrfs dev del /dev/vdi  /mnt/btrfs3/

Now the sysfs interface says:

  ghigo@emulato:~$ cat /sys/fs/btrfs/filesystems/2a66286d-
  63e9-4ed5b347-5af5e4ada814/fs_devices/open_devices
  3

But btrfs filesystem show says (note still Total devices 4):

  ghigo@emulato:~$ sudo btrfs fi show
  failed to read /dev/sr0
  Label: 'btrfs3'  uuid: 2a66286d-63e9-4ed5-b347-5af5e4ada814
Total devices 4 FS bytes used 92.00KB
devid4 size 100.00GB used 7.00GB path /dev/vdj
devid3 size 100.00GB used 6.04GB path /dev/vdi
devid5 size 100.00GB used 5.06GB path /dev/vdh
devid1 size 100.00GB used 6.08GB path /dev/vdg

  Btrfs Btrfs v0.19

Then I do a sync

  ghigo@emulato:~$ sync
  ghigo@emulato:~$ sudo btrfs fi show
  failed to read /dev/sr0
  Label: 'btrfs3'  uuid: 2a66286d-63e9-4ed5-b347-5af5e4ada814
Total devices 3 FS bytes used 92.00KB
devid4 size 100.00GB used 7.00GB path /dev/vdj
devid3 size 100.00GB used 6.04GB path /dev/vdi
devid5 size 100.00GB used 5.06GB path /dev/vdh
devid1 size 100.00GB used 6.08GB path /dev/vdg

  Btrfs Btrfs v0.19

(note Total devices 3)

And magically the filesystem is now composed by three disks. However 4 
physical devices are show. This because the disk /dev/vdi superblock 
says that the disk is still valid (after the btrfs device del the disk 
is not touched any more)


In the past Hubert posted a patch [2] to clear a btrfs superblock. A 
further enhancement of the btrfs device del could be to reset 
automatically the first superblock (leaving the backup ones unaffected).




[2] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/17065


Btrfs Btrfs v0.19
---

As far as we can tell, only four of the disks are considered part of
the btrfs by kernel. There were only four “btrfs: bdev”-lines in dmesg
and only four disks took part in balancing. “btrfs device scan” says:

   unable to scan the device '/dev/sdd' - Device or resource busy

and balance does not balance theses two devices (of 6)

It was neither possible to remove the disk from the btrfs via “btrfs
device delete” nor adding them via “btrfs device add”.

(8) a colleague swaped the two disk

Now btrfs-tools showed:

---
#

Re: “Bug”-report: inconsistency kernel - tools

2012-08-30 Thread Hugo Mills

On Thu, Aug 30, 2012 at 08:24:53PM +0200, Goffredo Baroncelli wrote:
 On 08/28/2012 09:52 PM, M G Berberich wrote:
 (7) reinserted disk (and rebooted)
  At some point before reboot the first 10 sectors of one disk
  were zeroed to test if the disk gets removed from the btrfs.
 
 IIRC the superblock is not placed at the beginning of the disk. On
 the basis of [1] it should be near the 64KB (around the sector #128)

   Just for the record, the first is at 64KiB; each subsequent one is
shifted 12 bits left (256MiB, 1TiB, 4EiB, 16ZiB, 64YiB).

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- This chap Anon is writing some perfectly lovely stuff ---  
 at the moment.  


signature.asc
Description: Digital signature

“Bug”-report: inconsistency kernel - tools

2012-08-28 Thread M G Berberich

Hello,

We had set up a btrfs-fs over 6 hot-plugable SAS-disks for
testing and got it into a state where kernel and btrfs-tools do not
agree any more about the state of the filesystem.

We do not remember exaclty what we did, but roughly it was something
like this (on the running system). THIS IS FROM MEMORY!

(1) pulled out one disk
(2) removed disk from btrfs
(3) rebalanced btrfs
(4) pulled out another disk
(5) removed disk from btrfs
(6) rebalanced btrfs

This went fine sofar.

(7) reinserted disk (and rebooted)
At some point before reboot the first 10 sectors of one disk
were zeroed to test if the disk gets removed from the btrfs.

Now btrfs-tools showed:

---
# btrfs fi show  
failed to read /dev/sr0
Label: 'BTRFS_RAID'  uuid: 807193fd-17de-4088-9a54-3e7cacdc89db
Total devices 6 FS bytes used 3.07GB
devid4 size 931.00GB used 75.00GB path /dev/sdf
devid5 size 931.00GB used 324.03GB path /dev/sde
devid6 size 931.00GB used 83.03GB path /dev/sdd
devid3 size 931.00GB used 326.03GB path /dev/sdc
devid2 size 931.00GB used 326.03GB path /dev/sdb
devid1 size 931.00GB used 324.04GB path /dev/sda

Btrfs Btrfs v0.19
---

As far as we can tell, only four of the disks are considered part of
the btrfs by kernel. There were only four “btrfs: bdev”-lines in dmesg
and only four disks took part in balancing. “btrfs device scan” says:

  unable to scan the device '/dev/sdd' - Device or resource busy

and balance does not balance theses two devices (of 6)

It was neither possible to remove the disk from the btrfs via “btrfs
device delete” nor adding them via “btrfs device add”.

(8) a colleague swaped the two disk

Now btrfs-tools showed:

---
# btrfs fi show
failed to read /dev/sr0
Label: 'BTRFS_RAID'  uuid: 807193fd-17de-4088-9a54-3e7cacdc89db
Total devices 5 FS bytes used 3.01GB
devid6 size 931.00GB used 83.03GB path /dev/sdf
devid4 size 931.00GB used 75.00GB path /dev/sdd
devid5 size 931.00GB used 325.03GB path /dev/sde
devid3 size 931.00GB used 326.03GB path /dev/sdc
devid2 size 931.00GB used 325.03GB path /dev/sdb
devid1 size 931.51GB used 326.04GB path /dev/sda

Btrfs Btrfs v0.19
---

Claiming the btrfs has 5 disk, but listing 6 disks out of 5 (6 of 5).

He finally managed to get the btrfs complete again by overwriting the
first 100G of the two disk. After this the btrfs-tools (correctly)
stated a filesystem with 4 disk and it was possible to add the two
disk again.


Assumption:
kernel and btrfs do not share the same view of the filesystem.

In this state commands to repair the filesystem do not work, because
they are either rejected by the tools or by the kernel.

A tool that allows a disk/partition to be marked as not-a-btrfs-part
would be nice.

A “/proc/btrfs” showing the kernels view of the filesystem would be
usefull.

MfG
bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | berbe...@fmi.uni-passau.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | www.fmi.uni-passau.de/~berberic
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bug report

2011-04-05 Thread Helmut Hullen

Hallo, Larry,

Du meintest am 05.04.11:

[...]

 and then try to apt-get some stuff, and the result is this:

 btrfs csum failed ino 17498 off 2412544 csum 491052325 private
 446722121
 btrfs csum failed ino 17498 off 2416640 csum 2077462867
 private 906054605

[...]

 I've gone through this twice now, so it's repeatable at least.  I
 know 2.6.35 is kinda old but was this kind of thing to be expected
 back then?

First try an actual kernel; I prefer 2.6.38.1

Viele Gruesse!
Helmut
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bug report

2011-04-04 Thread Larry D'Anna

So i made a filesystem image 

 $ dd if=/dev/zero of=root_fs bs=1024 count=$(expr 1024 \* 1024)
 $ mkfs.btrfs root_fs 

Then I put some debian on it (my kernel is 2.6.35-27-generic #48-Ubuntu) 

 $ mkdir root 
 $ mount -o loop root_fs root 
 $ debootstrap sid root 
 $ umount root

Then i run uml.   (2.6.35-1um-0ubuntu1)

 $ linux single eth0=tuntap,tap0,fe:fd:f0:00:00:01

and then try to apt-get some stuff, and the result is this:

btrfs csum failed ino 17498 off 2412544 csum 491052325 private 446722121
btrfs csum failed ino 17498 off 2416640 csum 2077462867 private 906054605
btrfs csum failed ino 17498 off 2420736 csum 263316283 private 2215839539
btrfs csum failed ino 17498 off 2424832 csum 4177088190 private 2414263107
btrfs csum failed ino 17498 off 2428928 csum 4028205539 private 3560605623
btrfs csum failed ino 17498 off 2433024 csum 1724529595 private 200634979
btrfs csum failed ino 17498 off 2437120 csum 4038631380 private 2927872002
btrfs csum failed ino 17498 off 2441216 csum 2616837020 private 729736037
btrfs csum failed ino 17498 off 2498560 csum 2566472073 private 3417075259
btrfs csum failed ino 17498 off 2502656 csum 2566472073 private 1410567947


 $ find / -mount -inum 17498  
 /var/cache/apt/srcpkgcache.bin

I've gone through this twice now, so it's repeatable at least.  I know 2.6.35 is
kinda old but was this kind of thing to be expected back then?  


  --larry
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug Report: Warning because of multipath ?

2011-03-02 Thread Felipe Barriga Richards

Hi everyone,

I've the following configuration:
Distro: Gentoo
Kernel: vanilla 2.6.38-rc6 AMD64 
Details:
I use btrfs on a Dell MD3000i iSCSI disk. I'm connected with 2 ethernet
cards with multipath to one raid controller.
The mounted partition is also accessed from other servers via nfs.

The mount options are: rw,compress,thread_pool=15,compress-force

I think that this error happens when the network is under heavy load and
also the btrfs is having multiple i/o.

Regards,

--- Kernel Message ---

[ cut here ]
WARNING: at fs/btrfs/disk-io.c:381 __btree_submit_bio_start+0x2c7/0x300
[btrfs]()
Hardware name: PowerEdge R710
Modules linked in: nfsd btrfs zlib_deflate lzo_decompress lzo_compress
ipv6 dm_round_robin dm_multipath iscsi_tcp libiscsi_tcp libiscsi
scsi_transport_iscsi cpufreq_stats cpufreq_powersave cpufreq_ondemand
acpi_cpufreq freq_table mperf usbhid dm_mod pata_acpi ata_generic
ehci_hcd ata_piix uhci_hcd bnx2 usbcore dcdbas power_meter sg rtc libata
processor firmware_class thermal_sys hwmon button
Pid: 13939, comm: btrfs-worker-1 Not tainted 2.6.38-rc6 #1
Call Trace:
 [810425bb] ? warn_slowpath_common+0x7b/0xc0
 [a0219037] ? __btree_submit_bio_start+0x2c7/0x300 [btrfs]
 [8104e910] ? process_timeout+0x0/0x10
 [a0247c98] ? worker_loop+0x148/0x530 [btrfs]
 [a0247b50] ? worker_loop+0x0/0x530 [btrfs]
 [a0247b50] ? worker_loop+0x0/0x530 [btrfs]
 [8105cea6] ? kthread+0x96/0xa0
 [8100ade4] ? kernel_thread_helper+0x4/0x10
 [8105ce10] ? kthread+0x0/0xa0
 [8100ade0] ? kernel_thread_helper+0x0/0x10
---[ end trace ebe62be1d938042c ]---


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug report: parent transid failed after heavy load

2011-01-07 Thread Arie Peterson


Dear all,


During a move of some 60GB of data from an ext4 partition to a btrfs 
partition, both on the same disk, the following happened:


- my window manager froze;
- the move suspended, i.e., no more data was written to the destination 
or deleted from the source;
- part of top output: (sorry for possible wrapping; sending this from 
webmail)


  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+ COMMAND

13610 root  20   0 000 D   26  0.0 299:45.87 
btrfs-cache-279
 1566 root  20   0 000 S   22  0.0 218:30.86 
btrfs-endio-met


(there were also a firefox instance and an npviewer.bin process still 
consuming CPU time, but I guess this was some flash movie happily 
playing along during the freeze);


- those two btrfs processes could not be terminated, not even by kill 
-9;

- lsof 1566 output (similar for the other process):

COMMANDPID USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
btrfs-end 1566 root  cwd   DIR8,6 40962 /
btrfs-end 1566 root  rtd   DIR8,6 40962 /
btrfs-end 1566 root  txt   unknown  /proc/1566/exe

After a reboot, I am able to mount the btrfs filesystem, and read data 
from it, but as soon as I try any write operation (even a simple touch), 
that command hangs, and there are two btrfs processes hanging around, 
just as above; dmesg gives lots of parent transid failed messages.


My kernel is 2.6.36 (with gentoo patches).

So, the questions:

1) Is this a known problem? If so, is it fixed in a newer version?

In the archive of this list, I read about others with parent transid 
failed errors, and a recovery operation (suggested by Chris Mason), 
using btrfs-select-super 
http://www.spinics.net/lists/linux-btrfs/msg07572.html.


2) Should I try this procedure to fix my filesystem? Is there any debug 
information I should collect first? (I can recreate the two spinning 
processes by rebooting and writing to the filesystem.)



I am saddened by this failure, as this data move was actually part of 
an operation to switch over to btrfs completely, after using it without 
problems for quite a while.



Thanks for any help. Keep up the good work.


Regards,

Arie Peterson

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mini bug report

2010-12-20 Thread Xavier Nicollet

Hi,

I use btrfs on my laptop, 2.6.37-rc2 from kernel.org, under dm-crypt, as
/. I use space_cache and compression (not forced).

Today, my computer froze. At reboot, the kernel could not mount.
The dmesg output, which I haven't saved was speaking of a null
dereference.

After that I rebooted on 2.6.34, which was not very happy: mount errors
(space cache ?).

Now I am on 2.6.37-rc2 again, which seems to work.
So I guess it might come from space_cache.

I would note on a paper if this comes back. However if anybody has any
clue on what specific part of the dmesg should be reported, it would be
very helpfull !

Cheers,

-- 
Xavier Nicollet
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mini bug report

2010-12-20 Thread Chris Mason

Excerpts from Xavier Nicollet's message of 2010-12-20 10:58:01 -0500:
 Hi,
 
 I use btrfs on my laptop, 2.6.37-rc2 from kernel.org, under dm-crypt, as
 /. I use space_cache and compression (not forced).
 
 Today, my computer froze. At reboot, the kernel could not mount.
 The dmesg output, which I haven't saved was speaking of a null
 dereference.
 
 After that I rebooted on 2.6.34, which was not very happy: mount errors
 (space cache ?).
 
 Now I am on 2.6.37-rc2 again, which seems to work.
 So I guess it might come from space_cache.
 
 I would note on a paper if this comes back. However if anybody has any
 clue on what specific part of the dmesg should be reported, it would be
 very helpfull !

These sound like the free space caching bugs that josef fixed.  If you
pull down the latest I think we've got it nailed.

-chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

67 matches

Mail list logo