- 12 Feb, 2007 40 commits
-
-
Evgeniy Dushistov authored
These series of patches add UFS2 write-support. UFS2 - is default file system for recent versions of FreeBSD. The main differences from UFS1 from write support point of view are: 1)Not all inodes are allocated during formatation of disk. 2)All meta-data(pointer to data blocks) are 64bit(in UFS1 they are 32bit). So patch series consist of 1)make possible mount UFS2 in read-write mode 2)code to write ufs2 inodes and code to initialize inodes chunks. 3)work with 64bit meta-data I made simple testing like create/deleting/writing/reading/truncating, also I ran fsx-linux and untar and build kernel on UFS1 and UFS2, after that FreeBSD fsck do not find any errors in fs. This patch makes possible to mount ufs2 "rw", and updates UFS2 documentation: remove note about bug(it fixed by reallocate blocks on the fly patch) and add me in the list of people who want receive bug reports. Signed-off-by:
Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Alon Bar-Lev authored
Current implementation allows the kernel to receive up to 255 characters from the bootloader. While the boot protocol allows greater buffers to be sent. In current environment, the command-line is used in order to specify many values, including suspend/resume, module arguments, splash, initramfs and more. 255 characters are not enough anymore. After edd issue was fixed, and dynammic kernel command-line patch was accepted, we can extend the COMMAND_LINE_SIZE without runtime memory requirements. Signed-off-by:
Alon Bar-Lev <alon.barlev@gmail.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by:
-
Alon Bar-Lev authored
Current implementation allows the kernel to receive up to 255 characters from the bootloader. While the boot protocol allows greater buffers to be sent. In current environment, the command-line is used in order to specify many values, including suspend/resume, module arguments, splash, initramfs and more. 255 characters are not enough anymore. After edd issue was fixed, and dynammic kernel command-line patch was accepted, we can extend the COMMAND_LINE_SIZE without runtime memory requirements. Signed-off-by:
-
Alon Bar-Lev authored
Current implementation allows the kernel to receive up to 255 characters from the bootloader. While the boot protocol allows greater buffers to be sent. In current environment, the command-line is used in order to specify many values, including suspend/resume, module arguments, splash, initramfs and more. 255 characters are not enough anymore. After edd issue was fixed, and dynammic kernel command-line patch was accepted, we can extend the COMMAND_LINE_SIZE without runtime memory requirements. Signed-off-by:
-
Alon Bar-Lev authored
Remove in-source externs, linux/init.h is included in all cases. This is a fixups for "Dynamic kernel command-line" patch. It also includes some uml __init fixups so that we can __initdata also its command_line. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
Rename saved_command_line into boot_command_line. Signed-off-by:
-
Alon Bar-Lev authored
Rename saved_command_line into boot_command_line. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
Rename saved_command_line into boot_command_line. Signed-off-by:
-
Alon Bar-Lev authored
Rename saved_command_line into boot_command_line. Signed-off-by:
-
Alon Bar-Lev authored
Rename saved_command_line into boot_command_line. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
Rename saved_command_line into boot_command_line. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
Rename saved_command_line into boot_command_line. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. [akpm@osdl.org: move some declarations to the right place] Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set cris_command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. Signed-off-by:
-
Alon Bar-Lev authored
Current implementation stores a static command-line buffer allocated to COMMAND_LINE_SIZE size. Most architectures stores two copies of this buffer, one for future reference and one for parameter parsing. Current kernel command-line size for most architecture is much too small for module parameters, video settings, initramfs paramters and much more. The problem is that setting COMMAND_LINE_SIZE to a grater value, allocates static buffers. In order to allow a greater command-line size, these buffers should be dynamically allocated or marked as init disposable buffers, so unused memory can be released. This patch renames the static saved_command_line variable into boot_command_line adding __initdata attribute, so that it can be disposed after initialization. This rename is required so applications that use saved_command_line will not be affected by this change. It reintroduces saved_command_line as dynamically allocated buffer to match the data in boot_command_line. It also mark secondary command-line buffer as __initdata, and copies it to dynamically allocated static_command_line buffer components may hold reference to it after initialization. This patch is for linux-2.6.20-rc4-mm1 and is divided to target each architecture. I could not check this in any architecture so please forgive me if I got it wrong. The per-architecture modification is very simple, use boot_command_line in place of saved_command_line. The common code is the change into dynamic command-line. This patch: 1. Rename saved_command_line into boot_command_line, mark as init disposable. 2. Add dynamic allocated saved_command_line. 3. Add dynamic allocated static_command_line. 4. During startup copy: boot_command_line into saved_command_line. arch command_line into static_command_line. 5. Parse static_command_line and not arch command_line, so arch command_line may be freed. Signed-off-by:
-
Nick Piggin authored
Avoid expensive integer divide 3 times per CPU per tick. A userspace test of this loop went from 26ns, down to 19ns on a G5; and from 123ns down to 28ns on a P3. (Also avoid a variable bit shift, as suggested by Alan. The effect of this wasn't noticable on the CPUs I tested with). Signed-off-by:
Nick Piggin <npiggin@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Michael Halcrow authored
Call flush_dcache_page() after modifying a pagecache by hand. Signed-off-by:
Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by:
-
Michael Halcrow authored
Open-code flag checking and manipulation. Signed-off-by:
Trevor Highland <tshighla@us.ibm.com> Signed-off-by:
-
Michael Halcrow authored
Replace kmap() with kmap_atomic(). Reduce the amount of time that mappings are held. Signed-off-by:
-
Michael Halcrow authored
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 authored
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 authored
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 authored
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 authored
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:
-
