1. 07 7月, 2009 2 次提交
    • O
      cred_guard_mutex: do not return -EINTR to user-space · 793285fc
      Oleg Nesterov 提交于
      do_execve() and ptrace_attach() return -EINTR if
      mutex_lock_interruptible(->cred_guard_mutex) fails.
      
      This is not right, change the code to return ERESTARTNOINTR.
      
      Perhaps we should also change proc_pid_attr_write().
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Cc: David Howells <dhowells@redhat.com>
      Acked-by: NRoland McGrath <roland@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      793285fc
    • Z
      sys_sync(): fix 16% performance regression in ffsb create_4k test · 3beab0b4
      Zhang, Yanmin 提交于
      I run many ffsb test cases on JBODs (typically 13/12 disks).  Comparing
      with kernel 2.6.30, 2.6.31-rc1 has about 16% regression with
      ffsb_create_4k.  The sub test case creates files continuously for 10
      minitues and every file is 1MB.
      
      Bisect located below patch.
      
      5cee5815 is first bad commit
      commit 5cee5815
      Author: Jan Kara <jack@suse.cz>
      Date:   Mon Apr 27 16:43:51 2009 +0200
      
          vfs: Make sys_sync() use fsync_super() (version 4)
      
          It is unnecessarily fragile to have two places (fsync_super() and do_sync())
          doing data integrity sync of the filesystem. Alter __fsync_super() to
          accommodate needs of both callers and use it. So after this patch
          __fsync_super() is the only place where we gather all the calls needed to
          properly send all data on a filesystem to disk.
      
      As a matter of fact, ffsb calls sys_sync in the end to make sure all data
      is flushed to disks and the flushing is counted into the result.  vmstat
      shows ffsb is blocked when syncing for a long time.  With 2.6.30, ffsb is
      blocked for a short time.
      
      I checked the patch and did experiments to recover the original methods.
      Eventually, the root cause is the patch deletes the calling to
      wakeup_pdflush when syncing, so only ffsb is blocked on disk I/O.
      wakeup_pdflush could ask pdflush to write back pages with ffsb at the
      same time.
      
      [akpm@linux-foundation.org: restore comment too]
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Acked-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3beab0b4
  2. 03 7月, 2009 8 次提交
  3. 02 7月, 2009 2 次提交
  4. 01 7月, 2009 10 次提交
  5. 29 6月, 2009 1 次提交
  6. 28 6月, 2009 1 次提交
  7. 26 6月, 2009 3 次提交
    • S
      [CIFS] remove unknown mount option warning message · 71a394fa
      Steve French 提交于
      Jeff's previous patch which removed the unneeded rw/ro
      parsing can cause a minor warning in dmesg (about the
      unknown rw or ro mount option) at mount time. This
      patch makes cifs ignore them in kernel to remove the warning
      (they are already handled in the mount helper and VFS).
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      71a394fa
    • S
      [CIFS] remove bkl usage from umount begin · ad8034f1
      Steve French 提交于
      The lock_kernel call moved into the fs for umount_begin
      is not needed.  This adds a check to make sure we don't
      call umount_begin twice on the same fs.
      
      umount_begin for cifs is probably not needed and
      may eventually be able to be removed, but in
      the meantime this smaller patch is safe and
      gets rid of the bkl from this path which provides
      some benefit.
      
      Acked-by: Jeff Layton <redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ad8034f1
    • S
      cifs: Fix incorrect return code being printed in cFYI messages · 0f3bc09e
      Suresh Jayaraman 提交于
      FreeXid() along with freeing Xid does add a cifsFYI debug message that
      prints rc (return code) as well. In some code paths where we set/return
      error code after calling FreeXid(), incorrect error code is being
      printed when cifsFYI is enabled.
      
      This could be misleading in few cases. For eg.
      In cifs_open() if cifs_fill_filedata() returns a valid pointer to
      cifsFileInfo, FreeXid() prints rc=-13 whereas 0 is actually being
      returned. Fix this by setting rc before calling FreeXid().
      
      Basically convert
      
      FreeXid(xid);			rc = -ERR;
      return -ERR;		=>	FreeXid(xid);
      				return rc;
      
      [Note that Christoph would like to replace the GetXid/FreeXid
      calls, which are primarily used for debugging.  This seems
      like a good longer term goal, but although there is an
      alternative tracing facility, there are no examples yet
      available that I know of that we can use (yet) to
      convert this cifs function entry/exit logging, and for
      creating an identifier that we can use to correlate
      all dmesg log entries for a particular vfs operation
      (ie identify all log entries for a particular vfs
      request to cifs: e.g. a particular close or read or write
      or byte range lock call ... and just using the thread id
      is harder).  Eventually when a replacement
      for this is available (e.g. when NFS switches over and various
      samples to look at in other file systems) we can remove the
      GetXid/FreeXid macro but in the meantime multiple people
      use this run time configurable logging all the time
      for debugging, and Suresh's patch fixes a problem
      which made it harder to notice some low
      memory problems in the log so it is worthwhile
      to fix this problem until a better logging
      approach is able to be used]
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSuresh Jayaraman <sjayaraman@suse.de>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      0f3bc09e
  8. 25 6月, 2009 8 次提交
  9. 24 6月, 2009 5 次提交