1. 14 7月, 2017 17 次提交
  2. 04 6月, 2017 1 次提交
  3. 29 5月, 2017 1 次提交
  4. 24 5月, 2017 4 次提交
    • T
      NFSv4.0: Fix a lock leak in nfs40_walk_client_list · b49c15f9
      Trond Myklebust 提交于
      Xiaolong Ye's kernel test robot detected the following Oops:
      [  299.158991] BUG: scheduling while atomic: mount.nfs/9387/0x00000002
      [  299.169587] 2 locks held by mount.nfs/9387:
      [  299.176165]  #0:  (nfs_clid_init_mutex){......}, at: [<ffffffff8130cc92>] nfs4_discover_server_trunking+0x47/0x1fc
      [  299.201802]  #1:  (&(&nn->nfs_client_lock)->rlock){......}, at: [<ffffffff813125fa>] nfs40_walk_client_list+0x2e9/0x338
      [  299.221979] CPU: 0 PID: 9387 Comm: mount.nfs Not tainted 4.11.0-rc7-00021-g14d1bbb0 #45
      [  299.235584] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
      [  299.251176] Call Trace:
      [  299.255192]  dump_stack+0x61/0x7e
      [  299.260416]  __schedule_bug+0x65/0x74
      [  299.266208]  __schedule+0x5d/0x87c
      [  299.271883]  schedule+0x89/0x9a
      [  299.276937]  schedule_timeout+0x232/0x289
      [  299.283223]  ? detach_if_pending+0x10b/0x10b
      [  299.289935]  schedule_timeout_uninterruptible+0x2a/0x2c
      [  299.298266]  ? put_rpccred+0x3e/0x115
      [  299.304327]  ? schedule_timeout_uninterruptible+0x2a/0x2c
      [  299.312851]  msleep+0x1e/0x22
      [  299.317612]  nfs4_discover_server_trunking+0x102/0x1fc
      [  299.325644]  nfs4_init_client+0x13f/0x194
      
      It looks as if we recently added a spin_lock() leak to
      nfs40_walk_client_list() when cleaning up the code.
      Reported-by: Nkernel test robot <xiaolong.ye@intel.com>
      Fixes: 14d1bbb0 ("NFS: Create a common nfs4_match_client() function")
      Cc: Anna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      b49c15f9
    • B
      pnfs: Fix the check for requests in range of layout segment · 08cb5b0f
      Benjamin Coddington 提交于
      It's possible and acceptable for NFS to attempt to add requests beyond the
      range of the current pgio->pg_lseg, a case which should be caught and
      limited by the pg_test operation.  However, the current handling of this
      case replaces pgio->pg_lseg with a new layout segment (after a WARN) within
      that pg_test operation.  That will cause all the previously added requests
      to be submitted with this new layout segment, which may not be valid for
      those requests.
      
      Fix this problem by only returning zero for the number of bytes to coalesce
      from pg_test for this case which allows any previously added requests to
      complete on the current layout segment.  The check for requests starting
      out of range of the layout segment moves to pg_init, so that the
      replacement of pgio->pg_lseg will be done when the next request is added.
      Signed-off-by: NBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      08cb5b0f
    • D
      pNFS/flexfiles: missing error code in ff_layout_alloc_lseg() · 662f9a10
      Dan Carpenter 提交于
      If xdr_inline_decode() fails then we end up returning ERR_PTR(0).  The
      caller treats NULL returns as -ENOMEM so it doesn't really hurt runtime,
      but obviously we intended to set an error code here.
      
      Fixes: d67ae825 ("pnfs/flexfiles: Add the FlexFile Layout Driver")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      662f9a10
    • O
      NFS fix COMMIT after COPY · 6d3b5d8d
      Olga Kornievskaia 提交于
      Fix a typo in the commit e0926934
      "NFS append COMMIT after synchronous COPY"
      Reported-by: NEryu Guan <eguan@redhat.com>
      Fixes: e0926934 ("NFS append COMMIT after synchronous COPY")
      Signed-off-by: NOlga Kornievskaia <kolga@netapp.com>
      Tested-by: NEryu Guan <eguan@redhat.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      6d3b5d8d
  5. 10 5月, 2017 2 次提交
  6. 09 5月, 2017 1 次提交
  7. 08 5月, 2017 2 次提交
  8. 06 5月, 2017 4 次提交
  9. 04 5月, 2017 2 次提交
    • J
      nfs: Fix bdi handling for cloned superblocks · 9052c7cf
      Jan Kara 提交于
      In commit 0d3b12584972 "nfs: Convert to separately allocated bdi" I have
      wrongly cloned bdi reference in nfs_clone_super(). Further inspection
      has shown that originally the code was actually allocating a new bdi (in
      ->clone_server callback) which was later registered in
      nfs_fs_mount_common() and used for sb->s_bdi in nfs_initialise_sb().
      This could later result in bdi for the original superblock not getting
      unregistered when that superblock got shutdown (as the cloned sb still
      held bdi reference) and later when a new superblock was created under
      the same anonymous device number, a clash in sysfs has happened on bdi
      registration:
      
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 10284 at /linux-next/fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x74
      sysfs: cannot create duplicate filename '/devices/virtual/bdi/0:32'
      Modules linked in: axp20x_usb_power gpio_axp209 nvmem_sunxi_sid sun4i_dma sun4i_ss virt_dma
      CPU: 1 PID: 10284 Comm: mount.nfs Not tainted 4.11.0-rc4+ #14
      Hardware name: Allwinner sun7i (A20) Family
      [<c010f19c>] (unwind_backtrace) from [<c010bc74>] (show_stack+0x10/0x14)
      [<c010bc74>] (show_stack) from [<c03c6e24>] (dump_stack+0x78/0x8c)
      [<c03c6e24>] (dump_stack) from [<c0122200>] (__warn+0xe8/0x100)
      [<c0122200>] (__warn) from [<c0122250>] (warn_slowpath_fmt+0x38/0x48)
      [<c0122250>] (warn_slowpath_fmt) from [<c02ac178>] (sysfs_warn_dup+0x64/0x74)
      [<c02ac178>] (sysfs_warn_dup) from [<c02ac254>] (sysfs_create_dir_ns+0x84/0x94)
      [<c02ac254>] (sysfs_create_dir_ns) from [<c03c8b8c>] (kobject_add_internal+0x9c/0x2ec)
      [<c03c8b8c>] (kobject_add_internal) from [<c03c8e24>] (kobject_add+0x48/0x98)
      [<c03c8e24>] (kobject_add) from [<c048d75c>] (device_add+0xe4/0x5a0)
      [<c048d75c>] (device_add) from [<c048ddb4>] (device_create_groups_vargs+0xac/0xbc)
      [<c048ddb4>] (device_create_groups_vargs) from [<c048dde4>] (device_create_vargs+0x20/0x28)
      [<c048dde4>] (device_create_vargs) from [<c02075c8>] (bdi_register_va+0x44/0xfc)
      [<c02075c8>] (bdi_register_va) from [<c023d378>] (super_setup_bdi_name+0x48/0xa4)
      [<c023d378>] (super_setup_bdi_name) from [<c0312ef4>] (nfs_fill_super+0x1a4/0x204)
      [<c0312ef4>] (nfs_fill_super) from [<c03133f0>] (nfs_fs_mount_common+0x140/0x1e8)
      [<c03133f0>] (nfs_fs_mount_common) from [<c03335cc>] (nfs4_remote_mount+0x50/0x58)
      [<c03335cc>] (nfs4_remote_mount) from [<c023ef98>] (mount_fs+0x14/0xa4)
      [<c023ef98>] (mount_fs) from [<c025cba0>] (vfs_kern_mount+0x54/0x128)
      [<c025cba0>] (vfs_kern_mount) from [<c033352c>] (nfs_do_root_mount+0x80/0xa0)
      [<c033352c>] (nfs_do_root_mount) from [<c0333818>] (nfs4_try_mount+0x28/0x3c)
      [<c0333818>] (nfs4_try_mount) from [<c0313874>] (nfs_fs_mount+0x2cc/0x8c4)
      [<c0313874>] (nfs_fs_mount) from [<c023ef98>] (mount_fs+0x14/0xa4)
      [<c023ef98>] (mount_fs) from [<c025cba0>] (vfs_kern_mount+0x54/0x128)
      [<c025cba0>] (vfs_kern_mount) from [<c02600f0>] (do_mount+0x158/0xc7c)
      [<c02600f0>] (do_mount) from [<c0260f98>] (SyS_mount+0x8c/0xb4)
      [<c0260f98>] (SyS_mount) from [<c0107840>] (ret_fast_syscall+0x0/0x3c)
      
      Fix the problem by always creating new bdi for a superblock as we used
      to do.
      Reported-and-tested-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
      Fixes: 0d3b12584972ce5781179ad3f15cca3cdb5cae05
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      9052c7cf
    • F
  10. 03 5月, 2017 3 次提交
  11. 29 4月, 2017 3 次提交