1. 21 Jan, 2014 1 commit
    • Weston Andros Adamson's avatar
      pnfs: fix BUG in filelayout_recover_commit_reqs · 471252cd
      Weston Andros Adamson authored
      cond_resched_lock(cinfo->lock) is called everywhere else while holding
      the cinfo->lock spinlock.  Not holding this lock while calling
      transfer_commit_list in filelayout_recover_commit_reqs causes the BUG
      below.
      
      It's true that we can't hold this lock while calling pnfs_put_lseg,
      because that might try to lock the inode lock - which might be the
      same lock as cinfo->lock.
      
      To reproduce, mount a 2 DS pynfs server and run an O_DIRECT command
      that crosses a stripe boundary and is not page aligned, such as:
      
       dd if=/dev/zero of=/mnt/f bs=17000 count=1 oflag=direct
      
      BUG: sleeping function called from invalid context at linux/fs/nfs/nfs4filelayout.c:1161
      in_atomic(): 0, irqs_disabled(): 0, pid: 27, name: kworker/0:1
      2 locks held by kworker/0:1/27:
       #0:  (events){.+.+.+}, at: [<ffffffff810501d7>] process_one_work+0x175/0x3a5
       #1:  ((&dreq->work)){+.+...}, at: [<ffffffff810501d7>] process_one_work+0x175/0x3a5
      CPU: 0 PID: 27 Comm: kworker/0:1 Not tainted 3.13.0-rc3-branch-dros_testing+ #21
      Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
      Workqueue: events nfs_direct_write_schedule_work [nfs]
       0000000000000000 ffff88007a39bbb8 ffffffff81491256 ffff88007b87a130  ffff88007a39bbd8 ffffffff8105f103 ffff880079614000 ffff880079617d40  ffff88007a39bc20 ffffffffa011603e ffff880078988b98 0000000000000000
      Call Trace:
       [<ffffffff81491256>] dump_stack+0x4d/0x66
       [<ffffffff8105f103>] __might_sleep+0x100/0x105
       [<ffffffffa011603e>] transfer_commit_list+0x94/0xf1 [nfs_layout_nfsv41_files]
       [<ffffffffa01160d6>] filelayout_recover_commit_reqs+0x3b/0x68 [nfs_layout_nfsv41_files]
       [<ffffffffa00ba53a>] nfs_direct_write_reschedule+0x9f/0x1d6 [nfs]
       [<ffffffff810705df>] ? mark_lock+0x1df/0x224
       [<ffffffff8106e617>] ? trace_hardirqs_off_caller+0x37/0xa4
       [<ffffffff8106e691>] ? trace_hardirqs_off+0xd/0xf
       [<ffffffffa00ba8f8>] nfs_direct_write_schedule_work+0x9d/0xb7 [nfs]
       [<ffffffff810501d7>] ? process_one_work+0x175/0x3a5
       [<ffffffff81050258>] process_one_work+0x1f6/0x3a5
       [<ffffffff810501d7>] ? process_one_work+0x175/0x3a5
       [<ffffffff8105187e>] worker_thread+0x149/0x1f5
       [<ffffffff81051735>] ? rescuer_thread+0x28d/0x28d
       [<ffffffff81056d74>] kthread+0xd2/0xda
       [<ffffffff81056ca2>] ? __kthread_parkme+0x61/0x61
       [<ffffffff8149e66c>] ret_from_fork+0x7c/0xb0
       [<ffffffff81056ca2>] ? __kthread_parkme+0x61/0x61
      Signed-off-by: default avatarWeston Andros Adamson <dros@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      471252cd
  2. 20 Jan, 2014 1 commit
  3. 19 Jan, 2014 1 commit
  4. 17 Jan, 2014 1 commit
  5. 13 Jan, 2014 10 commits
  6. 05 Jan, 2014 4 commits
    • Toralf Förster's avatar
    • Niels de Vos's avatar
      NFS: dprintk() should not print negative fileids and inode numbers · 1e8968c5
      Niels de Vos authored
      A fileid in NFS is a uint64. There are some occurrences where dprintk()
      outputs a signed fileid. This leads to confusion and more difficult to
      read debugging (negative fileids matching positive inode numbers).
      Signed-off-by: default avatarNiels de Vos <ndevos@redhat.com>
      CC: Santosh Pradhan <spradhan@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      1e8968c5
    • Alexander Aring's avatar
      nfs: fix dead code of ipv6_addr_scope · a8c22754
      Alexander Aring authored
      The correct way to check on IPV6_ADDR_SCOPE_LINKLOCAL is to check with
      the ipv6_addr_src_scope function.
      
      Currently this can't be work, because ipv6_addr_scope returns a int with
      a mask of IPV6_ADDR_SCOPE_MASK (0x00f0U) and IPV6_ADDR_SCOPE_LINKLOCAL
      is 0x02. So the condition is always false.
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      a8c22754
    • Weston Andros Adamson's avatar
      sunrpc: Fix infinite loop in RPC state machine · 6ff33b7d
      Weston Andros Adamson authored
      When a task enters call_refreshresult with status 0 from call_refresh and
      !rpcauth_uptodatecred(task) it enters call_refresh again with no rate-limiting
      or max number of retries.
      
      Instead of trying forever, make use of the retry path that other errors use.
      
      This only seems to be possible when the crrefresh callback is gss_refresh_null,
      which only happens when destroying the context.
      
      To reproduce:
      
      1) mount with sec=krb5 (or sec=sys with krb5 negotiated for non FSID specific
         operations).
      
      2) reboot - the client will be stuck and will need to be hard rebooted
      
      BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:2:46]
      Modules linked in: rpcsec_gss_krb5 nfsv4 nfs fscache ppdev crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd serio_raw i2c_piix4 i2c_core e1000 parport_pc parport shpchp nfsd auth_rpcgss oid_registry exportfs nfs_acl lockd sunrpc autofs4 mptspi scsi_transport_spi mptscsih mptbase ata_generic floppy
      irq event stamp: 195724
      hardirqs last  enabled at (195723): [<ffffffff814a925c>] restore_args+0x0/0x30
      hardirqs last disabled at (195724): [<ffffffff814b0a6a>] apic_timer_interrupt+0x6a/0x80
      softirqs last  enabled at (195722): [<ffffffff8103f583>] __do_softirq+0x1df/0x276
      softirqs last disabled at (195717): [<ffffffff8103f852>] irq_exit+0x53/0x9a
      CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc3-branch-dros_testing+ #4
      Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
      Workqueue: rpciod rpc_async_schedule [sunrpc]
      task: ffff8800799c4260 ti: ffff880079002000 task.ti: ffff880079002000
      RIP: 0010:[<ffffffffa0064fd4>]  [<ffffffffa0064fd4>] __rpc_execute+0x8a/0x362 [sunrpc]
      RSP: 0018:ffff880079003d18  EFLAGS: 00000246
      RAX: 0000000000000005 RBX: 0000000000000007 RCX: 0000000000000007
      RDX: 0000000000000007 RSI: ffff88007aecbae8 RDI: ffff8800783d8900
      RBP: ffff880079003d78 R08: ffff88006e30e9f8 R09: ffffffffa005a3d7
      R10: ffff88006e30e7b0 R11: ffff8800783d8900 R12: ffffffffa006675e
      R13: ffff880079003ce8 R14: ffff88006e30e7b0 R15: ffff8800783d8900
      FS:  0000000000000000(0000) GS:ffff88007f200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f3072333000 CR3: 0000000001a0b000 CR4: 00000000001407f0
      Stack:
       ffff880079003d98 0000000000000246 0000000000000000 ffff88007a9a4830
       ffff880000000000 ffffffff81073f47 ffff88007f212b00 ffff8800799c4260
       ffff8800783d8988 ffff88007f212b00 ffffe8ffff604800 0000000000000000
      Call Trace:
       [<ffffffff81073f47>] ? trace_hardirqs_on_caller+0x145/0x1a1
       [<ffffffffa00652d3>] rpc_async_schedule+0x27/0x32 [sunrpc]
       [<ffffffff81052974>] process_one_work+0x211/0x3a5
       [<ffffffff810528d5>] ? process_one_work+0x172/0x3a5
       [<ffffffff81052eeb>] worker_thread+0x134/0x202
       [<ffffffff81052db7>] ? rescuer_thread+0x280/0x280
       [<ffffffff81052db7>] ? rescuer_thread+0x280/0x280
       [<ffffffff810584a0>] kthread+0xc9/0xd1
       [<ffffffff810583d7>] ? __kthread_parkme+0x61/0x61
       [<ffffffff814afd6c>] ret_from_fork+0x7c/0xb0
       [<ffffffff810583d7>] ? __kthread_parkme+0x61/0x61
      Code: e8 87 63 fd e0 c6 05 10 dd 01 00 01 48 8b 43 70 4c 8d 6b 70 45 31 e4 a8 02 0f 85 d5 02 00 00 4c 8b 7b 48 48 c7 43 48 00 00 00 00 <4c> 8b 4b 50 4d 85 ff 75 0c 4d 85 c9 4d 89 cf 0f 84 32 01 00 00
      
      And the output of "rpcdebug -m rpc -s all":
      
      RPC:    61 call_refresh (status 0)
      RPC:    61 call_refresh (status 0)
      RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
      RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
      RPC:    61 call_refreshresult (status 0)
      RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
      RPC:    61 call_refreshresult (status 0)
      RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
      RPC:    61 call_refresh (status 0)
      RPC:    61 call_refreshresult (status 0)
      RPC:    61 call_refresh (status 0)
      RPC:    61 call_refresh (status 0)
      RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
      RPC:    61 call_refreshresult (status 0)
      RPC:    61 call_refresh (status 0)
      RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
      RPC:    61 call_refresh (status 0)
      RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
      RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
      RPC:    61 call_refreshresult (status 0)
      RPC:    61 call_refresh (status 0)
      RPC:    61 call_refresh (status 0)
      RPC:    61 call_refresh (status 0)
      RPC:    61 call_refresh (status 0)
      RPC:    61 call_refreshresult (status 0)
      RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
      Signed-off-by: default avatarWeston Andros Adamson <dros@netapp.com>
      Cc: stable@vger.kernel.org # 2.6.37+
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      6ff33b7d
  7. 31 Dec, 2013 4 commits
  8. 10 Dec, 2013 1 commit
  9. 06 Dec, 2013 17 commits