Eric Lee / smarc-fsl-linux-kernel

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 Jun, 2006

1 commit

  • 31204ed92   [PATCH] keys: discard the contents of a key on revocation ... Browse Code »

    Cause the keys linked to a keyring to be unlinked from it when revoked and it
    causes the data attached to a user-defined key to be discarded when revoked.

    This frees up most of the quota a key occupied at that point, rather than
    waiting for the key to actually be destroyed.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

07 Jan, 2006

1 commit

31 Oct, 2005

1 commit

  • 2aa349f6e   [PATCH] Keys: Export user-defined keyring operations ... Browse Code »

    Export user-defined key operations so that those who wish to define their
    own key type based on the user-defined key operations may do so (as has
    been requested).

    The header file created has been placed into include/keys/user-type.h, thus
    creating a directory where other key types may also be placed. Any
    objections to doing this?

    Signed-Off-By: David Howells
    Signed-Off-By: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

24 Jun, 2005

2 commits

  • 16c29b67f   [PATCH] eCryptfs: export user key type ... Browse Code »

    Export this symbol to GPL modules for eCryptfs: an out-of-tree GPL'ed
    filesystem.

    Signed off by: Michael Halcrow

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

    Michael Halcrow
     
  • 76d8aeabf   [PATCH] keys: Discard key spinlock and use RCU for key payload ... Browse Code »

    The attached patch changes the key implementation in a number of ways:

    (1) It removes the spinlock from the key structure.

    (2) The key flags are now accessed using atomic bitops instead of
    write-locking the key spinlock and using C bitwise operators.

    The three instantiation flags are dealt with with the construction
    semaphore held during the request_key/instantiate/negate sequence, thus
    rendering the spinlock superfluous.

    The key flags are also now bit numbers not bit masks.

    (3) The key payload is now accessed using RCU. This permits the recursive
    keyring search algorithm to be simplified greatly since no locks need be
    taken other than the usual RCU preemption disablement. Searching now does
    not require any locks or semaphores to be held; merely that the starting
    keyring be pinned.

    (4) The keyring payload now includes an RCU head so that it can be disposed
    of by call_rcu(). This requires that the payload be copied on unlink to
    prevent introducing races in copy-down vs search-up.

    (5) The user key payload is now a structure with the data following it. It
    includes an RCU head like the keyring payload and for the same reason. It
    also contains a data length because the data length in the key may be
    changed on another CPU whilst an RCU protected read is in progress on the
    payload. This would then see the supposed RCU payload and the on-key data
    length getting out of sync.

    I'm tempted to drop the key's datalen entirely, except that it's used in
    conjunction with quota management and so is a little tricky to get rid
    of.

    (6) Update the keys documentation.

    Signed-Off-By: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

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