Eric Lee / smarc-ti-linux-kernel

16 May, 2012

1 commit

  • d7dab39b6   ext3: return 32/64-bit dir name hash according to usage type ... Browse Code »

    This is based on commit d1f5273e9adb40724a85272f248f210dc4ce919a
    ext4: return 32/64-bit dir name hash according to usage type
    by Fan Yong

    Traditionally ext2/3/4 has returned a 32-bit hash value from llseek()
    to appease NFSv2, which can only handle a 32-bit cookie for seekdir()
    and telldir(). However, this causes problems if there are 32-bit hash
    collisions, since the NFSv2 server can get stuck resending the same
    entries from the directory repeatedly.

    Allow ext3 to return a full 64-bit hash (both major and minor) for
    telldir to decrease the chance of hash collisions.

    This patch does implement a new ext3_dir_llseek op, because with 64-bit
    hashes, nfs will attempt to seek to a hash "offset" which is much
    larger than ext3's s_maxbytes. So for dx dirs, we call
    generic_file_llseek_size() with the appropriate max hash value as the
    maximum seekable size. Otherwise we just pass through to
    generic_file_llseek().

    Patch-updated-by: Bernd Schubert
    Patch-updated-by: Eric Sandeen
    (blame us if something is not correct)

    Signed-off-by: Eric Sandeen
    Signed-off-by: Jan Kara

    Eric Sandeen
     

01 Apr, 2012

1 commit

29 Oct, 2008

1 commit

  • 5e1f8c9e2   ext3: Add support for non-native signed/unsigned htree hash algorithms ... Browse Code »

    The original ext3 hash algorithms assumed that variables of type char
    were signed, as God and K&R intended. Unfortunately, this assumption
    is not true on some architectures. Userspace support for marking
    filesystems with non-native signed/unsigned chars was added two years
    ago, but the kernel-side support was never added (until now).

    Signed-off-by: "Theodore Ts'o"
    Cc: akpm@linux-foundation.org
    Cc: linux-kernel@vger.kernel.org

    Theodore Ts'o
     

15 Feb, 2007

1 commit

  • cd354f1ae   [PATCH] remove many unneeded #includes of sched.h ... Browse Code »

    After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

27 Sep, 2006

2 commits

17 Apr, 2005

1 commit

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

    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