1. 15 7月, 2006 1 次提交
    • K
      [PATCH] struct file leakage · de459215
      Kirill Korotaev 提交于
      2.6.16 leaks like hell. While testing, I found massive leakage
      (reproduced in openvz) in:
      
      *filp
      *size-4096
      
      And 1 object leaks in
      *size-32
      *size-64
      *size-128
      
      It is the fix for the first one.  filp leaks in the bowels of namei.c.
      
      Seems, size-4096 is file table leaking in expand_fdtables.
      
      I have no idea what are the rest and why they show only accompanying
      another leaks.  Some debugging structs?
      
      [akpm@osdl.org, Trond: remove the IS_ERR() check]
      Signed-off-by: NAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: <stable@kernel.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>
      de459215
  2. 04 7月, 2006 1 次提交
  3. 26 6月, 2006 1 次提交
    • U
      [PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat · 45c9b11a
      Ulrich Drepper 提交于
      When the linkat() syscall was added the flag parameter was added in the
      last minute but it wasn't used so far.  The following patch should change
      that.  My tests show that this is all that's needed.
      
      If OLDNAME is a symlink setting the flag causes linkat to follow the
      symlink and create a hardlink with the target.  This is actually the
      behavior POSIX demands for link() as well but Linux wisely does not do
      this.  With this flag (which will most likely be in the next POSIX
      revision) the programmer can choose the behavior, defaulting to the safe
      variant.  As a side effect it is now possible to implement a
      POSIX-compliant link(2) function for those who are interested.
      
        touch file
        ln -s file symlink
      
        linkat(fd, "symlink", fd, "newlink", 0)
          -> newlink is hardlink of symlink
      
        linkat(fd, "symlink", fd, "newlink", AT_SYMLINK_FOLLOW)
          -> newlink is hardlink of file
      
      The value of AT_SYMLINK_FOLLOW is determined by the definition we already
      use in glibc.
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      45c9b11a
  4. 23 6月, 2006 1 次提交
  5. 20 6月, 2006 1 次提交
    • A
      [PATCH] log more info for directory entry change events · 9c937dcc
      Amy Griffis 提交于
      When an audit event involves changes to a directory entry, include
      a PATH record for the directory itself.  A few other notable changes:
      
          - fixed audit_inode_child() hooks in fsnotify_move()
          - removed unused flags arg from audit_inode()
          - added audit log routines for logging a portion of a string
      
      Here's some sample output.
      
      before patch:
      type=SYSCALL msg=audit(1149821605.320:26): arch=40000003 syscall=39 success=yes exit=0 a0=bf8d3c7c a1=1ff a2=804e1b8 a3=bf8d3c7c items=1 ppid=739 pid=800 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 comm="mkdir" exe="/bin/mkdir" subj=root:system_r:unconfined_t:s0-s0:c0.c255
      type=CWD msg=audit(1149821605.320:26):  cwd="/root"
      type=PATH msg=audit(1149821605.320:26): item=0 name="foo" parent=164068 inode=164010 dev=03:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=root:object_r:user_home_t:s0
      
      after patch:
      type=SYSCALL msg=audit(1149822032.332:24): arch=40000003 syscall=39 success=yes exit=0 a0=bfdd9c7c a1=1ff a2=804e1b8 a3=bfdd9c7c items=2 ppid=714 pid=777 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 comm="mkdir" exe="/bin/mkdir" subj=root:system_r:unconfined_t:s0-s0:c0.c255
      type=CWD msg=audit(1149822032.332:24):  cwd="/root"
      type=PATH msg=audit(1149822032.332:24): item=0 name="/root" inode=164068 dev=03:00 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=root:object_r:user_home_dir_t:s0
      type=PATH msg=audit(1149822032.332:24): item=1 name="foo" inode=164010 dev=03:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=root:object_r:user_home_t:s0
      Signed-off-by: NAmy Griffis <amy.griffis@hp.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9c937dcc
  6. 06 6月, 2006 1 次提交
  7. 01 4月, 2006 1 次提交
  8. 28 3月, 2006 1 次提交
    • I
      [PATCH] autofs4: nameidata needs to be up to date for follow_link · 051d3812
      Ian Kent 提交于
      In order to be able to trigger a mount using the follow_link inode method the
      nameidata struct that is passed in needs to have the vfsmount of the autofs
      trigger not its parent.
      
      During a path walk if an autofs trigger is mounted on a dentry, when the
      follow_link method is called, the nameidata struct contains the vfsmount and
      mountpoint dentry of the parent mount while the dentry that is passed in is
      the root of the autofs trigger mount.  I believe it is impossible to get the
      vfsmount of the trigger mount, within the follow_link method, when only the
      parent vfsmount and the root dentry of the trigger mount are known.
      
      This patch updates the nameidata struct on entry to __do_follow_link if it
      detects that it is out of date.  It moves the path_to_nameidata to above
      __do_follow_link to facilitate calling it from there.  The dput_path is moved
      as well as that seemed sensible.  No changes are made to these two functions.
      Signed-off-by: NIan Kent <raven@themaw.net>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      051d3812
  9. 26 3月, 2006 2 次提交
    • N
      [PATCH] Honour AOP_TRUNCATE_PAGE returns in page_symlink · 7e53cac4
      NeilBrown 提交于
      As prepare_write, commit_write and readpage are allowed to return
      AOP_TRUNCATE_PAGE, page_symlink should respond to them.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7e53cac4
    • O
      [PATCH] Missed error checking for intent's filp in open_namei(). · 4af4c52f
      Oleg Drokin 提交于
      It seems there is error check missing in open_namei for errors returned
      through intent.open.file (from lookup_instantiate_filp).
      
      If there is plain open performed, then such a check done inside
      __path_lookup_intent_open called from path_lookup_open(), but when the open
      is performed with O_CREAT flag set, then __path_lookup_intent_open is only
      called with LOOKUP_PARENT set where no file opening can occur yet.
      
      Later on lookup_hash is called where exact opening might take place and
      intent.open.file may be filled.  If it is filled with error value of some
      sort, then we get kernel attempting to dereference this error value as
      address (and corresponding oops) in nameidata_to_filp() called from
      filp_open().
      
      While this is relatively simple to workaround in ->lookup() method by just
      checking lookup_instantiate_filp() return value and returning error as
      needed, this is not so easy in ->d_revalidate(), where we can only return
      "yes, dentry is valid" or "no, dentry is invalid, perform full lookup
      again", and just returning 0 on error would cause extra lookup (with
      potential extra costly RPCs).
      
      So in short, I believe that there should be no difference in error handling
      for opening a file and creating a file in open_namei() and propose this
      simple patch as a solution.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4af4c52f
  10. 23 3月, 2006 1 次提交
  11. 21 3月, 2006 2 次提交
  12. 12 3月, 2006 1 次提交
  13. 25 2月, 2006 1 次提交
    • U
      [PATCH] flags parameter for linkat · c04030e1
      Ulrich Drepper 提交于
      I'm currently at the POSIX meeting and one thing covered was the
      incompatibility of Linux's link() with the POSIX definition.  The name.
      Linux does not follow symlinks, POSIX requires it does.
      
      Even if somebody thinks this is a good default behavior we cannot change this
      because it would break the ABI.  But the fact remains that some application
      might want this behavior.
      
      We have one chance to help implementing this without breaking the behavior.
       For this we could use the new linkat interface which would need a new
      flags parameter.  If the new parameter is AT_SYMLINK_FOLLOW the new
      behavior could be invoked.
      
      I do not want to introduce such a patch now.  But we could add the
      parameter now, just don't use it.  The patch below would do this.  Can we
      get this late patch applied before the release more or less fixes the
      syscall API?
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c04030e1
  14. 08 2月, 2006 1 次提交
  15. 06 2月, 2006 2 次提交
  16. 02 2月, 2006 1 次提交
  17. 19 1月, 2006 1 次提交
    • U
      [PATCH] vfs: *at functions: core · 5590ff0d
      Ulrich Drepper 提交于
      Here is a series of patches which introduce in total 13 new system calls
      which take a file descriptor/filename pair instead of a single file
      name.  These functions, openat etc, have been discussed on numerous
      occasions.  They are needed to implement race-free filesystem traversal,
      they are necessary to implement a virtual per-thread current working
      directory (think multi-threaded backup software), etc.
      
      We have in glibc today implementations of the interfaces which use the
      /proc/self/fd magic.  But this code is rather expensive.  Here are some
      results (similar to what Jim Meyering posted before).
      
      The test creates a deep directory hierarchy on a tmpfs filesystem.  Then
      rm -fr is used to remove all directories.  Without syscall support I get
      this:
      
      real    0m31.921s
      user    0m0.688s
      sys     0m31.234s
      
      With syscall support the results are much better:
      
      real    0m20.699s
      user    0m0.536s
      sys     0m20.149s
      
      The interfaces are for obvious reasons currently not much used.  But they'll
      be used.  coreutils (and Jeff's posixutils) are already using them.
      Furthermore, code like ftw/fts in libc (maybe even glob) will also start using
      them.  I expect a patch to make follow soon.  Every program which is walking
      the filesystem tree will benefit.
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5590ff0d
  18. 15 1月, 2006 2 次提交
  19. 12 1月, 2006 1 次提交
  20. 10 1月, 2006 1 次提交
  21. 09 1月, 2006 1 次提交
    • N
      [PATCH] Fix some problems with truncate and mtime semantics. · 4a30131e
      NeilBrown 提交于
      SUS requires that when truncating a file to the size that it currently
      is:
        truncate and ftruncate should NOT modify ctime or mtime
        O_TRUNC SHOULD modify ctime and mtime.
      
      Currently mtime and ctime are always modified on most local
      filesystems (side effect of ->truncate) or never modified (on NFS).
      
      With this patch:
        ATTR_CTIME|ATTR_MTIME are sent with ATTR_SIZE precisely when
          an update of these times is required whether size changes or not
          (via a new argument to do_truncate).  This allows NFS to do
          the right thing for O_TRUNC.
        inode_setattr nolonger forces ATTR_MTIME|ATTR_CTIME when the ATTR_SIZE
          sets the size to it's current value.  This allows local filesystems
          to do the right thing for f?truncate.
      
      Also, the logic in inode_setattr is changed a bit so there are two return
      points.  One returns the error from vmtruncate if it failed, the other
      returns 0 (there can be no other failure).
      
      Finally, if vmtruncate succeeds, and ATTR_SIZE is the only change
      requested, we now fall-through and mark_inode_dirty.  If a filesystem did
      not have a ->truncate function, then vmtruncate will have changed i_size,
      without marking the inode as 'dirty', and I think this is wrong.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4a30131e
  22. 09 11月, 2005 4 次提交
  23. 07 11月, 2005 1 次提交
  24. 31 10月, 2005 1 次提交
  25. 19 10月, 2005 2 次提交
  26. 07 10月, 2005 1 次提交
  27. 10 9月, 2005 2 次提交
  28. 08 9月, 2005 1 次提交
  29. 20 8月, 2005 1 次提交
    • 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
  30. 16 8月, 2005 1 次提交
  31. 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