Eric Lee / smarc-fsl-linux-kernel

22 May, 2007

1 commit

  • e8edc6e03   Detach sched.h from mm.h ... Browse Code »

    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

  • c9f2875b7   ecryptfs: use zero_user_page ... Browse Code »

    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
     
  • a35afb830   Remove SLAB_CTOR_CONSTRUCTOR ... Browse Code »

    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

  • 50953fe9e   slab allocators: Remove SLAB_DEBUG_INITIAL flag ... Browse Code »

    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
     
  • 6fe6900e1   mm: make read_cache_page synchronous ... Browse Code »

    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

  • b228b8e5b   [PATCH] eCryptfs: fix possible NULL ptr deref in ecryptfs_d_release() ... Browse Code »

    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

  • 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
     

13 Feb, 2007

11 commits

  • ee9b6d61a   [PATCH] Mark struct super_operations const ... Browse Code »

    This patch is inspired by Arjan's "Patch series to mark struct
    file_operations and struct inode_operations const".

    Compile tested with gcc & sparse.

    Signed-off-by: Josef 'Jeff' Sipek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josef 'Jeff' Sipek
     
  • 754661f14   [PATCH] mark struct inode_operations const 1 ... Browse Code »

    Many struct inode_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     
  • 0a9ac3824   [PATCH] eCryptfs: add flush_dcache_page() calls ... Browse Code »

    Call flush_dcache_page() after modifying a pagecache by hand.

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

    Michael Halcrow
     
  • e2bd99ec5   [PATCH] eCryptfs: open-code flag checking and manipulation ... Browse Code »

    Open-code flag checking and manipulation.

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

    Michael Halcrow
     
  • 9d8b8ce55   [PATCH] eCryptfs: convert kmap() to kmap_atomic() ... Browse Code »

    Replace kmap() with kmap_atomic(). Reduce the amount of time that mappings
    are held.

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

    Michael Halcrow
     
  • 70456600f   [PATCH] eCryptfs: convert f_op->write() to vfs_write() ... Browse Code »

    sys_write() takes a local copy of f_pos and writes that back
    into the struct file. It does this so that two concurrent write()
    callers don't make a mess of f_pos, and of the file contents.

    ecryptfs should be calling vfs_write(). That way we also get the fsnotify
    notifications, which ecryptfs presently appears to have subverted.

    Convert direct calls to f_op->write() into calls to vfs_write().

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

    Michael Halcrow
     
  • e77a56ddc   [PATCH] eCryptfs: Encrypted passthrough ... Browse Code »

    Provide an option to provide a view of the encrypted files such that the
    metadata is always in the header of the files, regardless of whether the
    metadata is actually in the header or in the extended attribute. This mode of
    operation is useful for applications like incremental backup utilities that do
    not preserve the extended attributes when directly accessing the lower files.

    With this option enabled, the files under the eCryptfs mount point will be
    read-only.

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

    Michael Halcrow
     
  • dd2a3b7ad   [PATCH] eCryptfs: Generalize metadata read/write ... Browse Code »

    Generalize the metadata reading and writing mechanisms, with two targets for
    now: metadata in file header and metadata in the user.ecryptfs xattr of the
    lower file.

    [akpm@osdl.org: printk warning fix]
    [bunk@stusta.de: make some needlessly global code static]
    Signed-off-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     
  • 17398957a   [PATCH] eCryptfs: xattr flags and mount options ... Browse Code »

    This patch set introduces the ability to store cryptographic metadata into an
    lower file extended attribute rather than the lower file header region.

    This patch set implements two new mount options:

    ecryptfs_xattr_metadata
    - When set, newly created files will have their cryptographic
    metadata stored in the extended attribute region of the file rather
    than the header.

    When storing the data in the file header, there is a minimum of 8KB
    reserved for the header information for each file, making each file at
    least 12KB in size. This can take up a lot of extra disk space if the user
    creates a lot of small files. By storing the data in the extended
    attribute, each file will only occupy at least of 4KB of space.

    As the eCryptfs metadata set becomes larger with new features such as
    multi-key associations, most popular filesystems will not be able to store
    all of the information in the xattr region in some cases due to space
    constraints. However, the majority of users will only ever associate one
    key per file, so most users will be okay with storing their data in the
    xattr region.

    This option should be used with caution. I want to emphasize that the
    xattr must be maintained under all circumstances, or the file will be
    rendered permanently unrecoverable. The last thing I want is for a user to
    forget to set an xattr flag in a backup utility, only to later discover
    that their backups are worthless.

    ecryptfs_encrypted_view
    - When set, this option causes eCryptfs to present applications a
    view of encrypted files as if the cryptographic metadata were
    stored in the file header, whether the metadata is actually stored
    in the header or in the extended attributes.

    No matter what eCryptfs winds up doing in the lower filesystem, I want
    to preserve a baseline format compatibility for the encrypted files. As of
    right now, the metadata may be in the file header or in an xattr. There is
    no reason why the metadata could not be put in a separate file in future
    versions.

    Without the compatibility mode, backup utilities would have to know to
    back up the metadata file along with the files. The semantics of eCryptfs
    have always been that the lower files are self-contained units of encrypted
    data, and the only additional information required to decrypt any given
    eCryptfs file is the key. That is what has always been emphasized about
    eCryptfs lower files, and that is what users expect. Providing the
    encrypted view option will provide a way to userspace applications wherein
    they can always get to the same old familiar eCryptfs encrypted files,
    regardless of what eCryptfs winds up doing with the metadata behind the
    scenes.

    This patch:

    Add extended attribute support to version bit vector, flags to indicate when
    xattr or encrypted view modes are enabled, and support for the new mount
    options.

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

    Michael Halcrow
     
  • dddfa461f   [PATCH] eCryptfs: Public key; packet management ... Browse Code »

    Public key support code. This reads and writes packets in the header that
    contain public key encrypted file keys. It calls the messaging code in the
    previous patch to send and receive encryption and decryption request
    packets from the userspace daemon.

    [akpm@osdl.org: cleab fix]
    Signed-off-by: Michael Halcrow
    Cc: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     
  • 88b4a07e6   [PATCH] eCryptfs: Public key transport mechanism ... Browse Code »

    This is the transport code for public key functionality in eCryptfs. It
    manages encryption/decryption request queues with a transport mechanism.
    Currently, netlink is the only implemented transport.

    Each inode has a unique File Encryption Key (FEK). Under passphrase, a File
    Encryption Key Encryption Key (FEKEK) is generated from a salt/passphrase
    combo on mount. This FEKEK encrypts each FEK and writes it into the header of
    each file using the packet format specified in RFC 2440. This is all
    symmetric key encryption, so it can all be done via the kernel crypto API.

    These new patches introduce public key encryption of the FEK. There is no
    asymmetric key encryption support in the kernel crypto API, so eCryptfs pushes
    the FEK encryption and decryption out to a userspace daemon. After
    considering our requirements and determining the complexity of using various
    transport mechanisms, we settled on netlink for this communication.

    eCryptfs stores authentication tokens into the kernel keyring. These tokens
    correlate with individual keys. For passphrase mode of operation, the
    authentication token contains the symmetric FEKEK. For public key, the
    authentication token contains a PKI type and an opaque data blob managed by
    individual PKI modules in userspace.

    Each user who opens a file under an eCryptfs partition mounted in public key
    mode must be running a daemon. That daemon has the user's credentials and has
    access to all of the keys to which the user should have access. The daemon,
    when started, initializes the pluggable PKI modules available on the system
    and registers itself with the eCryptfs kernel module. Userspace utilities
    register public key authentication tokens into the user session keyring.
    These authentication tokens correlate key signatures with PKI modules and PKI
    blobs. The PKI blobs contain PKI-specific information necessary for the PKI
    module to carry out asymmetric key encryption and decryption.

    When the eCryptfs module parses the header of an existing file and finds a Tag
    1 (Public Key) packet (see RFC 2440), it reads in the public key identifier
    (signature). The asymmetrically encrypted FEK is in the Tag 1 packet;
    eCryptfs puts together a decrypt request packet containing the signature and
    the encrypted FEK, then it passes it to the daemon registered for the
    current->euid via a netlink unicast to the PID of the daemon, which was
    registered at the time the daemon was started by the user.

    The daemon actually just makes calls to libecryptfs, which implements request
    packet parsing and manages PKI modules. libecryptfs grabs the public key
    authentication token for the given signature from the user session keyring.
    This auth tok tells libecryptfs which PKI module should receive the request.
    libecryptfs then makes a decrypt() call to the PKI module, and it passes along
    the PKI block from the auth tok. The PKI uses the blob to figure out how it
    should decrypt the data passed to it; it performs the decryption and passes
    the decrypted data back to libecryptfs. libecryptfs then puts together a
    reply packet with the decrypted FEK and passes that back to the eCryptfs
    module.

    The eCryptfs module manages these request callouts to userspace code via
    message context structs. The module maintains an array of message context
    structs and places the elements of the array on two lists: a free and an
    allocated list. When eCryptfs wants to make a request, it moves a msg ctx
    from the free list to the allocated list, sets its state to pending, and fires
    off the message to the user's registered daemon.

    When eCryptfs receives a netlink message (via the callback), it correlates the
    msg ctx struct in the alloc list with the data in the message itself. The
    msg->index contains the offset of the array of msg ctx structs. It verifies
    that the registered daemon PID is the same as the PID of the process that sent
    the message. It also validates a sequence number between the received packet
    and the msg ctx. Then, it copies the contents of the message (the reply
    packet) into the msg ctx struct, sets the state in the msg ctx to done, and
    wakes up the process that was sleeping while waiting for the reply.

    The sleeping process was whatever was performing the sys_open(). This process
    originally called ecryptfs_send_message(); it is now in
    ecryptfs_wait_for_response(). When it wakes up and sees that the msg ctx
    state was set to done, it returns a pointer to the message contents (the reply
    packet) and returns. If all went well, this packet contains the decrypted
    FEK, which is then copied into the crypt_stat struct, and life continues as
    normal.

    The case for creation of a new file is very similar, only instead of a decrypt
    request, eCryptfs sends out an encrypt request.

    > - We have a great clod of key mangement code in-kernel. Why is that
    > not suitable (or growable) for public key management?

    eCryptfs uses Howells' keyring to store persistent key data and PKI state
    information. It defers public key cryptographic transformations to userspace
    code. The userspace data manipulation request really is orthogonal to key
    management in and of itself. What eCryptfs basically needs is a secure way to
    communicate with a particular daemon for a particular task doing a syscall,
    based on the UID. Nothing running under another UID should be able to access
    that channel of communication.

    > - Is it appropriate that new infrastructure for public key
    > management be private to a particular fs?

    The messaging.c file contains a lot of code that, perhaps, could be extracted
    into a separate kernel service. In essence, this would be a sort of
    request/reply mechanism that would involve a userspace daemon. I am not aware
    of anything that does quite what eCryptfs does, so I was not aware of any
    existing tools to do just what we wanted.

    > What happens if one of these daemons exits without sending a quit
    > message?

    There is a stale uidpid association in the hash table for that user. When
    the user registers a new daemon, eCryptfs cleans up the old association and
    generates a new one. See ecryptfs_process_helo().

    > - _why_ does it use netlink?

    Netlink provides the transport mechanism that would minimize the complexity of
    the implementation, given that we can have multiple daemons (one per user). I
    explored the possibility of using relayfs, but that would involve having to
    introduce control channels and a protocol for creating and tearing down
    channels for the daemons. We do not have to worry about any of that with
    netlink.

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

    Michael Halcrow
     

