Arjan van de Ven [Mon, 12 Feb 2007 08:55:34 +0000 (00:55 -0800)]
[PATCH] mark struct file_operations const 6
Many struct file_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 <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Arjan van de Ven [Mon, 12 Feb 2007 08:55:34 +0000 (00:55 -0800)]
[PATCH] mark struct file_operations const 5
Many struct file_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 <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Arjan van de Ven [Mon, 12 Feb 2007 08:55:33 +0000 (00:55 -0800)]
[PATCH] mark struct file_operations const 4
Many struct file_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.
[akpm@sdl.org: dvb fix] Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Arjan van de Ven [Mon, 12 Feb 2007 08:55:32 +0000 (00:55 -0800)]
[PATCH] mark struct file_operations const 3
Many struct file_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 <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Arjan van de Ven [Mon, 12 Feb 2007 08:55:31 +0000 (00:55 -0800)]
[PATCH] mark struct file_operations const 2
Many struct file_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.
[akpm@osdl.org: sparc64 fix] Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Arjan van de Ven [Mon, 12 Feb 2007 08:55:28 +0000 (00:55 -0800)]
[PATCH] mark struct file_operations const 1
Many struct file_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 <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As the actual graphics hardware cannot be accessed directly by Linux, ps3fb
uses a virtual frame buffer in main memory. The actual screen image is copied
to graphics memory by the GPU on every vertical blank, by making a hypervisor
call.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: James Simmons <jsimmons@infradead.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Preallocate bootmem memory for the PS3 frame buffer device, which needs a
large block of physically-contiguous memory. The size of this memory block is
configurable:
- The config option CONFIG_FB_PS3_DEFAULT_SIZE_M allows to specify the
default amount of memory (in MiB) allocated to the virtual frame buffer.
- The early boot parameter `ps3fb=xxx' allows to override the default value.
It will be rounded up to a multiple of 1 MiB, if needed.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> Cc: James Simmons <jsimmons@infradead.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fb_videomode_to_var(): reset the virtual screen parameters when converting
from an fb_videomode to an fb_var_screeninfo.
Without this the old virtual screen parameters are kept. Hence you cannot
switch to a video mode with a lower resolution on frame buffer devices that
don't support virtual screens and panning, as values are not supposed to be
rounded down when they don't fit.
I also reordered the assignments to match the order of the individual members.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: James Simmons <jsimmons@infradead.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Prarit Bhargava [Mon, 12 Feb 2007 08:55:14 +0000 (00:55 -0800)]
[PATCH] change nvidiafb_remove to __devexit
Change nvidiafb_remove to __devexit to fix MODPOST warnings:
WARNING: drivers/video/nvidia/nvidiafb.o - Section mismatch: reference to
.exit.text:nvidiafb_remove from .data.rel.local after 'nvidiafb_driver' (at
offset 0x28)
Signed-off-by: Prarit Bhargava <prarit@redhat.com> Acked-By: James Simmons <jsimmons@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jiri Slaby [Mon, 12 Feb 2007 08:55:11 +0000 (00:55 -0800)]
[PATCH] Video: fb, add true ref_count atomicity
Some of fb drivers uses atomic_t in bad manner, since there are still some
race-prone gaps. Use mutexes to protect open/close code sections with
ref_count testing and finally use simple uint.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Acked-by: Denis Oliver Kropp <dok@directfb.org> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jean Delvare [Mon, 12 Feb 2007 08:55:07 +0000 (00:55 -0800)]
[PATCH] matroxfb: Use kzalloc
Use kzalloc instead of kmalloc+memset, twice.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Petr Vandrovec <vandrove@vc.cvut.cz> Acked-By: James Simmons <jsimmons@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se> Cc: Thomas Hellstrom <thomas@tungstengraphics.com> Cc: James Simmons <jsimmons@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Robert P. J. Day [Mon, 12 Feb 2007 08:55:03 +0000 (00:55 -0800)]
[PATCH] Correct apparent typo CONFIG_ATY_CT in ATY video
Replace the apparent typo CONFIG_ATY_CT with CONFIG_FB_ATY_CT.
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Cc: James Simmons <jsimmons@infradead.org> Cc: Ville Syrjala <syrjala@sci.fi> Cc: Antonino A. Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Woody Suwalski [Mon, 12 Feb 2007 08:55:00 +0000 (00:55 -0800)]
[PATCH] cyber2010 framebuffer on ARM Netwinder fix
The Netwinder machines with Cyber2010 crash badly when starting Xserver.
The workaround is to disable pci burst option for this revision of video
chip.
[akpm@osdl.org: cleanup] Signed-off-by: Woody Suwalski <woodys@xandros.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: James Simmons <jsimmons@infradead.org> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The end marker is missing from the driver's PCI ID table. This set of
changes adds the marker, switches to using PCI_DEVICE() and records the
table for the use in a module.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This sets up the deep register of the TGA ASIC as well as the blank pedestal
of the Bt463 RAMDAC correctly for the sync-on-green mode.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is a set of clean-ups for the module support in the driver -- __devinit
and __devexit classifiers are now specified correctly, initialization
functions are marked static and a few unnecessary #ifdefs are removed.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There is no need to set the GE bit (Win32 compatibility) in the mode register;
it shall get cleared with the next subsequent update to the register anyway.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The 32-plane variations of the TGA use the Bt463 RAMDAC and are therefore
DirectColor rather than TrueColor adapters. This is a set of changes to
implement the necessary bits to support this model. A couple of fixes to fix
accesses to the RAMDAC are included as a side-effect.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The direction of copying in the copyarea functions is selected incorrectly,
resulting in corruption. This is a fix.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is a set of changes to update the driver to the framebuffer_alloc() API.
Included, there is also a fix to a memory leak due to the colour map
allocation not being freed upon driver's removal. Aside from the fix there
are no functional changes.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Avi Kivity [Mon, 12 Feb 2007 08:54:47 +0000 (00:54 -0800)]
[PATCH] KVM: cpu hotplug support
On hotplug, we execute the hardware extension enable sequence. On unplug, we
decache any vcpus that last ran on the exiting cpu, and execute the hardware
extension disable sequence.
Signed-off-by: Avi Kivity <avi@qumranet.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Avi Kivity [Mon, 12 Feb 2007 08:54:43 +0000 (00:54 -0800)]
[PATCH] hotplug: Allow modules to use the cpu hotplug notifiers even if !CONFIG_HOTPLUG_CPU
The following patchset allows a host with running virtual machines to be
suspended and, on at least a subset of the machines tested, resumed. Note
that this is orthogonal to suspending and resuming an individual guest to a
file.
A side effect of implementing suspend/resume is that cpu hotplug is now
supported. This should please the owners of big iron.
This patch:
KVM wants the cpu hotplug notifications, both for cpu hotplug itself, but more
commonly for host suspend/resume.
In order to avoid extensive #ifdefs, provide stubs when CONFIG_CPU_HOTPLUG is
not defined.
In all, we have four cases:
- UP: register and unregister stubbed out
- SMP+hotplug: full register and unregister
- SMP, no hotplug, core: register as __init, unregister stubbed
(cpus are brought up during core initialization)
- SMP, no hotplug, module: register and unregister stubbed out
(cpus cannot be brought up during module lifetime)
Signed-off-by: Avi Kivity <avi@qumranet.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ingo Molnar [Mon, 12 Feb 2007 08:54:42 +0000 (00:54 -0800)]
[PATCH] kvm: fix vcpu freeing bug
vcpu_load() can return NULL and it sometimes does in failure paths (for
example when the userspace ABI version is too old) - causing a preemption
count underflow in the ->vcpu_free() later on. So check for NULL.
Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dor Laor [Mon, 12 Feb 2007 08:54:39 +0000 (00:54 -0800)]
[PATCH] kvm: Two-way apic tpr synchronization
We report the value of cr8 to userspace on an exit. Also let userspace change
cr8 when we re-enter the guest. The lets 64-bit guest code maintain the tpr
correctly.
Thanks for Yaniv Kamay for the idea.
Signed-off-by: Dor Laor <dor.laor@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The kvm mmu relies on cr0.wp being set even if the guest does not set it. The
vmx code correctly forces cr0.wp at all times, the svm code does not, so it
can't boot solaris without this patch.
Signed-off-by: Avi Kivity <avi@qumranet.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ingo Molnar [Mon, 12 Feb 2007 08:54:33 +0000 (00:54 -0800)]
[PATCH] kvm: optimize inline assembly
Forms like "0(%rsp)" generate an instruction with an unnecessary one byte
displacement under certain circumstances. replace with the equivalent
"(%rsp)".
Signed-off-by: Avi Kivity <avi@qumranet.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch adds into write inode path function to write UFS2 inode, and
modifys allocate inode path to allocate and init additional inode chunks.
Also some cleanups:
- remove not used parameters in some functions
- remove i_gen field from ufs_inode_info structure,
there is i_generation in inode structure with same purposes.
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.
Alon Bar-Lev [Mon, 12 Feb 2007 08:54:29 +0000 (00:54 -0800)]
[PATCH] ia64: 2048-byte command line
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.
Alon Bar-Lev [Mon, 12 Feb 2007 08:54:28 +0000 (00:54 -0800)]
[PATCH] x86_64: 2048-byte command line
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.
Alon Bar-Lev [Mon, 12 Feb 2007 08:54:27 +0000 (00:54 -0800)]
[PATCH] i386: 2048-byte command line
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.
Alon Bar-Lev [Mon, 12 Feb 2007 08:54:21 +0000 (00:54 -0800)]
[PATCH] Dynamic kernel command-line: sparc
Rename saved_command_line into boot_command_line.
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com> Cc: William Lee Irwin III <wli@holomorphy.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Alon Bar-Lev [Mon, 12 Feb 2007 08:54:12 +0000 (00:54 -0800)]
[PATCH] Dynamic kernel command-line: ia64
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 <alon.barlev@gmail.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Alon Bar-Lev [Mon, 12 Feb 2007 08:53:52 +0000 (00:53 -0800)]
[PATCH] Dynamic kernel command-line: common
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: Alon Bar-Lev <alon.barlev@gmail.com> Cc: Andi Kleen <ak@muc.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ian Molton <spyro@f2s.com> Cc: Mikael Starvik <starvik@axis.com> Cc: David Howells <dhowells@redhat.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp> Cc: Richard Curnow <rc@rc0.org.uk> Cc: William Lee Irwin III <wli@holomorphy.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp> Cc: Chris Zankel <chris@zankel.net> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michael Halcrow [Mon, 12 Feb 2007 08:53:48 +0000 (00:53 -0800)]
[PATCH] eCryptfs: convert f_op->write() to vfs_write()
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 <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michael Halcrow [Mon, 12 Feb 2007 08:53:47 +0000 (00:53 -0800)]
[PATCH] eCryptfs: Encrypted passthrough
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 <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michael Halcrow [Mon, 12 Feb 2007 08:53:46 +0000 (00:53 -0800)]
[PATCH] eCryptfs: Generalize metadata read/write
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 <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michael Halcrow [Mon, 12 Feb 2007 08:53:45 +0000 (00:53 -0800)]
[PATCH] eCryptfs: xattr flags and mount options
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 <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michael Halcrow [Mon, 12 Feb 2007 08:53:44 +0000 (00:53 -0800)]
[PATCH] eCryptfs: Public key; packet management
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 <mhalcrow@us.ibm.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michael Halcrow [Mon, 12 Feb 2007 08:53:43 +0000 (00:53 -0800)]
[PATCH] eCryptfs: Public key transport mechanism
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: Michael Halcrow <mhalcrow@us.ibm.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
NFS_SUPER_MAGIC is already defined in include/linux/magic.h
Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Chuck Lever [Mon, 12 Feb 2007 08:53:39 +0000 (00:53 -0800)]
[PATCH] knfsd: SUNRPC: fix up svc_create_socket() to take a sockaddr struct + length
Replace existing svc_create_socket() API to allow callers to pass addresses
larger than a sockaddr_in.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Cc: Aurelien Charbon <aurelien.charbon@ext.bull.net> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PATCH] knfsd: SUNRPC: Support IPv6 addresses in svc_tcp_accept
Modify svc_tcp_accept to support connecting on IPv6 sockets.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Cc: Aurelien Charbon <aurelien.charbon@ext.bull.net> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Chuck Lever [Mon, 12 Feb 2007 08:53:37 +0000 (00:53 -0800)]
[PATCH] knfsd: SUNRPC: add a "generic" function to see if the peer uses a secure port
The only reason svcsock.c looks at a sockaddr's port is to check whether the
remote peer is connecting from a privileged port. Refactor this check to hide
processing that is specific to address format.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Cc: Aurelien Charbon <aurelien.charbon@ext.bull.net> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
projects / linux-2.6 / log