1. 06 3月, 2014 1 次提交
  2. 30 1月, 2014 2 次提交
  3. 22 1月, 2014 1 次提交
    • W
      pnfs: fix BUG in filelayout_recover_commit_reqs · 471252cd
      Weston Andros Adamson 提交于
      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: NWeston Andros Adamson <dros@primarydata.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      471252cd
  4. 06 1月, 2014 1 次提交
  5. 07 9月, 2013 1 次提交
    • A
      NFSv4.1 Use MDS auth flavor for data server connection · 0e20162e
      Andy Adamson 提交于
      Commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state whenever possible"
      uses the nfs_client cl_rpcclient for all state management operations, and
      will use krb5i or auth_sys with no regard to the mount command authflavor
      choice.
      
      The MDS, as any NFSv4.1 mount point, uses the nfs_server rpc client for all
      non-state management operations with a different nfs_server for each fsid
      encountered traversing the mount point, each with a potentially different
      auth flavor.
      
      pNFS data servers are not mounted in the normal sense as there is no associated
      nfs_server structure. Data servers can also export multiple fsids, each with
      a potentially different auth flavor.
      
      Data servers need to use the same authflavor as the MDS server rpc client for
      non-state management operations. Populate a list of rpc clients with the MDS
      server rpc client auth flavor for the DS to use.
      Signed-off-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      0e20162e
  6. 22 8月, 2013 1 次提交
  7. 07 6月, 2013 1 次提交
  8. 26 3月, 2013 3 次提交
  9. 21 3月, 2013 1 次提交
  10. 24 2月, 2013 1 次提交
    • B
      pnfs: fix resend_to_mds for directio · 78f33277
      Benny Halevy 提交于
      Pass the directio request on pageio_init to clean up the API.
      
      Percolate pg_dreq from original nfs_pageio_descriptor to the
      pnfs_{read,write}_done_resend_to_mds and use it on respective
      call to nfs_pageio_init_{read,write} on the newly created
      nfs_pageio_descriptor.
      
      Reproduced by command:
       mount -o vers=4.1 server:/ /mnt
       dd bs=128k count=8 if=/dev/zero of=/mnt/dd.out oflag=direct
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      IP: [<ffffffffa021a3a8>] atomic_inc+0x4/0x9 [nfs]
      PGD 34786067 PUD 34794067 PMD 0
      Oops: 0002 [#1] SMP
      Modules linked in: nfs_layout_nfsv41_files nfsv4 nfs nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc btrfs zlib_deflate libcrc32c ipv6 autofs4
      CPU 1
      Pid: 259, comm: kworker/1:2 Not tainted 3.8.0-rc6 #2 Bochs Bochs
      RIP: 0010:[<ffffffffa021a3a8>]  [<ffffffffa021a3a8>] atomic_inc+0x4/0x9 [nfs]
      RSP: 0018:ffff880038f8fa68  EFLAGS: 00010206
      RAX: ffffffffa021a6a9 RBX: ffff880038f8fb48 RCX: 00000000000a0000
      RDX: ffffffffa021e616 RSI: ffff8800385e9a40 RDI: 0000000000000028
      RBP: ffff880038f8fa68 R08: ffffffff81ad6720 R09: ffff8800385e9510
      R10: ffffffffa0228450 R11: ffff880038e87418 R12: ffff8800385e9a40
      R13: ffff8800385e9a70 R14: ffff880038f8fb38 R15: ffffffffa0148878
      FS:  0000000000000000(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000028 CR3: 0000000034789000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process kworker/1:2 (pid: 259, threadinfo ffff880038f8e000, task ffff880038302480)
      Stack:
       ffff880038f8fa78 ffffffffa021a6bf ffff880038f8fa88 ffffffffa021bb82
       ffff880038f8fae8 ffffffffa021f454 ffff880038f8fae8 ffffffff8109689d
       ffff880038f8fab8 ffffffff00000006 0000000000000000 ffff880038f8fb48
      Call Trace:
       [<ffffffffa021a6bf>] nfs_direct_pgio_init+0x16/0x18 [nfs]
       [<ffffffffa021bb82>] nfs_pgheader_init+0x6a/0x6c [nfs]
       [<ffffffffa021f454>] nfs_generic_pg_writepages+0x51/0xf8 [nfs]
       [<ffffffff8109689d>] ? mark_held_locks+0x71/0x99
       [<ffffffffa0148878>] ? rpc_release_resources_task+0x37/0x37 [sunrpc]
       [<ffffffffa021bc25>] nfs_pageio_doio+0x1a/0x43 [nfs]
       [<ffffffffa021be7c>] nfs_pageio_complete+0x16/0x2c [nfs]
       [<ffffffffa02608be>] pnfs_write_done_resend_to_mds+0x95/0xc5 [nfsv4]
       [<ffffffffa0148878>] ? rpc_release_resources_task+0x37/0x37 [sunrpc]
       [<ffffffffa028e27f>] filelayout_reset_write+0x8c/0x99 [nfs_layout_nfsv41_files]
       [<ffffffffa028e5f9>] filelayout_write_done_cb+0x4d/0xc1 [nfs_layout_nfsv41_files]
       [<ffffffffa024587a>] nfs4_write_done+0x36/0x49 [nfsv4]
       [<ffffffffa021f996>] nfs_writeback_done+0x53/0x1cc [nfs]
       [<ffffffffa021fb1d>] nfs_writeback_done_common+0xe/0x10 [nfs]
       [<ffffffffa028e03d>] filelayout_write_call_done+0x28/0x2a [nfs_layout_nfsv41_files]
       [<ffffffffa01488a1>] rpc_exit_task+0x29/0x87 [sunrpc]
       [<ffffffffa014a0c9>] __rpc_execute+0x11d/0x3cc [sunrpc]
       [<ffffffff810969dc>] ? trace_hardirqs_on_caller+0x117/0x173
       [<ffffffffa014a39f>] rpc_async_schedule+0x27/0x32 [sunrpc]
       [<ffffffffa014a378>] ? __rpc_execute+0x3cc/0x3cc [sunrpc]
       [<ffffffff8105f8c1>] process_one_work+0x226/0x422
       [<ffffffff8105f7f4>] ? process_one_work+0x159/0x422
       [<ffffffff81094757>] ? lock_acquired+0x210/0x249
       [<ffffffffa014a378>] ? __rpc_execute+0x3cc/0x3cc [sunrpc]
       [<ffffffff810600d8>] worker_thread+0x126/0x1c4
       [<ffffffff8105ffb2>] ? manage_workers+0x240/0x240
       [<ffffffff81064ef8>] kthread+0xb1/0xb9
       [<ffffffff81064e47>] ? __kthread_parkme+0x65/0x65
       [<ffffffff815206ec>] ret_from_fork+0x7c/0xb0
       [<ffffffff81064e47>] ? __kthread_parkme+0x65/0x65
      Code: 00 83 38 02 74 12 48 81 4b 50 00 00 01 00 c7 83 60 07 00 00 01 00 00 00 48 89 df e8 55 fe ff ff 5b 41 5c 5d c3 66 90 55 48 89 e5 <f0> ff 07 5d c3 55 48 89 e5 f0 ff 0f 0f 94 c0 84 c0 0f 95 c0 0f
      RIP  [<ffffffffa021a3a8>] atomic_inc+0x4/0x9 [nfs]
       RSP <ffff880038f8fa68>
      CR2: 0000000000000028
      Signed-off-by: NBenny Halevy <bhalevy@tonian.com>
      Cc: stable@kernel.org [>= 3.6]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      78f33277
  11. 13 12月, 2012 1 次提交
    • A
      SUNRPC handle EKEYEXPIRED in call_refreshresult · eb96d5c9
      Andy Adamson 提交于
      Currently, when an RPCSEC_GSS context has expired or is non-existent
      and the users (Kerberos) credentials have also expired or are non-existent,
      the client receives the -EKEYEXPIRED error and tries to refresh the context
      forever.  If an application is performing I/O, or other work against the share,
      the application hangs, and the user is not prompted to refresh/establish their
      credentials. This can result in a denial of service for other users.
      
      Users are expected to manage their Kerberos credential lifetimes to mitigate
      this issue.
      
      Move the -EKEYEXPIRED handling into the RPC layer. Try tk_cred_retry number
      of times to refresh the gss_context, and then return -EACCES to the application.
      Signed-off-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      eb96d5c9
  12. 06 12月, 2012 2 次提交
  13. 05 11月, 2012 1 次提交
  14. 15 10月, 2012 3 次提交
  15. 29 9月, 2012 5 次提交
  16. 17 7月, 2012 2 次提交
  17. 29 6月, 2012 1 次提交
  18. 28 5月, 2012 1 次提交
  19. 23 5月, 2012 5 次提交
  20. 20 5月, 2012 6 次提交