12 Feb, 2007

1 commit

  • c37622296   [PATCH] Transform kmem_cache_alloc()+memset(0) -> kmem_cache_zalloc(). ... Browse Code »

    Replace appropriate pairs of "kmem_cache_alloc()" + "memset(0)" with the
    corresponding "kmem_cache_zalloc()" call.

    Signed-off-by: Robert P. J. Day
    Cc: "Luck, Tony"
    Cc: Andi Kleen
    Cc: Roland McGrath
    Cc: James Bottomley
    Cc: Greg KH
    Acked-by: Joel Becker
    Cc: Steven Whitehouse
    Cc: Jan Kara
    Cc: Michael Halcrow
    Cc: "David S. Miller"
    Cc: Stephen Smalley
    Cc: James Morris
    Cc: Chris Wright
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Robert P. J. Day
     

07 Feb, 2007

1 commit

09 Dec, 2006

3 commits

08 Dec, 2006

3 commits

  • 8487f2e40   [PATCH] make ecryptfs_version_str_map[] static ... Browse Code »

    Signed-off-by: Adrian Bunk
    Acked-by: Michael Halcrow
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     
  • e18b890bb   [PATCH] slab: remove kmem_cache_t ... Browse Code »

    Replace all uses of kmem_cache_t with struct kmem_cache.

    The patch was generated using the following script:

    #!/bin/sh
    #
    # Replace one string by another in all the kernel sources.
    #

    set -e

    for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do
    quilt add $file
    sed -e "1,\$s/$1/$2/g" $file >/tmp/$$
    mv /tmp/$$ $file
    quilt refresh
    done

    The script was run like this

    sh replace kmem_cache_t "struct kmem_cache"

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

    Christoph Lameter
     
  • e94b17660   [PATCH] slab: remove SLAB_KERNEL ... Browse Code »

    SLAB_KERNEL is an alias of GFP_KERNEL.

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

    Christoph Lameter