Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 24 5月, 2007 1 次提交
  3. 22 5月, 2007 1 次提交
    • A
      Detach sched.h from mm.h · e8edc6e0
      由 Alexey Dobriyan 提交于 
      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: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8edc6e0
  5. 17 5月, 2007 2 次提交
  7. 09 5月, 2007 1 次提交
  9. 08 5月, 2007 2 次提交
    • C
      slab allocators: Remove SLAB_DEBUG_INITIAL flag · 50953fe9
      由 Christoph Lameter 提交于 
      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: NChristoph Lameter <clameter@sgi.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      50953fe9
    • N
      mm: make read_cache_page synchronous · 6fe6900e
      由 Nick Piggin 提交于 
      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: NNick Piggin <npiggin@suse.de>
Cc: Hugh Dickins <hugh@veritas.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6fe6900e
  11. 03 5月, 2007 1 次提交
  13. 26 4月, 2007 2 次提交
  15. 17 3月, 2007 1 次提交
  17. 08 3月, 2007 1 次提交
  19. 05 3月, 2007 3 次提交
  21. 02 3月, 2007 4 次提交
  23. 17 2月, 2007 2 次提交
  25. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      由 Tim Schmielau 提交于 
      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: NTim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  27. 13 2月, 2007 11 次提交
    • J
      [PATCH] Mark struct super_operations const · ee9b6d61
      由 Josef 'Jeff' Sipek 提交于 
      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: NJosef 'Jeff' Sipek <jsipek@cs.sunysb.edu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ee9b6d61
    • A
      [PATCH] mark struct inode_operations const 1 · 754661f1
      由 Arjan van de Ven 提交于 
      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: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      754661f1
    • M
      [PATCH] eCryptfs: add flush_dcache_page() calls · 0a9ac382
      由 Michael Halcrow 提交于 
      Call flush_dcache_page() after modifying a pagecache by hand.
Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0a9ac382
    • M
      [PATCH] eCryptfs: open-code flag checking and manipulation · e2bd99ec
      由 Michael Halcrow 提交于 
      Open-code flag checking and manipulation.
Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NTrevor Highland <tshighla@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e2bd99ec
    • M
      [PATCH] eCryptfs: convert kmap() to kmap_atomic() · 9d8b8ce5
      由 Michael Halcrow 提交于 
      Replace kmap() with kmap_atomic().  Reduce the amount of time that mappings
are held.
Signed-off-by: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NTrevor Highland <tshighla@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9d8b8ce5
    • M
      [PATCH] eCryptfs: convert f_op->write() to vfs_write() · 70456600
      由 Michael Halcrow 提交于 
      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: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      70456600
    • M
      [PATCH] eCryptfs: Encrypted passthrough · e77a56dd
      由 Michael Halcrow 提交于 
      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: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e77a56dd
    • M
      [PATCH] eCryptfs: Generalize metadata read/write · dd2a3b7a
      由 Michael Halcrow 提交于 
      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: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dd2a3b7a
    • M
      [PATCH] eCryptfs: xattr flags and mount options · 17398957
      由 Michael Halcrow 提交于 
      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: NMichael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      17398957
    • M
      [PATCH] eCryptfs: Public key; packet management · dddfa461
      由 Michael Halcrow 提交于 
      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: NMichael Halcrow <mhalcrow@us.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dddfa461
    • M
      [PATCH] eCryptfs: Public key transport mechanism · 88b4a07e
      由 Michael Halcrow 提交于 
      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 uid<->pid 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: NMichael Halcrow <mhalcrow@us.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      88b4a07e
  29. 12 2月, 2007 1 次提交
  31. 07 2月, 2007 1 次提交
  33. 09 12月, 2006 3 次提交
  35. 08 12月, 2006 2 次提交