1. 07 Apr, 2022 10 commits
  2. 30 Mar, 2022 3 commits
  3. 28 Mar, 2022 1 commit
  4. 26 Mar, 2022 1 commit
  5. 25 Mar, 2022 2 commits
  6. 24 Mar, 2022 3 commits
  7. 23 Mar, 2022 1 commit
    • NeilBrown's avatar
      SUNRPC: avoid race between mod_timer() and del_timer_sync() · 3848e96e
      NeilBrown authored
      xprt_destory() claims XPRT_LOCKED and then calls del_timer_sync().
      Both xprt_unlock_connect() and xprt_release() call
       ->release_xprt()
      which drops XPRT_LOCKED and *then* xprt_schedule_autodisconnect()
      which calls mod_timer().
      
      This may result in mod_timer() being called *after* del_timer_sync().
      When this happens, the timer may fire long after the xprt has been freed,
      and run_timer_softirq() will probably crash.
      
      The pairing of ->release_xprt() and xprt_schedule_autodisconnect() is
      always called under ->transport_lock.  So if we take ->transport_lock to
      call del_timer_sync(), we can be sure that mod_timer() will run first
      (if it runs at all).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      3848e96e
  8. 22 Mar, 2022 16 commits
  9. 21 Mar, 2022 1 commit
  10. 13 Mar, 2022 2 commits
    • NeilBrown's avatar
      SUNRPC: change locking for xs_swap_enable/disable · 693486d5
      NeilBrown authored
      It is not in general safe to wait for XPRT_LOCKED to clear.
      A wakeup is only sent when
       - connection completes
       - sock close completes
      so during normal operations, this can wait indefinitely.
      
      The event we need to protect against is ->inet being set to NULL, and
      that happens under the recv_mutex lock.
      
      So drop the handlign of XPRT_LOCKED and use recv_mutex instead.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      693486d5
    • NeilBrown's avatar
      NFS: swap-out must always use STABLE writes. · c265de25
      NeilBrown authored
      The commit handling code is not safe against memory-pressure deadlocks
      when writing to swap.  In particular, nfs_commitdata_alloc() blocks
      indefinitely waiting for memory, and this can consume all available
      workqueue threads.
      
      swap-out most likely uses STABLE writes anyway as COND_STABLE indicates
      that a stable write should be used if the write fits in a single
      request, and it normally does.  However if we ever swap with a small
      wsize, or gather unusually large numbers of pages for a single write,
      this might change.
      
      For safety, make it explicit in the code that direct writes used for swap
      must always use FLUSH_STABLE.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      c265de25