1. 12 8月, 2008 1 次提交
  2. 09 8月, 2008 1 次提交
  3. 27 7月, 2008 2 次提交
  4. 03 7月, 2008 1 次提交
    • A
      Remove BKL from remote_llseek v2 · 9465efc9
      Andi Kleen 提交于
      - Replace remote_llseek with generic_file_llseek_unlocked (to force compilation
      failures in all users)
      - Change all users to either use generic_file_llseek_unlocked directly or
      take the BKL around. I changed the file systems who don't use the BKL
      for anything (CIFS, GFS) to call it directly. NCPFS and SMBFS and NFS
      take the BKL, but explicitely in their own source now.
      
      I moved them all over in a single patch to avoid unbisectable sections.
      
      Open problem: 32bit kernels can corrupt fpos because its modification
      is not atomic, but they can do that anyways because there's other paths who
      modify it without BKL.
      
      Do we need a special lock for the pos/f_version = 0 checks?
      
      Trond says the NFS BKL is likely not needed, but keep it for now
      until his full audit.
      
      v2: Use generic_file_llseek_unlocked instead of remote_llseek_unlocked
          and factor duplicated code (suggested by hch)
      
      Cc: Trond.Myklebust@netapp.com
      Cc: swhiteho@redhat.com
      Cc: sfrench@samba.org
      Cc: vandrove@vc.cvut.cz
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      9465efc9
  5. 11 6月, 2008 1 次提交
  6. 20 5月, 2008 1 次提交
  7. 17 5月, 2008 1 次提交
    • S
      [CIFS] add more complete mount options to cifs_show_options · 2b280fab
      Steve French 提交于
      adds various options to cifs_show_options
      (displayed when you cat /proc/mounts with a cifs mount).  I limited
      the new ones to values that are associated with the mount with the
      exception of "seal" (which is a per tree connection property, but I
      thought was important enough to show through).
      
      Eventually cifs's parse_mount_options also needs to
      be rewritten to use the match_token API but that would be a big enough
      change that I would prefer that changing parse_mount_options wait
      until next release.
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      2b280fab
  8. 15 5月, 2008 1 次提交
  9. 29 4月, 2008 1 次提交
  10. 28 4月, 2008 1 次提交
  11. 25 4月, 2008 2 次提交
  12. 13 2月, 2008 2 次提交
  13. 08 2月, 2008 2 次提交
  14. 25 1月, 2008 1 次提交
  15. 11 1月, 2008 1 次提交
  16. 10 1月, 2008 1 次提交
  17. 21 11月, 2007 1 次提交
    • J
      [CIFS] Fix potential data corruption when writing out cached dirty pages · cea21805
      Jeff Layton 提交于
      Fix RedHat bug 329431
      
      The idea here is separate "conscious" from "unconscious" flushes.
      Conscious flushes are those due to a fsync() or close(). Unconscious
      ones are flushes that occur as a side effect of some other operation or
      due to memory pressure.
      
      Currently, when an error occurs during an unconscious flush (ENOSPC or
      EIO), we toss out the page and don't preserve that error to report to
      the user when a conscious flush occurs. If after the unconscious flush,
      there are no more dirty pages for the inode, the conscious flush will
      simply return success even though there were previous errors when writing
      out pages. This can lead to data corruption.
      
      The easiest way to reproduce this is to mount up a CIFS share that's
      very close to being full or where the user is very close to quota. mv
      a file to the share that's slightly larger than the quota allows. The
      writes will all succeed (since they go to pagecache). The mv will do a
      setattr to set the new file's attributes. This calls
      filemap_write_and_wait,
      which will return an error since all of the pages can't be written out.
      Then later, when the flush and release ops occur, there are no more
      dirty pages in pagecache for the file and those operations return 0. mv
      then assumes that the file was written out correctly and deletes the
      original.
      
      CIFS already has a write_behind_rc variable where it stores the results
      from earlier flushes, but that value is only reported in cifs_close.
      Since the VFS ignores the return value from the release operation, this
      isn't helpful. We should be reporting this error during the flush
      operation.
      
      This patch does the following:
      
      1) changes cifs_fsync to use filemap_write_and_wait and cifs_flush and also
      sync to check its return code. If it returns successful, they then check
      the value of write_behind_rc to see if an earlier flush had reported any
      errors. If so, they return that error and clear write_behind_rc.
      
      2) sets write_behind_rc in a few other places where pages are written
      out as a side effect of other operations and the code waits on them.
      
      3) changes cifs_setattr to only call filemap_write_and_wait for
      ATTR_SIZE changes.
      
      4) makes cifs_writepages accurately distinguish between EIO and ENOSPC
      errors when writing out pages.
      
      Some simple testing indicates that the patch works as expected and that
      it fixes the reproduceable known problem.
      Acked-by: NDave Kleikamp <shaggy@austin.rr.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      cea21805
  18. 03 11月, 2007 2 次提交
  19. 18 10月, 2007 1 次提交
  20. 17 10月, 2007 1 次提交
  21. 12 10月, 2007 1 次提交
  22. 31 8月, 2007 1 次提交
  23. 24 8月, 2007 1 次提交
  24. 20 7月, 2007 1 次提交
    • P
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt 提交于
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      20c2df83
  25. 19 7月, 2007 1 次提交
  26. 18 7月, 2007 2 次提交
    • S
      63135e08
    • R
      Freezer: make kernel threads nonfreezable by default · 83144186
      Rafael J. Wysocki 提交于
      Currently, the freezer treats all tasks as freezable, except for the kernel
      threads that explicitly set the PF_NOFREEZE flag for themselves.  This
      approach is problematic, since it requires every kernel thread to either
      set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
      care for the freezing of tasks at all.
      
      It seems better to only require the kernel threads that want to or need to
      be frozen to use some freezer-related code and to remove any
      freezer-related code from the other (nonfreezable) kernel threads, which is
      done in this patch.
      
      The patch causes all kernel threads to be nonfreezable by default (ie.  to
      have PF_NOFREEZE set by default) and introduces the set_freezable()
      function that should be called by the freezable kernel threads in order to
      unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
      threads call set_freezable(), so it shouldn't cause any (intentional)
      change of behaviour to appear.  Additionally, it updates documentation to
      describe the freezing of tasks more accurately.
      
      [akpm@linux-foundation.org: build fixes]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@nigel.suspend2.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83144186
  27. 13 7月, 2007 1 次提交
  28. 12 7月, 2007 1 次提交
  29. 10 7月, 2007 1 次提交
  30. 08 7月, 2007 1 次提交
  31. 07 7月, 2007 1 次提交
  32. 05 6月, 2007 1 次提交
  33. 17 5月, 2007 1 次提交
    • C
      Remove SLAB_CTOR_CONSTRUCTOR · a35afb83
      Christoph Lameter 提交于
      SLAB_CTOR_CONSTRUCTOR is always specified. No point in checking it.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Dave Kleikamp <shaggy@austin.ibm.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Jan Kara <jack@ucw.cz>
      Cc: David Chinner <dgc@sgi.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a35afb83
  34. 08 5月, 2007 1 次提交
    • C
      slab allocators: Remove SLAB_DEBUG_INITIAL flag · 50953fe9
      Christoph Lameter 提交于
      I have never seen a use of SLAB_DEBUG_INITIAL.  It is only supported by
      SLAB.
      
      I think its purpose was to have a callback after an object has been freed
      to verify that the state is the constructor state again?  The callback is
      performed before each freeing of an object.
      
      I would think that it is much easier to check the object state manually
      before the free.  That also places the check near the code object
      manipulation of the object.
      
      Also the SLAB_DEBUG_INITIAL callback is only performed if the kernel was
      compiled with SLAB debugging on.  If there would be code in a constructor
      handling SLAB_DEBUG_INITIAL then it would have to be conditional on
      SLAB_DEBUG otherwise it would just be dead code.  But there is no such code
      in the kernel.  I think SLUB_DEBUG_INITIAL is too problematic to make real
      use of, difficult to understand and there are easier ways to accomplish the
      same effect (i.e.  add debug code before kfree).
      
      There is a related flag SLAB_CTOR_VERIFY that is frequently checked to be
      clear in fs inode caches.  Remove the pointless checks (they would even be
      pointless without removeal of SLAB_DEBUG_INITIAL) from the fs constructors.
      
      This is the last slab flag that SLUB did not support.  Remove the check for
      unimplemented flags from SLUB.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      50953fe9