1. 22 Sep, 2010 4 commits
  2. 21 Sep, 2010 4 commits
  3. 20 Sep, 2010 2 commits
    • J. Bruce Fields's avatar
      nfsd4: fix hang on fast-booting nfs servers · 06497524
      J. Bruce Fields authored
      The last_close field of a cache_detail is initialized to zero, so the
      condition
      
      	detail->last_close < seconds_since_boot() - 30
      
      may be false even for a cache that was never opened.
      
      However, we want to immediately fail upcalls to caches that were never
      opened: in the case of the auth_unix_gid cache, especially, which may
      never be opened by mountd (if the --manage-gids option is not set), we
      want to fail the upcall immediately.  Otherwise client requests will be
      dropped unnecessarily on reboot.
      
      Also document these conditions.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      06497524
    • J. Bruce Fields's avatar
      Merge remote branch 'trond/bugfixes' into for-2.6.37 · c88739b3
      J. Bruce Fields authored
      Without some client-side fixes, server testing is currently difficult.
      c88739b3
  4. 12 Sep, 2010 12 commits
  5. 11 Sep, 2010 13 commits
  6. 10 Sep, 2010 5 commits
    • mark gross's avatar
      PM QoS: Correct pr_debug() misuse and improve parameter checks · 0109c2c4
      mark gross authored
      Correct some pr_debug() misuse and add a stronger parameter check to
      pm_qos_write() for the ASCII hex value case.  Thanks to Dan Carpenter
      for pointing out the problem!
      Signed-off-by: default avatarmark gross <markgross@thegnar.org>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      0109c2c4
    • Dave Chinner's avatar
      xfs: log IO completion workqueue is a high priority queue · 51749e47
      Dave Chinner authored
      The workqueue implementation in 2.6.36-rcX has changed, resulting
      in the workqueues no longer having dedicated threads for work
      processing. This has caused severe livelocks under heavy parallel
      create workloads because the log IO completions have been getting
      held up behind metadata IO completions.  Hence log commits would
      stall, memory allocation would stall because pages could not be
      cleaned, and lock contention on the AIL during inode IO completion
      processing was being seen to slow everything down even further.
      
      By making the log Io completion workqueue a high priority workqueue,
      they are queued ahead of all data/metadata IO completions and
      processed before the data/metadata completions. Hence the log never
      gets stalled, and operations needed to clean memory can continue as
      quickly as possible. This avoids the livelock conditions and allos
      the system to keep running under heavy load as per normal.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAlex Elder <aelder@sgi.com>
      51749e47
    • Roland McGrath's avatar
      execve: make responsive to SIGKILL with large arguments · 9aea5a65
      Roland McGrath authored
      An execve with a very large total of argument/environment strings
      can take a really long time in the execve system call.  It runs
      uninterruptibly to count and copy all the strings.  This change
      makes it abort the exec quickly if sent a SIGKILL.
      
      Note that this is the conservative change, to interrupt only for
      SIGKILL, by using fatal_signal_pending().  It would be perfectly
      correct semantics to let any signal interrupt the string-copying in
      execve, i.e. use signal_pending() instead of fatal_signal_pending().
      We'll save that change for later, since it could have user-visible
      consequences, such as having a timer set too quickly make it so that
      an execve can never complete, though it always happened to work before.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Reviewed-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9aea5a65
    • Roland McGrath's avatar
      execve: improve interactivity with large arguments · 7993bc1f
      Roland McGrath authored
      This adds a preemption point during the copying of the argument and
      environment strings for execve, in copy_strings().  There is already
      a preemption point in the count() loop, so this doesn't add any new
      points in the abstract sense.
      
      When the total argument+environment strings are very large, the time
      spent copying them can be much more than a normal user time slice.
      So this change improves the interactivity of the rest of the system
      when one process is doing an execve with very large arguments.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Reviewed-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7993bc1f
    • Roland McGrath's avatar
      setup_arg_pages: diagnose excessive argument size · 1b528181
      Roland McGrath authored
      The CONFIG_STACK_GROWSDOWN variant of setup_arg_pages() does not
      check the size of the argument/environment area on the stack.
      When it is unworkably large, shift_arg_pages() hits its BUG_ON.
      This is exploitable with a very large RLIMIT_STACK limit, to
      create a crash pretty easily.
      
      Check that the initial stack is not too large to make it possible
      to map in any executable.  We're not checking that the actual
      executable (or intepreter, for binfmt_elf) will fit.  So those
      mappings might clobber part of the initial stack mapping.  But
      that is just userland lossage that userland made happen, not a
      kernel problem.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Reviewed-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1b528181