1. 28 8月, 2009 1 次提交
  2. 26 8月, 2009 1 次提交
  3. 13 7月, 2009 1 次提交
  4. 29 4月, 2009 2 次提交
    • C
      NFSD: Prevent a buffer overflow in svc_xprt_names() · 335c54bd
      Chuck Lever 提交于
      The svc_xprt_names() function can overflow its buffer if it's so near
      the end of the passed in buffer that the "name too long" string still
      doesn't fit.  Of course, it could never tell if it was near the end
      of the passed in buffer, since its only caller passes in zero as the
      buffer length.
      
      Let's make this API a little safer.
      
      Change svc_xprt_names() so it *always* checks for a buffer overflow,
      and change its only caller to pass in the correct buffer length.
      
      If svc_xprt_names() does overflow its buffer, it now fails with an
      ENAMETOOLONG errno, instead of trying to write a message at the end
      of the buffer.  I don't like this much, but I can't figure out a clean
      way that's always safe to return some of the names, *and* an
      indication that the buffer was not long enough.
      
      The displayed error when doing a 'cat /proc/fs/nfsd/portlist' is
      "File name too long".
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      335c54bd
    • H
      net/sunrpc/svc_xprt.c: fix sparse warnings · dcf1a357
      H Hartley Sweeten 提交于
      Fix the following sparse warnings in net/sunrpc/svc_xprt.c.
      
        warning: symbol 'svc_recv' was not declared. Should it be static?
        warning: symbol 'svc_drop' was not declared. Should it be static?
        warning: symbol 'svc_send' was not declared. Should it be static?
        warning: symbol 'svc_close_all' was not declared. Should it be static?
      Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      dcf1a357
  5. 04 4月, 2009 1 次提交
  6. 29 3月, 2009 2 次提交
  7. 19 3月, 2009 2 次提交
    • G
      knfsd: add file to export stats about nfsd pools · 03cf6c9f
      Greg Banks 提交于
      Add /proc/fs/nfsd/pool_stats to export to userspace various
      statistics about the operation of rpc server thread pools.
      
      This patch is based on a forward-ported version of
      knfsd-add-pool-thread-stats which has been shipping in the SGI
      "Enhanced NFS" product since 2006 and which was previously
      posted:
      
      http://article.gmane.org/gmane.linux.nfs/10375
      
      It has also been updated thus:
      
       * moved EXPORT_SYMBOL() to near the function it exports
       * made the new struct struct seq_operations const
       * used SEQ_START_TOKEN instead of ((void *)1)
       * merged fix from SGI PV 990526 "sunrpc: use dprintk instead of
         printk in svc_pool_stats_*()" by Harshula Jayasuriya.
       * merged fix from SGI PV 964001 "Crash reading pool_stats before
         nfsds are started".
      Signed-off-by: NGreg Banks <gnb@sgi.com>
      Signed-off-by: NHarshula Jayasuriya <harshula@sgi.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      03cf6c9f
    • G
      knfsd: avoid overloading the CPU scheduler with enormous load averages · 59a252ff
      Greg Banks 提交于
      Avoid overloading the CPU scheduler with enormous load averages
      when handling high call-rate NFS loads.  When the knfsd bottom half
      is made aware of an incoming call by the socket layer, it tries to
      choose an nfsd thread and wake it up.  As long as there are idle
      threads, one will be woken up.
      
      If there are lot of nfsd threads (a sensible configuration when
      the server is disk-bound or is running an HSM), there will be many
      more nfsd threads than CPUs to run them.  Under a high call-rate
      low service-time workload, the result is that almost every nfsd is
      runnable, but only a handful are actually able to run.  This situation
      causes two significant problems:
      
      1. The CPU scheduler takes over 10% of each CPU, which is robbing
         the nfsd threads of valuable CPU time.
      
      2. At a high enough load, the nfsd threads starve userspace threads
         of CPU time, to the point where daemons like portmap and rpc.mountd
         do not schedule for tens of seconds at a time.  Clients attempting
         to mount an NFS filesystem timeout at the very first step (opening
         a TCP connection to portmap) because portmap cannot wake up from
         select() and call accept() in time.
      
      Disclaimer: these effects were observed on a SLES9 kernel, modern
      kernels' schedulers may behave more gracefully.
      
      The solution is simple: keep in each svc_pool a counter of the number
      of threads which have been woken but have not yet run, and do not wake
      any more if that count reaches an arbitrary small threshold.
      
      Testing was on a 4 CPU 4 NIC Altix using 4 IRIX clients, each with 16
      synthetic client threads simulating an rsync (i.e. recursive directory
      listing) workload reading from an i386 RH9 install image (161480
      regular files in 10841 directories) on the server.  That tree is small
      enough to fill in the server's RAM so no disk traffic was involved.
      This setup gives a sustained call rate in excess of 60000 calls/sec
      before being CPU-bound on the server.  The server was running 128 nfsds.
      
      Profiling showed schedule() taking 6.7% of every CPU, and __wake_up()
      taking 5.2%.  This patch drops those contributions to 3.0% and 2.2%.
      Load average was over 120 before the patch, and 20.9 after.
      
      This patch is a forward-ported version of knfsd-avoid-nfsd-overload
      which has been shipping in the SGI "Enhanced NFS" product since 2006.
      It has been posted before:
      
      http://article.gmane.org/gmane.linux.nfs/10374Signed-off-by: NGreg Banks <gnb@sgi.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      59a252ff
  8. 08 1月, 2009 3 次提交
  9. 07 1月, 2009 1 次提交
    • J
      sunrpc: add sv_maxconn field to svc_serv (try #3) · c9233eb7
      Jeff Layton 提交于
      svc_check_conn_limits() attempts to prevent denial of service attacks
      by having the service close old connections once it reaches a
      threshold. This threshold is based on the number of threads in the
      service:
      
      	(serv->sv_nrthreads + 3) * 20
      
      Once we reach this, we drop the oldest connections and a printk pops
      to warn the admin that they should increase the number of threads.
      
      Increasing the number of threads isn't an option however for services
      like lockd. We don't want to eliminate this check entirely for such
      services but we need some way to increase this limit.
      
      This patch adds a sv_maxconn field to the svc_serv struct. When it's
      set to 0, we use the current method to calculate the max number of
      connections. RPC services can then set this on an as-needed basis.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Acked-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      c9233eb7
  10. 30 9月, 2008 1 次提交
  11. 19 5月, 2008 2 次提交
  12. 24 4月, 2008 2 次提交
    • J
      SUNRPC: allow svc_recv to break out of 500ms sleep when alloc_page fails · 7b54fe61
      Jeff Layton 提交于
      svc_recv() calls alloc_page(), and if it fails it does a 500ms
      uninterruptible sleep and then reattempts. There doesn't seem to be any
      real reason for this to be uninterruptible, so change it to an
      interruptible sleep. Also check for kthread_stop() and signalled() after
      setting the task state to avoid races that might lead to sleeping after
      kthread_stop() wakes up the task.
      
      I've done some very basic smoke testing with this, but obviously it's
      hard to test the actual changes since this all depends on an
      alloc_page() call failing.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      7b54fe61
    • J
      SUNRPC: have svc_recv() check kthread_should_stop() · 7086721f
      Jeff Layton 提交于
      When using kthreads that call into svc_recv, we want to make sure that
      they do not block there for a long time when we're trying to take down
      the kthread.
      
      This patch changes svc_recv() to check kthread_should_stop() at the same
      places that it checks to see if it's signalled(). Also check just before
      svc_recv() tries to schedule(). By making sure that we check it just
      after setting the task state we can avoid having to use any locking or
      signalling to ensure it doesn't block for a long time.
      
      There's still a chance of a 500ms sleep if alloc_page() fails, but
      that should be a rare occurrence and isn't a terribly long time in
      the context of a kthread being taken down.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      7086721f
  13. 18 3月, 2008 1 次提交
  14. 02 2月, 2008 17 次提交