Eric Lee / smarc-fsl-linux-kernel

07 May, 2007

1 commit

  • 9b9d2ab41   locks: add lock cancel command ... Browse Code »

    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: Marc Eshel
    Signed-off-by: "J. Bruce Fields"

    Marc Eshel
     

26 Jun, 2006

1 commit

  • 45c9b11a1   [PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat ... Browse Code »

    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: Ulrich Drepper
    Acked-by: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ulrich Drepper
     

19 Jan, 2006

1 commit

  • 5590ff0d5   [PATCH] vfs: *at functions: core ... Browse Code »

    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: Ulrich Drepper
    Signed-off-by: Alexey Dobriyan
    Cc: Christoph Hellwig
    Cc: Al Viro
    Acked-by: Ingo Molnar
    Cc: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ulrich Drepper
     

24 Jun, 2005

1 commit

  • ef3daeda7   [PATCH] Don't force O_LARGEFILE for 32 bit processes on ia64 ... Browse Code »

    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: Yoav Zach
    Acked-by: Tony Luck
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yoav Zach
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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!

    Linus Torvalds