1. 14 Mar, 2011 1 commit
    • Al Viro's avatar
      New AT_... flag: AT_EMPTY_PATH · f52e0c11
      Al Viro authored
      For name_to_handle_at(2) we'll want both ...at()-style syscall that
      would be usable for non-directory descriptors (with empty relative
      pathname).  Introduce new flag (AT_EMPTY_PATH) to deal with that and
      corresponding LOOKUP_EMPTY; teach user_path_at() and path_init() to
      deal with the latter.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      f52e0c11
  2. 15 Jan, 2011 1 commit
  3. 21 May, 2010 1 commit
  4. 17 Oct, 2007 1 commit
    • Ulrich Drepper's avatar
      F_DUPFD_CLOEXEC implementation · 22d2b35b
      Ulrich Drepper authored
      One more small change to extend the availability of creation of file
      descriptors with FD_CLOEXEC set.  Adding a new command to fcntl() requires
      no new system call and the overall impact on code size if minimal.
      
      If this patch gets accepted we will also add this change to the next
      revision of the POSIX spec.
      
      To test the patch, use the following little program.  Adjust the value of
      F_DUPFD_CLOEXEC appropriately.
      
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      #include <errno.h>
      #include <fcntl.h>
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      
      #ifndef F_DUPFD_CLOEXEC
      # define F_DUPFD_CLOEXEC 12
      #endif
      
      int
      main (int argc, char *argv[])
      {
        if  (argc > 1)
          {
            if (fcntl (3, F_GETFD) == 0)
      	{
      	  puts ("descriptor not closed");
      	  exit (1);
      	}
            if (errno != EBADF)
      	{
      	  puts ("error not EBADF");
      	  exit (1);
      	}
      
            exit (0);
          }
        int fd = fcntl (STDOUT_FILENO, F_DUPFD_CLOEXEC, 0);
        if (fd == -1 && errno == EINVAL)
          {
            puts ("F_DUPFD_CLOEXEC not supported");
            return 0;
          }
        if (fd != 3)
          {
            puts ("program called with descriptors other than 0,1,2");
            return 1;
          }
      
        execl ("/proc/self/exe", "/proc/self/exe", "1", NULL);
        puts ("execl failed");
        return 1;
      }
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: default avatarUlrich Drepper <drepper@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: <linux-arch@vger.kernel.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      22d2b35b
  5. 06 May, 2007 1 commit
    • Marc Eshel's avatar
      locks: add lock cancel command · 9b9d2ab4
      Marc Eshel authored
      Lock managers need to be able to cancel pending lock requests.  In the case
      where the exported filesystem manages its own locks, it's not sufficient just
      to call posix_unblock_lock(); we need to let the filesystem know what's
      happening too.
      
      We do this by adding a new fcntl lock command: FL_CANCELLK.  Some day this
      might also be made available to userspace applications that could benefit from
      an asynchronous locking api.
      Signed-off-by: default avatarMarc Eshel <eshel@almaden.ibm.com>
      Signed-off-by: default avatar"J. Bruce Fields" <bfields@citi.umich.edu>
      9b9d2ab4
  6. 25 Jun, 2006 1 commit
    • Ulrich Drepper's avatar
      [PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat · 45c9b11a
      Ulrich Drepper authored
      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: default avatarUlrich Drepper <drepper@redhat.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      45c9b11a
  7. 18 Jan, 2006 1 commit
    • Ulrich Drepper's avatar
      [PATCH] vfs: *at functions: core · 5590ff0d
      Ulrich Drepper authored
      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: default avatarUlrich Drepper <drepper@redhat.com>
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5590ff0d
  8. 23 Jun, 2005 1 commit
    • Yoav Zach's avatar
      [PATCH] Don't force O_LARGEFILE for 32 bit processes on ia64 · ef3daeda
      Yoav Zach authored
      In ia64 kernel, the O_LARGEFILE flag is forced when opening a file.  This
      is problematic for execution of 32 bit processes, which are not largefile
      aware, either by SW emulation or by HW execution.
      
      For such processes, the problem is two-fold:
      
      1) When trying to open a file that is larger than 4G
         the operation should fail, but it's not
      2) Writing to offset larger than 4G should fail, but
         it's not
      
      The proposed patch takes advantage of the way 32 bit processes are
      identified in ia64 systems.  Such processes have PER_LINUX32 for their
      personality.  With the patch, the ia64 kernel will not enforce the
      O_LARGEFILE flag if the current process has PER_LINUX32 set.  The behavior
      for all other architectures remains unchanged.
      Signed-off-by: default avatarYoav Zach <yoav.zach@intel.com>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ef3daeda
  9. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4