23 Aug, 2007

1 commit

  • When ecryptfs_lookup() is called against special files, eCryptfs generates
    the following errors because it tries to treat them like regular eCryptfs
    files.

    Error opening lower file for lower_dentry [0xffff810233a6f150], lower_mnt [0xffff810235bb4c80], and flags [0x8000]
    Error opening lower_file to read header region
    Error attempting to read the [user.ecryptfs] xattr from the lower file; return value = [-95]
    Valid metadata not found in header region or xattr region; treating file as unencrypted

    For instance, the problem can be reproduced by the steps below.

    # mkdir /root/crypt /mnt/crypt
    # mount -t ecryptfs /root/crypt /mnt/crypt
    # mknod /mnt/crypt/c0 c 0 0
    # umount /mnt/crypt
    # mount -t ecryptfs /root/crypt /mnt/crypt
    # ls -l /mnt/crypt

    This patch fixes it by adding a check similar to directories and
    symlinks.

    Signed-off-by: Ryusuke Konishi
    Acked-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ryusuke Konishi
     

12 Aug, 2007

2 commits

  • ecryptfs_init() exits without doing any cleanup jobs if
    ecryptfs_init_messaging() fails. In that case, eCryptfs leaves
    sysfs entries, leaks memory, and causes an invalid page fault.
    This patch fixes the problem.

    Signed-off-by: Ryusuke Konishi
    Acked-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ryusuke Konishi
     
  • When ecryptfs_lookup() is called against special files, eCryptfs generates
    the following errors because it tries to treat them like regular eCryptfs
    files.

    Error opening lower file for lower_dentry [0xffff810233a6f150], lower_mnt [0xffff810235bb4c80], and flags
    [0x8000]
    Error opening lower_file to read header region
    Error attempting to read the [user.ecryptfs] xattr from the lower file; return value = [-95]
    Valid metadata not found in header region or xattr region; treating file as unencrypted

    For instance, the problem can be reproduced by the steps below.

    # mkdir /root/crypt /mnt/crypt
    # mount -t ecryptfs /root/crypt /mnt/crypt
    # mknod /mnt/crypt/c0 c 0 0
    # umount /mnt/crypt
    # mount -t ecryptfs /root/crypt /mnt/crypt
    # ls -l /mnt/crypt

    This patch fixes it by adding a check similar to directories and
    symlinks.

    Signed-off-by: Ryusuke Konishi
    Acked-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ryusuke Konishi
     

20 Jul, 2007

3 commits

  • Fix page index to offset conversion overflows in buffer layer, ecryptfs,
    and ocfs2.

    It would be nice to convert the whole tree to page_offset, but for now
    just fix the bugs.

    Signed-off-by: Nick Piggin
    Cc: Michael Halcrow
    Cc: Mark Fasheh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nick Piggin
     
  • Slab destructors were no longer supported after Christoph's
    c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
    BUGs for both slab and slub, and slob never supported them
    either.

    This rips out support for the dtor pointer from kmem_cache_create()
    completely and fixes up every single callsite in the kernel (there were
    about 224, not including the slab allocator definitions themselves,
    or the documentation references).

    Signed-off-by: Paul Mundt

    Paul Mundt
     
  • There is another bug recently introduced into the ecryptfs_setattr()
    function in 2.6.22. eCryptfs will attempt to treat special files like
    regular eCryptfs files on chmod, chown, and so forth. This leads to a NULL
    pointer dereference. This patch validates that the file is a regular file
    before proceeding with operations related to the inode's crypt_stat.

    Thanks to Ryusuke Konishi for finding this bug and suggesting the fix.

    Signed-off-by: Michael Halcrow
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     

18 Jul, 2007

1 commit

  • Following was uncovered by compiling the kernel with '-W' flag:

    CC [M] fs/ecryptfs/inode.o
    fs/ecryptfs/inode.c: In function ‘ecryptfs_lookup’:
    fs/ecryptfs/inode.c:304: warning: comparison of unsigned expression < 0 is always false
    fs/ecryptfs/inode.c: In function ‘ecryptfs_symlink’:
    fs/ecryptfs/inode.c:486: warning: comparison of unsigned expression < 0 is always false

    Function ecryptfs_encode_filename() can return -ENOMEM, so change the
    variables to plain int, as in the first case the only real use actually
    expects int, and in latter case there is no use beoynd the error check.

    Signed-off-by: Mika Kukkonen
    Cc: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mika Kukkonen
     

12 Jul, 2007

1 commit

  • sysfs is now completely out of driver/module lifetime game. After
    deletion, a sysfs node doesn't access anything outside sysfs proper,
    so there's no reason to hold onto the attribute owners. Note that
    often the wrong modules were accounted for as owners leading to
    accessing removed modules.

    This patch kills now unnecessary attribute->owner. Note that with
    this change, userland holding a sysfs node does not prevent the
    backing module from being unloaded.

    For more info regarding lifetime rule cleanup, please read the
    following message.

    http://article.gmane.org/gmane.linux.kernel/510293

    (tweaked by Greg to not delete the field just yet, to make it easier to
    merge things properly.)

    Signed-off-by: Tejun Heo
    Cc: Cornelia Huck
    Cc: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Tejun Heo
     

10 Jul, 2007

1 commit


29 Jun, 2007

