1. 21 Jul, 2019 1 commit
  2. 10 Jul, 2019 1 commit
    • Chuck Lever's avatar
      svcrdma: Ignore source port when computing DRC hash · 44b14046
      Chuck Lever authored
      commit 1e091c3bbf51d34d5d96337a59ce5ab2ac3ba2cc upstream.
      
      The DRC appears to be effectively empty after an RPC/RDMA transport
      reconnect. The problem is that each connection uses a different
      source port, which defeats the DRC hash.
      
      Clients always have to disconnect before they send retransmissions
      to reset the connection's credit accounting, thus every retransmit
      on NFS/RDMA will miss the DRC.
      
      An NFS/RDMA client's IP source port is meaningless for RDMA
      transports. The transport layer typically sets the source port value
      on the connection to a random ephemeral port. The server already
      ignores it for the "secure port" check. See commit 16e4d93f
      ("NFSD: Ignore client's source port on RDMA transports").
      
      The Linux NFS server's DRC resolves XID collisions from the same
      source IP address by using the checksum of the first 200 bytes of
      the RPC call header.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: stable@vger.kernel.org # v4.14+
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44b14046
  3. 02 May, 2019 1 commit
    • NeilBrown's avatar
      sunrpc: don't mark uninitialised items as VALID. · 790899da
      NeilBrown authored
      commit d58431eacb226222430940134d97bfd72f292fcd upstream.
      
      A recent commit added a call to cache_fresh_locked()
      when an expired item was found.
      The call sets the CACHE_VALID flag, so it is important
      that the item actually is valid.
      There are two ways it could be valid:
      1/ If ->update has been called to fill in relevant content
      2/ if CACHE_NEGATIVE is set, to say that content doesn't exist.
      
      An expired item that is waiting for an update will be neither.
      Setting CACHE_VALID will mean that a subsequent call to cache_put()
      will be likely to dereference uninitialised pointers.
      
      So we must make sure the item is valid, and we already have code to do
      that in try_to_negate_entry().  This takes the hash lock and so cannot
      be used directly, so take out the two lines that we need and use them.
      
      Now cache_fresh_locked() is certain to be called only on
      a valid item.
      
      Cc: stable@kernel.org # 2.6.35
      Fixes: 4ecd55ea0742 ("sunrpc: fix cache_head leak due to queued request")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      790899da
  4. 23 Feb, 2019 1 commit
  5. 23 Jan, 2019 1 commit
  6. 16 Jan, 2019 1 commit
    • Vasily Averin's avatar
      sunrpc: use-after-free in svc_process_common() · 65dba325
      Vasily Averin authored
      commit d4b09acf924b84bae77cad090a9d108e70b43643 upstream.
      
      if node have NFSv41+ mounts inside several net namespaces
      it can lead to use-after-free in svc_process_common()
      
      svc_process_common()
              /* Setup reply header */
              rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr(rqstp); <<< HERE
      
      svc_process_common() can use incorrect rqstp->rq_xprt,
      its caller function bc_svc_process() takes it from serv->sv_bc_xprt.
      The problem is that serv is global structure but sv_bc_xprt
      is assigned per-netnamespace.
      
      According to Trond, the whole "let's set up rqstp->rq_xprt
      for the back channel" is nothing but a giant hack in order
      to work around the fact that svc_process_common() uses it
      to find the xpt_ops, and perform a couple of (meaningless
      for the back channel) tests of xpt_flags.
      
      All we really need in svc_process_common() is to be able to run
      rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr()
      
      Bruce J Fields points that this xpo_prep_reply_hdr() call
      is an awfully roundabout way just to do "svc_putnl(resv, 0);"
      in the tcp case.
      
      This patch does not initialiuze rqstp->rq_xprt in bc_svc_process(),
      now it calls svc_process_common() with rqstp->rq_xprt = NULL.
      
      To adjust reply header svc_process_common() just check
      rqstp->rq_prot and calls svc_tcp_prep_reply_hdr() for tcp case.
      
      To handle rqstp->rq_xprt = NULL case in functions called from
      svc_process_common() patch intruduces net namespace pointer
      svc_rqst->rq_bc_net and adjust SVC_NET() definition.
      Some other function was also adopted to properly handle described case.
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Cc: stable@vger.kernel.org
      Fixes: 23c20ecd ("NFS: callback up - users counting cleanup")
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      v2: - added lost extern svc_tcp_prep_reply_hdr()
          - dropped trace_svc_process() changes
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      65dba325
  7. 13 Jan, 2019 3 commits
  8. 09 Jan, 2019 1 commit
    • Deepa Dinamani's avatar
      sock: Make sock->sk_stamp thread-safe · e5af70e9
      Deepa Dinamani authored
      [ Upstream commit 3a0ed3e9619738067214871e9cb826fa23b2ddb9 ]
      
      Al Viro mentioned (Message-ID
      <20170626041334.GZ10672@ZenIV.linux.org.uk>)
      that there is probably a race condition
      lurking in accesses of sk_stamp on 32-bit machines.
      
      sock->sk_stamp is of type ktime_t which is always an s64.
      On a 32 bit architecture, we might run into situations of
      unsafe access as the access to the field becomes non atomic.
      
      Use seqlocks for synchronization.
      This allows us to avoid using spinlocks for readers as
      readers do not need mutual exclusion.
      
      Another approach to solve this is to require sk_lock for all
      modifications of the timestamps. The current approach allows
      for timestamps to have their own lock: sk_stamp_lock.
      This allows for the patch to not compete with already
      existing critical sections, and side effects are limited
      to the paths in the patch.
      
      The addition of the new field maintains the data locality
      optimizations from
      commit 9115e8cd ("net: reorganize struct sock for better data
      locality")
      
      Note that all the instances of the sk_stamp accesses
      are either through the ioctl or the syscall recvmsg.
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e5af70e9
  9. 21 Dec, 2018 1 commit
    • Trond Myklebust's avatar
      SUNRPC: Fix a potential race in xprt_connect() · c3f68415
      Trond Myklebust authored
      [ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
      
      If an asynchronous connection attempt completes while another task is
      in xprt_connect(), then the call to rpc_sleep_on() could end up
      racing with the call to xprt_wake_pending_tasks().
      So add a second test of the connection state after we've put the
      task to sleep and set the XPRT_CONNECTING flag, when we know that there
      can be no asynchronous connection attempts still in progress.
      
      Fixes: 0b9e7943 ("SUNRPC: Move the test for XPRT_CONNECTING into...")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c3f68415
  10. 13 Dec, 2018 1 commit
  11. 01 Dec, 2018 1 commit
  12. 27 Nov, 2018 1 commit
  13. 21 Nov, 2018 1 commit
  14. 13 Nov, 2018 1 commit
  15. 15 Sep, 2018 1 commit
    • Laura Abbott's avatar
      sunrpc: Don't use stack buffer with scatterlist · 8b89affb
      Laura Abbott authored
      [ Upstream commit 44090cc8 ]
      
      Fedora got a bug report from NFS:
      
      kernel BUG at include/linux/scatterlist.h:143!
      ...
      RIP: 0010:sg_init_one+0x7d/0x90
      ..
        make_checksum+0x4e7/0x760 [rpcsec_gss_krb5]
        gss_get_mic_kerberos+0x26e/0x310 [rpcsec_gss_krb5]
        gss_marshal+0x126/0x1a0 [auth_rpcgss]
        ? __local_bh_enable_ip+0x80/0xe0
        ? call_transmit_status+0x1d0/0x1d0 [sunrpc]
        call_transmit+0x137/0x230 [sunrpc]
        __rpc_execute+0x9b/0x490 [sunrpc]
        rpc_run_task+0x119/0x150 [sunrpc]
        nfs4_run_exchange_id+0x1bd/0x250 [nfsv4]
        _nfs4_proc_exchange_id+0x2d/0x490 [nfsv4]
        nfs41_discover_server_trunking+0x1c/0xa0 [nfsv4]
        nfs4_discover_server_trunking+0x80/0x270 [nfsv4]
        nfs4_init_client+0x16e/0x240 [nfsv4]
        ? nfs_get_client+0x4c9/0x5d0 [nfs]
        ? _raw_spin_unlock+0x24/0x30
        ? nfs_get_client+0x4c9/0x5d0 [nfs]
        nfs4_set_client+0xb2/0x100 [nfsv4]
        nfs4_create_server+0xff/0x290 [nfsv4]
        nfs4_remote_mount+0x28/0x50 [nfsv4]
        mount_fs+0x3b/0x16a
        vfs_kern_mount.part.35+0x54/0x160
        nfs_do_root_mount+0x7f/0xc0 [nfsv4]
        nfs4_try_mount+0x43/0x70 [nfsv4]
        ? get_nfs_version+0x21/0x80 [nfs]
        nfs_fs_mount+0x789/0xbf0 [nfs]
        ? pcpu_alloc+0x6ca/0x7e0
        ? nfs_clone_super+0x70/0x70 [nfs]
        ? nfs_parse_mount_options+0xb40/0xb40 [nfs]
        mount_fs+0x3b/0x16a
        vfs_kern_mount.part.35+0x54/0x160
        do_mount+0x1fd/0xd50
        ksys_mount+0xba/0xd0
        __x64_sys_mount+0x21/0x30
        do_syscall_64+0x60/0x1f0
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      This is BUG_ON(!virt_addr_valid(buf)) triggered by using a stack
      allocated buffer with a scatterlist. Convert the buffer for
      rc4salt to be dynamically allocated instead.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1615258Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b89affb
  16. 09 Sep, 2018 1 commit
    • Bill Baker's avatar
      NFSv4 client live hangs after live data migration recovery · bf23ba37
      Bill Baker authored
      commit 0f90be13 upstream.
      
      After a live data migration event at the NFS server, the client may send
      I/O requests to the wrong server, causing a live hang due to repeated
      recovery events.  On the wire, this will appear as an I/O request failing
      with NFS4ERR_BADSESSION, followed by successful CREATE_SESSION, repeatedly.
      NFS4ERR_BADSSESSION is returned because the session ID being used was
      issued by the other server and is not valid at the old server.
      
      The failure is caused by async worker threads having cached the transport
      (xprt) in the rpc_task structure.  After the migration recovery completes,
      the task is redispatched and the task resends the request to the wrong
      server based on the old value still present in tk_xprt.
      
      The solution is to recompute the tk_xprt field of the rpc_task structure
      so that the request goes to the correct server.
      Signed-off-by: default avatarBill Baker <bill.baker@oracle.com>
      Reviewed-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarHelen Chao <helen.chao@oracle.com>
      Fixes: fb43d172 ("SUNRPC: Use the multipath iterator to assign a ...")
      Cc: stable@vger.kernel.org # v4.9+
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf23ba37
  17. 22 Jul, 2018 1 commit
  18. 03 Jul, 2018 1 commit
  19. 26 Apr, 2018 3 commits
    • Trond Myklebust's avatar
      SUNRPC: Don't call __UDPX_INC_STATS() from a preemptible context · 26bebd5a
      Trond Myklebust authored
      
      [ Upstream commit 0afa6b44 ]
      
      Calling __UDPX_INC_STATS() from a preemptible context leads to a
      warning of the form:
      
       BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u5:0/31
       caller is xs_udp_data_receive_workfn+0x194/0x270
       CPU: 1 PID: 31 Comm: kworker/u5:0 Not tainted 4.15.0-rc8-00076-g90ea9f1b #2
       Workqueue: xprtiod xs_udp_data_receive_workfn
       Call Trace:
        dump_stack+0x85/0xc1
        check_preemption_disabled+0xce/0xe0
        xs_udp_data_receive_workfn+0x194/0x270
        process_one_work+0x318/0x620
        worker_thread+0x20a/0x390
        ? process_one_work+0x620/0x620
        kthread+0x120/0x130
        ? __kthread_bind_mask+0x60/0x60
        ret_from_fork+0x24/0x30
      
      Since we're taking a spinlock in those functions anyway, let's fix the
      issue by moving the call so that it occurs under the spinlock.
      Reported-by: default avatarkernel test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      26bebd5a
    • Chuck Lever's avatar
      svcrdma: Fix Read chunk round-up · 0b1fa241
      Chuck Lever authored
      
      [ Upstream commit 175e0310 ]
      
      A single NFSv4 WRITE compound can often have three operations:
      PUTFH, WRITE, then GETATTR.
      
      When the WRITE payload is sent in a Read chunk, the client places
      the GETATTR in the inline part of the RPC/RDMA message, just after
      the WRITE operation (sans payload). The position value in the Read
      chunk enables the receiver to insert the Read chunk at the correct
      place in the received XDR stream; that is between the WRITE and
      GETATTR.
      
      According to RFC 8166, an NFS/RDMA client does not have to add XDR
      round-up to the Read chunk that carries the WRITE payload. The
      receiver adds XDR round-up padding if it is absent and the
      receiver's XDR decoder requires it to be present.
      
      Commit 193bcb7b ("svcrdma: Populate tail iovec when receiving")
      attempted to add support for receiving such a compound so that just
      the WRITE payload appears in rq_arg's page list, and the trailing
      GETATTR is placed in rq_arg's tail iovec. (TCP just strings the
      whole compound into the head iovec and page list, without regard
      to the alignment of the WRITE payload).
      
      The server transport logic also had to accommodate the optional XDR
      round-up of the Read chunk, which it did simply by lengthening the
      tail iovec when round-up was needed. This approach is adequate for
      the NFSv2 and NFSv3 WRITE decoders.
      
      Unfortunately it is not sufficient for nfsd4_decode_write. When the
      Read chunk length is a couple of bytes less than PAGE_SIZE, the
      computation at the end of nfsd4_decode_write allows argp->pagelen to
      go negative, which breaks the logic in read_buf that looks for the
      tail iovec.
      
      The result is that a WRITE operation whose payload length is just
      less than a multiple of a page succeeds, but the subsequent GETATTR
      in the same compound fails with NFS4ERR_OP_ILLEGAL because the XDR
      decoder can't find it. Clients ignore the error, but they must
      update their attribute cache via a separate round trip.
      
      As nfsd4_decode_write appears to expect the payload itself to always
      have appropriate XDR round-up, have svc_rdma_build_normal_read_chunk
      add the Read chunk XDR round-up to the page_len rather than
      lengthening the tail iovec.
      Reported-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Fixes: 193bcb7b ("svcrdma: Populate tail iovec when receiving")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b1fa241
    • Chuck Lever's avatar
      xprtrdma: Fix backchannel allocation of extra rpcrdma_reps · 342d9092
      Chuck Lever authored
      
      [ Upstream commit d698c4a0 ]
      
      The backchannel code uses rpcrdma_recv_buffer_put to add new reps
      to the free rep list. This also decrements rb_recv_count, which
      spoofs the receive overrun logic in rpcrdma_buffer_get_rep.
      
      Commit 9b06688b ("xprtrdma: Fix additional uses of
      spin_lock_irqsave(rb_lock)") replaced the original open-coded
      list_add with a call to rpcrdma_recv_buffer_put(), but then a year
      later, commit 05c97466 ("xprtrdma: Fix receive buffer
      accounting") added rep accounting to rpcrdma_recv_buffer_put.
      It was an oversight to let the backchannel continue to use this
      function.
      
      The fix this, let's combine the "add to free list" logic with
      rpcrdma_create_rep.
      
      Also, do not allocate RPCRDMA_MAX_BC_REQUESTS rpcrdma_reps in
      rpcrdma_buffer_create and then allocate additional rpcrdma_reps in
      rpcrdma_bc_setup_reps. Allocating the extra reps during backchannel
      set-up is sufficient.
      
      Fixes: 05c97466 ("xprtrdma: Fix receive buffer accounting")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      342d9092
  20. 24 Apr, 2018 1 commit
  21. 19 Apr, 2018 1 commit
    • Eric Biggers's avatar
      sunrpc: remove incorrect HMAC request initialization · e4fa275b
      Eric Biggers authored
      commit f3aefb6a upstream.
      
      make_checksum_hmac_md5() is allocating an HMAC transform and doing
      crypto API calls in the following order:
      
          crypto_ahash_init()
          crypto_ahash_setkey()
          crypto_ahash_digest()
      
      This is wrong because it makes no sense to init() the request before a
      key has been set, given that the initial state depends on the key.  And
      digest() is short for init() + update() + final(), so in this case
      there's no need to explicitly call init() at all.
      
      Before commit 9fa68f62 ("crypto: hash - prevent using keyed hashes
      without setting key") the extra init() had no real effect, at least for
      the software HMAC implementation.  (There are also hardware drivers that
      implement HMAC-MD5, and it's not immediately obvious how gracefully they
      handle init() before setkey().)  But now the crypto API detects this
      incorrect initialization and returns -ENOKEY.  This is breaking NFS
      mounts in some cases.
      
      Fix it by removing the incorrect call to crypto_ahash_init().
      Reported-by: default avatarMichael Young <m.a.young@durham.ac.uk>
      Fixes: 9fa68f62 ("crypto: hash - prevent using keyed hashes without setting key")
      Fixes: fffdaef2 ("gss_krb5: Add support for rc4-hmac encryption")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4fa275b
  22. 22 Feb, 2018 2 commits
    • Chuck Lever's avatar
      xprtrdma: Fix BUG after a device removal · 67154fb8
      Chuck Lever authored
      commit e89e8d8f upstream.
      
      Michal Kalderon reports a BUG that occurs just after device removal:
      
      [  169.112490] rpcrdma: removing device qedr0 for 192.168.110.146:20049
      [  169.143909] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      [  169.181837] IP: rpcrdma_dma_unmap_regbuf+0xa/0x60 [rpcrdma]
      
      The RPC/RDMA client transport attempts to allocate some resources
      on demand. Registered buffers are one such resource. These are
      allocated (or re-allocated) by xprt_rdma_allocate to hold RPC Call
      and Reply messages. A hardware resource is associated with each of
      these buffers, as they can be used for a Send or Receive Work
      Request.
      
      If a device is removed from under an NFS/RDMA mount, the transport
      layer is responsible for releasing all hardware resources before
      the device can be finally unplugged. A BUG results when the NFS
      mount hasn't yet seen much activity: the transport tries to release
      resources that haven't yet been allocated.
      
      rpcrdma_free_regbuf() already checks for this case, so just move
      that check to cover the DEVICE_REMOVAL case as well.
      Reported-by: default avatarMichal Kalderon <Michal.Kalderon@cavium.com>
      Fixes: bebd0318 ("xprtrdma: Support unplugging an HCA ...")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarMichal Kalderon <Michal.Kalderon@cavium.com>
      Cc: stable@vger.kernel.org # v4.12+
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67154fb8
    • Chuck Lever's avatar
      xprtrdma: Fix calculation of ri_max_send_sges · 84b41e37
      Chuck Lever authored
      commit 1179e2c2 upstream.
      
      Commit 16f906d6 ("xprtrdma: Reduce required number of send
      SGEs") introduced the rpcrdma_ia::ri_max_send_sges field. This fixes
      a problem where xprtrdma would not work if the device's max_sge
      capability was small (low single digits).
      
      At least RPCRDMA_MIN_SEND_SGES are needed for the inline parts of
      each RPC. ri_max_send_sges is set to this value:
      
        ia->ri_max_send_sges = max_sge - RPCRDMA_MIN_SEND_SGES;
      
      Then when marshaling each RPC, rpcrdma_args_inline uses that value
      to determine whether the device has enough Send SGEs to convey an
      NFS WRITE payload inline, or whether instead a Read chunk is
      required.
      
      More recently, commit ae72950a ("xprtrdma: Add data structure to
      manage RDMA Send arguments") used the ri_max_send_sges value to
      calculate the size of an array, but that commit erroneously assumed
      ri_max_send_sges contains a value similar to the device's max_sge,
      and not one that was reduced by the minimum SGE count.
      
      This assumption results in the calculated size of the sendctx's
      Send SGE array to be too small. When the array is used to marshal
      an RPC, the code can write Send SGEs into the following sendctx
      element in that array, corrupting it. When the device's max_sge is
      large, this issue is entirely harmless; but it results in an oops
      in the provider's post_send method, if dev.attrs.max_sge is small.
      
      So let's straighten this out: ri_max_send_sges will now contain a
      value with the same meaning as dev.attrs.max_sge, which makes
      the code easier to understand, and enables rpcrdma_sendctx_create
      to calculate the size of the SGE array correctly.
      Reported-by: default avatarMichal Kalderon <Michal.Kalderon@cavium.com>
      Fixes: 16f906d6 ("xprtrdma: Reduce required number of send SGEs")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarMichal Kalderon <Michal.Kalderon@cavium.com>
      Cc: stable@vger.kernel.org # v4.10+
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84b41e37
  23. 03 Feb, 2018 1 commit
  24. 20 Dec, 2017 3 commits
  25. 14 Dec, 2017 1 commit
  26. 30 Nov, 2017 1 commit
    • Chuck Lever's avatar
      svcrdma: Preserve CB send buffer across retransmits · a7a05def
      Chuck Lever authored
      commit 0bad47ca upstream.
      
      During each NFSv4 callback Call, an RDMA Send completion frees the
      page that contains the RPC Call message. If the upper layer
      determines that a retransmit is necessary, this is too soon.
      
      One possible symptom: after a GARBAGE_ARGS response an NFSv4.1
      callback request, the following BUG fires on the NFS server:
      
      kernel: BUG: Bad page state in process kworker/0:2H  pfn:7d3ce2
      kernel: page:ffffea001f4f3880 count:-2 mapcount:0 mapping:          (null) index:0x0
      kernel: flags: 0x2fffff80000000()
      kernel: raw: 002fffff80000000 0000000000000000 0000000000000000 fffffffeffffffff
      kernel: raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
      kernel: page dumped because: nonzero _refcount
      kernel: Modules linked in: cts rpcsec_gss_krb5 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm
      ocfs2_nodemanager ocfs2_stackglue rpcrdm a ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad
      rdma_cm ib_cm iw_cm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
      kvm irqbypass crct10dif_pc lmul crc32_pclmul ghash_clmulni_intel pcbc iTCO_wdt
      iTCO_vendor_support aesni_intel crypto_simd glue_helper cryptd pcspkr lpc_ich i2c_i801
      mei_me mf d_core mei raid0 sg wmi ioatdma ipmi_si ipmi_devintf ipmi_msghandler shpchp
      acpi_power_meter acpi_pad nfsd nfs_acl lockd auth_rpcgss grace sunrpc ip_tables xfs
      libcrc32c mlx4_en mlx4_ib mlx5_ib ib_core sd_mod sr_mod cdrom ast drm_kms_helper
      syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ahci crc32c_intel libahci drm
      mlx5_core igb libata mlx4_core dca i2c_algo_bit i2c_core nvme
      kernel: ptp nvme_core pps_core dm_mirror dm_region_hash dm_log dm_mod dax
      kernel: CPU: 0 PID: 11495 Comm: kworker/0:2H Not tainted 4.14.0-rc3-00001-g577ce48 #811
      kernel: Hardware name: Supermicro Super Server/X10SRL-F, BIOS 1.0c 09/09/2015
      kernel: Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
      kernel: Call Trace:
      kernel: dump_stack+0x62/0x80
      kernel: bad_page+0xfe/0x11a
      kernel: free_pages_check_bad+0x76/0x78
      kernel: free_pcppages_bulk+0x364/0x441
      kernel: ? ttwu_do_activate.isra.61+0x71/0x78
      kernel: free_hot_cold_page+0x1c5/0x202
      kernel: __put_page+0x2c/0x36
      kernel: svc_rdma_put_context+0xd9/0xe4 [rpcrdma]
      kernel: svc_rdma_wc_send+0x50/0x98 [rpcrdma]
      
      This issue exists all the way back to v4.5, but refactoring and code
      re-organization prevents this simple patch from applying to kernels
      older than v4.12. The fix is the same, however, if someone needs to
      backport it.
      Reported-by: default avatarBen Coddington <bcodding@redhat.com>
      BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=314
      Fixes: 5d252f90 ('svcrdma: Add class for RDMA backwards ... ')
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7a05def
  27. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  28. 19 Oct, 2017 1 commit
  29. 16 Oct, 2017 1 commit
  30. 01 Oct, 2017 1 commit
  31. 25 Sep, 2017 1 commit
  32. 06 Sep, 2017 1 commit
    • NeilBrown's avatar
      SUNRPC: remove some dead code. · f1ecbc21
      NeilBrown authored
      RPC_TASK_NO_RETRANS_TIMEOUT is set when cl_noretranstimeo
      is set, which happens when  RPC_CLNT_CREATE_NO_RETRANS_TIMEOUT is set,
      which happens when NFS_CS_NO_RETRANS_TIMEOUT is set.
      
      This flag means "don't resend on a timeout, only resend if the
      connection gets broken for some reason".
      
      cl_discrtry is set when RPC_CLNT_CREATE_DISCRTRY is set, which
      happens when NFS_CS_DISCRTRY is set.
      
      This flag means "always disconnect before resending".
      
      NFS_CS_NO_RETRANS_TIMEOUT and NFS_CS_DISCRTRY are both only set
      in nfs4_init_client(), and it always sets both.
      
      So we will never have a situation where only one of the flags is set.
      So this code, which tests if timeout retransmits are allowed, and
      disconnection is required, will never run.
      
      So it makes sense to remove this code as it cannot be tested and
      could confuse people reading the code (like me).
      
      (alternately we could leave it there with a comment saying
       it is never actually used).
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      f1ecbc21
  33. 05 Sep, 2017 1 commit
    • Chuck Lever's avatar
      xprtrdma: Use xprt_pin_rqst in rpcrdma_reply_handler · 9590d083
      Chuck Lever authored
      Adopt the use of xprt_pin_rqst to eliminate contention between
      Call-side users of rb_lock and the use of rb_lock in
      rpcrdma_reply_handler.
      
      This replaces the mechanism introduced in 431af645 ("xprtrdma:
      Fix client lock-up after application signal fires").
      
      Use recv_lock to quickly find the completing rqst, pin it, then
      drop the lock. At that point invalidation and pull-up of the Reply
      XDR can be done. Both are often expensive operations.
      
      Finally, take recv_lock again to signal completion to the RPC
      layer. It also protects adjustment of "cwnd".
      
      This greatly reduces the amount of time a lock is held by the
      reply handler. Comparing lock_stat results shows a marked decrease
      in contention on rb_lock and recv_lock.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      [trond.myklebust@primarydata.com: Remove call to rpcrdma_buffer_put() from
         the "out_norqst:" path in rpcrdma_reply_handler.]
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      9590d083