Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. Apr 07, 2022
  2. Mar 29, 2022
  3. Mar 28, 2022
  4. Mar 25, 2022
  5. Mar 24, 2022
  6. Mar 23, 2022
    • 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
  7. Mar 22, 2022
  8. Mar 21, 2022
  9. Mar 13, 2022
    • 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