3 commits

  • When one llseek's past the end of the file and then writes, every page past
    the previous end of the file should be cleared. Trevor found that the code,
    as is, does not assure that the very last page is always cleared. This patch
    takes care of that.

    Signed-off-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     
  • Recent changes in eCryptfs have made it possible to get to ecryptfs_setattr()
    with an uninitialized crypt_stat struct. This results in a wide and colorful
    variety of unpleasantries. This patch properly initializes the crypt_stat
    structure in ecryptfs_setattr() when it is necessary to do so.

    Signed-off-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     
  • This patch fixes the processes involved in wiping regions of the data during
    truncate and write events, fixing a kernel hang in 2.6.22-rc4 while assuring
    that zero values are written out to the appropriate locations during events in
    which the i_size will change.

    The range passed to ecryptfs_truncate() from ecryptfs_prepare_write() includes
    the page that is the object of ecryptfs_prepare_write(). This leads to a
    kernel hang as read_cache_page() is executed on the same page in the
    ecryptfs_truncate() execution path. This patch remedies this by limiting the
    range passed to ecryptfs_truncate() so as to exclude the page that is the
    object of ecryptfs_prepare_write(); it also adds code to
    ecryptfs_prepare_write() to zero out the region of its own page when writing
    past the i_size position. This patch also modifies ecryptfs_truncate() so
    that when a file is truncated to a smaller size, eCryptfs will zero out the
    contents of the new last page from the new size through to the end of the last
    page.

    Signed-off-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     

24 May, 2007

1 commit

  • Delay writing 0's out in eCryptfs after a seek past the end of the file
    until data is actually written.

    http://www.opengroup.org/onlinepubs/009695399/functions/lseek.html

    ``The lseek() function shall not, by itself, extend the size of a
    file.''

    Without this fix, applications that lseek() past the end of the file without
    writing will experience unexpected behavior.

    Signed-off-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     

22 May, 2007

1 commit

  • First thing mm.h does is including sched.h solely for can_do_mlock() inline
    function which has "current" dereference inside. By dealing with can_do_mlock()
    mm.h can be detached from sched.h which is good. See below, why.

    This patch
    a) removes unconditional inclusion of sched.h from mm.h
    b) makes can_do_mlock() normal function in mm/mlock.c
    c) exports can_do_mlock() to not break compilation
    d) adds sched.h inclusions back to files that were getting it indirectly.
    e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
    getting them indirectly

    Net result is:
    a) mm.h users would get less code to open, read, preprocess, parse, ... if
    they don't need sched.h
    b) sched.h stops being dependency for significant number of files:
    on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
    after patch it's only 3744 (-8.3%).

    Cross-compile tested on

    all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
    alpha alpha-up
    arm
    i386 i386-up i386-defconfig i386-allnoconfig
    ia64 ia64-up
    m68k
    mips
    parisc parisc-up
    powerpc powerpc-up
    s390 s390-up
    sparc sparc-up
    sparc64 sparc64-up
    um-x86_64
    x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig

    as well as my two usual configs.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

17 May, 2007

2 commits

  • Use zero_user_page() instead of open-coding it.

    Signed-off-by: Nate Diller
    Cc: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nate Diller
     
  • SLAB_CTOR_CONSTRUCTOR is always specified. No point in checking it.

    Signed-off-by: Christoph Lameter
    Cc: David Howells
    Cc: Jens Axboe
    Cc: Steven French
    Cc: Michael Halcrow
    Cc: OGAWA Hirofumi
    Cc: Miklos Szeredi
    Cc: Steven Whitehouse
    Cc: Roman Zippel
    Cc: David Woodhouse
    Cc: Dave Kleikamp
    Cc: Trond Myklebust
    Cc: "J. Bruce Fields"
    Cc: Anton Altaparmakov
    Cc: Mark Fasheh
    Cc: Paul Mackerras
    Cc: Christoph Hellwig
    Cc: Jan Kara
    Cc: David Chinner
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

09 May, 2007

1 commit


08 May, 2007

2 commits

  • I have never seen a use of SLAB_DEBUG_INITIAL. It is only supported by
    SLAB.

    I think its purpose was to have a callback after an object has been freed
    to verify that the state is the constructor state again? The callback is
    performed before each freeing of an object.

    I would think that it is much easier to check the object state manually
    before the free. That also places the check near the code object
    manipulation of the object.

    Also the SLAB_DEBUG_INITIAL callback is only performed if the kernel was
    compiled with SLAB debugging on. If there would be code in a constructor
    handling SLAB_DEBUG_INITIAL then it would have to be conditional on
    SLAB_DEBUG otherwise it would just be dead code. But there is no such code
    in the kernel. I think SLUB_DEBUG_INITIAL is too problematic to make real
    use of, difficult to understand and there are easier ways to accomplish the
    same effect (i.e. add debug code before kfree).

    There is a related flag SLAB_CTOR_VERIFY that is frequently checked to be
    clear in fs inode caches. Remove the pointless checks (they would even be
    pointless without removeal of SLAB_DEBUG_INITIAL) from the fs constructors.

    This is the last slab flag that SLUB did not support. Remove the check for
    unimplemented flags from SLUB.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     
  • Ensure pages are uptodate after returning from read_cache_page, which allows
    us to cut out most of the filesystem-internal PageUptodate calls.

    I didn't have a great look down the call chains, but this appears to fixes 7
    possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in
    ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in
    block2mtd. All depending on whether the filler is async and/or can return
    with a !uptodate page.

    Signed-off-by: Nick Piggin
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nick Piggin
     

03 May, 2007

1 commit


26 Apr, 2007

2 commits


17 Mar, 2007

1 commit

  • ecryptfs_d_release() first dereferences a pointer (via
    ecryptfs_dentry_to_lower()) and then afterwards checks to see if the
    pointer it just dereferenced is NULL (via ecryptfs_dentry_to_private()).

    This patch moves all of the work done on the dereferenced pointer inside a
    block governed by the condition that the pointer is non-NULL.

    Signed-off-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     

08 Mar, 2007

1 commit


05 Mar, 2007

3 commits


02 Mar, 2007

4 commits


17 Feb, 2007

2 commits


15 Feb, 2007

1 commit

  • 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
     

13 Feb, 2007

6 commits