1. 20 8月, 2005 4 次提交
    • S
      [PATCH] NFSv4: unbalanced BKL in nfs_atomic_lookup() · 01c314a0
      Steve Dickson 提交于
      Added missing unlock_kernel() to NFSv4 atomic lookup.
      Signed-off-by: NSteve Dickson <steved@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      01c314a0
    • A
      [PATCH] Fix up symlink function pointers · 008b150a
      Al Viro 提交于
      This fixes up the symlink functions for the calling convention change:
      
       * afs, autofs4, befs, devfs, freevxfs, jffs2, jfs, ncpfs, procfs,
         smbfs, sysvfs, ufs, xfs - prototype change for ->follow_link()
       * befs, smbfs, xfs - same for ->put_link()
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      008b150a
    • L
      Fix nasty ncpfs symlink handling bug. · cc314eef
      Linus Torvalds 提交于
      This bug could cause oopses and page state corruption, because ncpfs
      used the generic page-cache symlink handlign functions.  But those
      functions only work if the page cache is guaranteed to be "stable", ie a
      page that was installed when the symlink walk was started has to still
      be installed in the page cache at the end of the walk.
      
      We could have fixed ncpfs to not use the generic helper routines, but it
      is in many ways much cleaner to instead improve on the symlink walking
      helper routines so that they don't require that absolute stability.
      
      We do this by allowing "follow_link()" to return a error-pointer as a
      cookie, which is fed back to the cleanup "put_link()" routine.  This
      also simplifies NFS symlink handling.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cc314eef
    • A
      [PATCH] jffs2: fix symlink error handling · 2fb1e308
      Al Viro 提交于
      The current calling conventions for ->follow_link() are already fairly
      complex.
      
      What we have is
      	1) you can return -error; then you must release nameidata yourself
      	   and ->put_link() will _not_ be called.
      	2) you can do nd_set_link(nd, ERR_PTR(-error)) and return 0
      	3) you can do nd_set_link(nd, path) and return 0
      	4) you can return 0 (after having moved nameidata yourself)
      
      jffs2 follow_link() is broken - it has an exit where it returns
      -EIO and leaks nameidata.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2fb1e308
  2. 19 8月, 2005 4 次提交
  3. 18 8月, 2005 1 次提交
    • S
      [PATCH] nfsd to unlock kernel before exiting · c4f92dba
      Steven Rostedt 提交于
      The nfsd holds the big kernel lock upon exit, when it really shouldn't.
      Not to mention that this breaks Ingo's RT patch. This is a trivial fix
      to release the lock.
      
      Ingo, this patch also works with your kernel, and stops the problem with
      nfsd.
      
      Note, there's a "goto out;" where "out:" is right above svc_exit_thread.
      The point of the goto also holds the kernel_lock, so I don't see any
      problem here in releasing it.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c4f92dba
  4. 17 8月, 2005 2 次提交
  5. 16 8月, 2005 4 次提交
  6. 15 8月, 2005 2 次提交
  7. 14 8月, 2005 1 次提交
  8. 11 8月, 2005 1 次提交
  9. 09 8月, 2005 1 次提交
    • J
      [PATCH] fsnotify_name/inoderemove · 7a91bf7f
      John McCutchan 提交于
      The patch below unhooks fsnotify from vfs_unlink & vfs_rmdir.  It
      introduces two new fsnotify calls, that are hooked in at the dcache
      level.  This not only more closely matches how the VFS layer works, it
      also avoids the problem with locking and inode lifetimes.
      
      The two functions are
      
       - fsnotify_nameremove -- called when a directory entry is going away.
         It notifies the PARENT of the deletion.  This is called from
         d_delete().
      
       - inoderemove -- called when the files inode itself is going away.  It
         notifies the inode that is being deleted.  This is called from
         dentry_iput().
      Signed-off-by: NJohn McCutchan <ttb@tentacle.dhs.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7a91bf7f
  10. 08 8月, 2005 2 次提交
    • M
      [PATCH] namespace.c: fix bind mount from foreign namespace · 68b47139
      Miklos Szeredi 提交于
      I'm resending this patch, because I still believe it's the correct fix.
      
      Tested before/after applying the patch with a test application
      available from:
      
        http://www.inf.bme.hu/~mszeredi/nstest.c
      
      Bind mount from a foreign namespace results in an un-removable mount.
      The reason is that mnt->mnt_namespace is copied from the old mount in
      clone_mnt().  Because of this check_mnt() in sys_umount() will fail.
      
      The solution is to set mnt->mnt_namespace to current->namespace in
      clone_mnt().  clone_mnt() is either called from do_loopback() or
      copy_tree().  copy_tree() is called from do_loopback() or
      copy_namespace().
      
      When called (directly or indirectly) from do_loopback(), always
      current->namspace is being modified: check_mnt(nd->mnt).  So setting
      mnt->mnt_namespace to current->namspace is the right thing to do.
      
      When called from copy_namespace(), the setting of mnt_namespace is
      irrelevant, since mnt_namespace is reset later in that function for
      all copied mounts.
      
      Jamie said:
      
        This patch is correct.  The old code was buggy for more fundamental and
        serious reason: it broke the invariant that a tree of vfsmnts all have the
        same value of mnt_namespace (and the same for the mnt_list list).
      Signed-off-by: NMiklos Szeredi <miklos@szeredi.hu>
      Acked-by: NJamie Lokier <jamie@shareable.org>
      Cc: <viro@parcelfarce.linux.theplanet.co.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      68b47139
    • A
      [PATCH] __bio_clone() dead comment · e525e153
      Andrew Morton 提交于
      Remove a very wrong comment.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e525e153
  11. 07 8月, 2005 1 次提交
    • L
      Check input buffer size in zisofs · fab5a60a
      Linus Torvalds 提交于
      This uses the new deflateBound() thing to sanity-check the input to the
      zlib decompressor before we even bother to start reading in the blocks.
      
      Problem noted by Tim Yamin <plasmaroo@gentoo.org>
      fab5a60a
  12. 05 8月, 2005 3 次提交
  13. 02 8月, 2005 5 次提交
  14. 30 7月, 2005 2 次提交
  15. 29 7月, 2005 1 次提交
  16. 28 7月, 2005 6 次提交
    • A
      [PATCH] bio_clone fix · a5453be4
      Andrew Morton 提交于
      Fix bug introduced in 2.6.11-rc2: when we clone a BIO we need to copy over the
      current index into it as well.
      
      It corrupts data with some MD setups.
      
      See http://bugzilla.kernel.org/show_bug.cgi?id=4946
      
      Huuuuuuuuge thanks to Matthew Stapleton <matthew4196@gmail.com> for doggedly
      chasing this one down.
      Acked-by: NJens Axboe <axboe@suse.de>
      Cc: <linux-raid@vger.kernel.org>
      Cc: <dm-devel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a5453be4
    • J
      [PATCH] clean up inline static vs static inline · 77933d72
      Jesper Juhl 提交于
      `gcc -W' likes to complain if the static keyword is not at the beginning of
      the declaration.  This patch fixes all remaining occurrences of "inline
      static" up with "static inline" in the entire kernel tree (140 occurrences in
      47 files).
      
      While making this change I came across a few lines with trailing whitespace
      that I also fixed up, I have also added or removed a blank line or two here
      and there, but there are no functional changes in the patch.
      Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      77933d72
    • O
      [PATCH] turn many #if $undefined_string into #ifdef $undefined_string · 44456d37
      Olaf Hering 提交于
      turn many #if $undefined_string into #ifdef $undefined_string to fix some
      warnings after -Wno-def was added to global CFLAGS
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      44456d37
    • A
      [PATCH] reiserfs doesn't use mbcache · 02b77569
      Andreas Gruenbacher 提交于
      reiserfs doesn't use the mbcache, so this can go.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      02b77569
    • A
      [PATCH] mbcache: Remove unused mb_cache_shrink parameter · 8c52ab42
      Andreas Gruenbacher 提交于
      The cache parameter to mb_cache_shrink isn't used.  We may as well remove
      it.
      Signed-off-by: NAndreas Gruenbacher <agruen@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8c52ab42
    • P
      [PATCH] stale POSIX lock handling · c293621b
      Peter Staubach 提交于
      I believe that there is a problem with the handling of POSIX locks, which
      the attached patch should address.
      
      The problem appears to be a race between fcntl(2) and close(2).  A
      multithreaded application could close a file descriptor at the same time as
      it is trying to acquire a lock using the same file descriptor.  I would
      suggest that that multithreaded application is not providing the proper
      synchronization for itself, but the OS should still behave correctly.
      
      SUS3 (Single UNIX Specification Version 3, read: POSIX) indicates that when
      a file descriptor is closed, that all POSIX locks on the file, owned by the
      process which closed the file descriptor, should be released.
      
      The trick here is when those locks are released.  The current code releases
      all locks which exist when close is processing, but any locks in progress
      are handled when the last reference to the open file is released.
      
      There are three cases to consider.
      
      One is the simple case, a multithreaded (mt) process has a file open and
      races to close it and acquire a lock on it.  In this case, the close will
      release one reference to the open file and when the fcntl is done, it will
      release the other reference.  For this situation, no locks should exist on
      the file when both the close and fcntl operations are done.  The current
      system will handle this case because the last reference to the open file is
      being released.
      
      The second case is when the mt process has dup(2)'d the file descriptor.
      The close will release one reference to the file and the fcntl, when done,
      will release another, but there will still be at least one more reference
      to the open file.  One could argue that the existence of a lock on the file
      after the close has completed is okay, because it was acquired after the
      close operation and there is still a way for the application to release the
      lock on the file, using an existing file descriptor.
      
      The third case is when the mt process has forked, after opening the file
      and either before or after becoming an mt process.  In this case, each
      process would hold a reference to the open file.  For each process, this
      degenerates to first case above.  However, the lock continues to exist
      until both processes have released their references to the open file.  This
      lock could block other lock requests.
      
      The changes to release the lock when the last reference to the open file
      aren't quite right because they would allow the lock to exist as long as
      there was a reference to the open file.  This is too long.
      
      The new proposed solution is to add support in the fcntl code path to
      detect a race with close and then to release the lock which was just
      acquired when such as race is detected.  This causes locks to be released
      in a timely fashion and for the system to conform to the POSIX semantic
      specification.
      
      This was tested by instrumenting a kernel to detect the handling locks and
      then running a program which generates case #3 above.  A dangling lock
      could be reliably generated.  When the changes to detect the close/fcntl
      race were added, a dangling lock could no longer be generated.
      
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c293621b