1. 28 Jul, 2015 2 commits
    • Kinglong Mee's avatar
      nfs: Fix an oops caused by using other thread's stack space in ASYNC mode · a49c2691
      Kinglong Mee authored
      An oops caused by using other thread's stack space in sunrpc ASYNC sending thread.
      
      [ 9839.007187] ------------[ cut here ]------------
      [ 9839.007923] kernel BUG at fs/nfs/nfs4xdr.c:910!
      [ 9839.008069] invalid opcode: 0000 [#1] SMP
      [ 9839.008069] Modules linked in: blocklayoutdriver rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm joydev iosf_mbi crct10dif_pclmul snd_timer crc32_pclmul crc32c_intel ghash_clmulni_intel snd soundcore ppdev pvpanic parport_pc i2c_piix4 serio_raw virtio_balloon parport acpi_cpufreq nfsd nfs_acl lockd grace auth_rpcgss sunrpc qxl drm_kms_helper virtio_net virtio_console virtio_blk ttm drm virtio_pci virtio_ring virtio ata_generic pata_acpi
      [ 9839.008069] CPU: 0 PID: 308 Comm: kworker/0:1H Not tainted 4.0.0-0.rc4.git1.3.fc23.x86_64 #1
      [ 9839.008069] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [ 9839.008069] Workqueue: rpciod rpc_async_schedule [sunrpc]
      [ 9839.008069] task: ffff8800d8b4d8e0 ti: ffff880036678000 task.ti: ffff880036678000
      [ 9839.008069] RIP: 0010:[<ffffffffa0339cc9>]  [<ffffffffa0339cc9>] reserve_space.part.73+0x9/0x10 [nfsv4]
      [ 9839.008069] RSP: 0018:ffff88003667ba58  EFLAGS: 00010246
      [ 9839.008069] RAX: 0000000000000000 RBX: 000000001fc15e18 RCX: ffff8800c0193800
      [ 9839.008069] RDX: ffff8800e4ae3f24 RSI: 000000001fc15e2c RDI: ffff88003667bcd0
      [ 9839.008069] RBP: ffff88003667ba58 R08: ffff8800d9173008 R09: 0000000000000003
      [ 9839.008069] R10: ffff88003667bcd0 R11: 000000000000000c R12: 0000000000010000
      [ 9839.008069] R13: ffff8800d9173350 R14: 0000000000000000 R15: ffff8800c0067b98
      [ 9839.008069] FS:  0000000000000000(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000
      [ 9839.008069] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 9839.008069] CR2: 00007f988c9c8bb0 CR3: 00000000d99b6000 CR4: 00000000000407f0
      [ 9839.008069] Stack:
      [ 9839.008069]  ffff88003667bbc8 ffffffffa03412c5 00000000c6c55680 ffff880000000003
      [ 9839.008069]  0000000000000088 00000010c6c55680 0001000000000002 ffffffff816e87e9
      [ 9839.008069]  0000000000000000 00000000477290e2 ffff88003667bab8 ffffffff81327ba3
      [ 9839.008069] Call Trace:
      [ 9839.008069]  [<ffffffffa03412c5>] encode_attrs+0x435/0x530 [nfsv4]
      [ 9839.008069]  [<ffffffff816e87e9>] ? inet_sendmsg+0x69/0xb0
      [ 9839.008069]  [<ffffffff81327ba3>] ? selinux_socket_sendmsg+0x23/0x30
      [ 9839.008069]  [<ffffffff8164c1df>] ? do_sock_sendmsg+0x9f/0xc0
      [ 9839.008069]  [<ffffffff8164c278>] ? kernel_sendmsg+0x58/0x70
      [ 9839.008069]  [<ffffffffa011acc0>] ? xdr_reserve_space+0x20/0x170 [sunrpc]
      [ 9839.008069]  [<ffffffffa011acc0>] ? xdr_reserve_space+0x20/0x170 [sunrpc]
      [ 9839.008069]  [<ffffffffa0341b40>] ? nfs4_xdr_enc_open_noattr+0x130/0x130 [nfsv4]
      [ 9839.008069]  [<ffffffffa03419a5>] encode_open+0x2d5/0x340 [nfsv4]
      [ 9839.008069]  [<ffffffffa0341b40>] ? nfs4_xdr_enc_open_noattr+0x130/0x130 [nfsv4]
      [ 9839.008069]  [<ffffffffa011ab89>] ? xdr_encode_opaque+0x19/0x20 [sunrpc]
      [ 9839.008069]  [<ffffffffa0339cfb>] ? encode_string+0x2b/0x40 [nfsv4]
      [ 9839.008069]  [<ffffffffa0341bf3>] nfs4_xdr_enc_open+0xb3/0x140 [nfsv4]
      [ 9839.008069]  [<ffffffffa0110a4c>] rpcauth_wrap_req+0xac/0xf0 [sunrpc]
      [ 9839.008069]  [<ffffffffa01017db>] call_transmit+0x18b/0x2d0 [sunrpc]
      [ 9839.008069]  [<ffffffffa0101650>] ? call_decode+0x860/0x860 [sunrpc]
      [ 9839.008069]  [<ffffffffa0101650>] ? call_decode+0x860/0x860 [sunrpc]
      [ 9839.008069]  [<ffffffffa010caa0>] __rpc_execute+0x90/0x460 [sunrpc]
      [ 9839.008069]  [<ffffffffa010ce85>] rpc_async_schedule+0x15/0x20 [sunrpc]
      [ 9839.008069]  [<ffffffff810b452b>] process_one_work+0x1bb/0x410
      [ 9839.008069]  [<ffffffff810b47d3>] worker_thread+0x53/0x470
      [ 9839.008069]  [<ffffffff810b4780>] ? process_one_work+0x410/0x410
      [ 9839.008069]  [<ffffffff810b4780>] ? process_one_work+0x410/0x410
      [ 9839.008069]  [<ffffffff810ba7b8>] kthread+0xd8/0xf0
      [ 9839.008069]  [<ffffffff810ba6e0>] ? kthread_worker_fn+0x180/0x180
      [ 9839.008069]  [<ffffffff81786418>] ret_from_fork+0x58/0x90
      [ 9839.008069]  [<ffffffff810ba6e0>] ? kthread_worker_fn+0x180/0x180
      [ 9839.008069] Code: 00 00 48 c7 c7 21 fa 37 a0 e8 94 1c d6 e0 c6 05 d2 17 05 00 01 8b 03 eb d7 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 <0f> 0b 0f 1f 44 00 00 66 66 66 66 90 55 48 89 e5 41 54 53 89 f3
      [ 9839.008069] RIP  [<ffffffffa0339cc9>] reserve_space.part.73+0x9/0x10 [nfsv4]
      [ 9839.008069]  RSP <ffff88003667ba58>
      [ 9839.071114] ---[ end trace cc14c03adb522e94 ]---
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      a49c2691
    • Jeff Layton's avatar
      nfs: plug memory leak when ->prepare_layoutcommit fails · 3471648a
      Jeff Layton authored
      "data" is currently leaked when the prepare_layoutcommit operation
      returns an error. Put the cred before taking the spinlock in that
      case, take the lock and then goto out_unlock which will drop the
      lock and then free "data".
      Signed-off-by: default avatarJeff Layton <jeff.layton@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      3471648a
  2. 27 Jul, 2015 5 commits
    • Trond Myklebust's avatar
    • NeilBrown's avatar
      sunrpc: translate -EAGAIN to -ENOBUFS when socket is writable. · 743c69e7
      NeilBrown authored
      The networking layer does not reliably report the distinction between
      a non-block write failing because:
       1/ the queue is too full already and
       2/ a memory allocation attempt failed.
      
      The distinction is important because in the first case it is
      appropriate to retry as soon as the socket reports that it is
      writable, and in the second case a small delay is required as the
      socket will most likely report as writable but kmalloc could still
      fail.
      
      sk_stream_wait_memory() exhibits this distinction nicely, setting
      'vm_wait' if a small wait is needed.  However in the non-blocking case
      it always returns -EAGAIN no matter the cause of the failure.  This
      -EAGAIN call get all the way to sunrpc.
      
      The sunrpc layer expects EAGAIN to indicate the first cause, and
      ENOBUFS to indicate the second.  Various documentation suggests that
      this is not unreasonable, but does not guarantee the desired error
      codes.
      
      The result of getting -EAGAIN when -ENOBUFS is expected is that the
      send is tried again in a tight loop and soft lockups are reported.
      
      so: add tests after calls to xs_sendpages() to translate -EAGAIN into
      -ENOBUFS if the socket is writable.  This cannot happen inside
      xs_sendpages() as the test for "is socket writable" is different
      between TCP and UDP.
      
      With this change, the tight loop retrying xs_sendpages() becomes a
      loop which only retries every 250ms, and so will not trigger a
      soft-lockup warning.
      
      It is possible that the write did fail because the queue was too full
      and by the time xs_sendpages() completed, the queue was writable
      again.  In this case an extra 250ms delay is inserted that isn't
      really needed.  This circumstance suggests a degree of congestion so a
      delay is not necessarily a bad thing, and it can only cause a single
      250ms delay, not a series of them.
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      743c69e7
    • J. Bruce Fields's avatar
      NFSv4.2: handle NFS-specific llseek errors · bdcc2cd1
      J. Bruce Fields authored
      Handle NFS-specific llseek errors instead of letting them leak out to
      userspace.
      Reported-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      bdcc2cd1
    • Trond Myklebust's avatar
      NFS: Don't clear desc->pg_moreio in nfs_do_recoalesce() · d4c30454
      Trond Myklebust authored
      Recoalescing does not affect whether or not we've already sent off
      I/O, and doing so means that we end up sending a bunch of synchronous
      for cases where we actually need to be using unstable writes.
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      d4c30454
    • Trond Myklebust's avatar
      NFS: Fix a memory leak in nfs_do_recoalesce · 03d5eb65
      Trond Myklebust authored
      If the function exits early, then we must put those requests that were
      not processed back onto the &mirror->pg_list so they can be cleaned up
      by nfs_pgio_error().
      
      Fixes: a7d42ddb ("nfs: add mirroring support to pgio layer")
      Cc: stable@vger.kernel.org # v4.0+
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      03d5eb65
  3. 22 Jul, 2015 8 commits
  4. 11 Jul, 2015 5 commits
  5. 08 Jul, 2015 1 commit
  6. 05 Jul, 2015 5 commits
  7. 03 Jul, 2015 2 commits
  8. 01 Jul, 2015 9 commits
  9. 29 Jun, 2015 1 commit
    • NeilBrown's avatar
      NFSv4: When returning a delegation, don't reclaim an incompatible open mode. · 39f897fd
      NeilBrown authored
      It is possible to have an active open with one mode, and a delegation
      for the same file with a different mode.
      In particular, a WR_ONLY open and an RD_ONLY delegation.
      This happens if a WR_ONLY open is followed by a RD_ONLY open which
      provides a delegation, but is then close.
      
      When returning the delegation, we currently try to claim opens for
      every open type (n_rdwr, n_rdonly, n_wronly).  As there is no harm
      in claiming an open for a mode that we already have, this is often
      simplest.
      
      However if the delegation only provides a subset of the modes that we
      currently have open, this will produce an error from the server.
      
      So when claiming open modes prior to returning a delegation, skip the
      open request if the mode is not covered by the delegation - the open_stateid
      must already cover that mode, so there is nothing to do.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      39f897fd
  10. 27 Jun, 2015 2 commits