- 24 Feb, 2008 40 commits
-
-
Mirco Tischler authored
This fixes the following compile error caused by commit 3a2d5b70 ("PM: Introduce PM_EVENT_HIBERNATE callback state") CC [M] drivers/usb/host/u132-hcd.o drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’: drivers/usb/host/u132-hcd.c:3224: error: expected expression before ‘int’ drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use in this function) ... Signed-off-by:
Mirco Tischler <mt-ml@gmx.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Oliver Pinter authored
Signed-off-by:
Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by:
-
Linus Torvalds authored
Oleg Nesterov and others have pointed out that on some architectures, the traditional sequence of set_current_state(TASK_INTERRUPTIBLE); if (CONDITION) return; schedule(); is racy wrt another CPU doing CONDITION = 1; wake_up_process(p); because while set_current_state() has a memory barrier separating setting of the TASK_INTERRUPTIBLE state from reading of the CONDITION variable, there is no such memory barrier on the wakeup side. Now, wake_up_process() does actually take a spinlock before it reads and sets the task state on the waking side, and on x86 (and many other architectures) that spinlock is in fact equivalent to a memory barrier, but that is not generally guaranteed. The write that sets CONDITION could move into the critical region protected by the runqueue spinlock. However, adding a smp_wmb() to before the spinlock should now order the writing of CONDITION wrt the lock itself, which in turn is ordered wrt the accesses within the spinlock (which includes the reading of the old state). This should thus close the race (which probably has never been seen in practice, but since smp_wmb() is a no-op on x86, it's not like this will make anything worse either on the most common architecture where the spinlock already gave the required protection). Acked-by:
Oleg Nesterov <oleg@tv-sign.ru> Acked-by:
Dmitry Adamushko <dmitry.adamushko@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Jeff Garzik authored
- Fix build 'make randconfig' build warning spotted by Toralf Foerster: drivers/scsi/mvsas.c: In function 'mvs_hexdump': drivers/scsi/mvsas.c:715: error: implicit declaration of function 'isalnum' - Remove unneeded prototypes (spotted by hch) Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
(sorry for being offtpoic, but while experts are here...) A "typical" implementation of atomic_add_unless() can return 0 immediately after the first atomic_read() (before doing cmpxchg). In that case it doesn't provide any barrier semantics. See include/asm-ia64/atomic.h as an example. We should either change the implementation, or fix the docs. Signed-off-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Li Zefan authored
Cgroup requires the subsystem to return negative error code on error in the create method. Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by:
Balbir Singh <balbir@in.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Li Zefan authored
Remove this VM_BUG_ON(), as Balbir stated: We used to have a for loop with !list_empty() as a termination condition and VM_BUG_ON(!pc) is a spill over. With the new loop, VM_BUG_ON(!pc) does not make sense. Signed-off-by:
-
Li Zefan authored
- remove trailing " Bytes"s in the demonstration - remove section 4.4 (feature control_type has been removed) - fix reference section Signed-off-by:
-
Li Zefan authored
Signed-off-by:
Paul Menage <menage@google.com> Signed-off-by:
-
Li Zefan authored
The list head res->tasks gets initialized twice in find_css_set(). Signed-off-by:
-
Li Zefan authored
Cgroup uses unsigned long for subsys bitops, not unsigned long long. Signed-off-by:
-
Li Zefan authored
opts.release_agent is not kfree()ed in all necessary places. Signed-off-by:
-
Li Zefan authored
- replace old name 'cont' with 'cgrp' (Paul Menage did this cleanup for cgroup.c in commit bd89aabc) - remove a duplicate declaration of cgroup_path() Signed-off-by:
-
Li Zefan authored
fix: - comments about need_forkexit_callback - comments about release agent - typo and comment style, etc. Signed-off-by:
-
Li Zefan authored
Misc fixes and updates, make the doc consistent with current cgroup implementation. Signed-off-by:
-
Alexander van Heukelum authored
WARNING: vmlinux.o(.meminit.text+0x649): Section mismatch in reference from the function free_area_init_core() to the function .init.text:setup_usemap() The function __meminit free_area_init_core() references a function __init setup_usemap(). If free_area_init_core is only used by setup_usemap then annotate free_area_init_core with a matching annotation. The warning is covers this stack of functions in mm/page_alloc.c: alloc_bootmem_node must be marked __init. alloc_bootmem_node is used by setup_usemap, if !SPARSEMEM. (usemap_size is only used by setup_usemap, if !SPARSEMEM.) setup_usemap is only used by free_area_init_core. free_area_init_core is only used by free_area_init_node. free_area_init_node is used by: arch/alpha/mm/numa.c: __init paging_init() arch/arm/mm/init.c: __init bootmem_init_node() arch/avr32/mm/init.c: __init paging_init() arch/cris/arch-v10/mm/init.c: __init paging_init() arch/cris/arch-v32/mm/init.c: __init paging_init() arch/m32r/mm/discontig.c: __init zone_sizes_init() arch/m32r/mm/init.c: __init zone_sizes_init() arch/m68k/mm/motorola.c: __init paging_init() arch/m68k/mm/sun3mmu.c: __init paging_init() arch/mips/sgi-ip27/ip27-memory.c: __init paging_init() arch/parisc/mm/init.c: __init paging_init() arch/sparc/mm/srmmu.c: __init srmmu_paging_init() arch/sparc/mm/sun4c.c: __init sun4c_paging_init() arch/sparc64/mm/init.c: __init paging_init() mm/page_alloc.c: __init free_area_init_nodes() mm/page_alloc.c: __init free_area_init() and mm/memory_hotplug.c: hotadd_new_pgdat() hotadd_new_pgdat can not be an __init function, but: It is compiled for MEMORY_HOTPLUG configurations only MEMORY_HOTPLUG depends on SPARSEMEM || X86_64_ACPI_NUMA X86_64_ACPI_NUMA depends on X86_64 ARCH_FLATMEM_ENABLE depends on X86_32 ARCH_DISCONTIGMEM_ENABLE depends on X86_32 So X86_64_ACPI_NUMA implies SPARSEMEM, right? So we can mark the stack of functions __init for !SPARSEMEM, but we must mark them __meminit for SPARSEMEM configurations. This is ok, because then the calls to alloc_bootmem_node are also avoided. Compile-tested on: silly minimal config defconfig x86_32 defconfig x86_64 defconfig x86_64 -HIBERNATION +MEMORY_HOTPLUG Signed-off-by:
Alexander van Heukelum <heukelum@fastmail.fm> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Casey Schaufler authored
Update the Smack LSM to allow the registration of the capability "module" as a secondary LSM. Integrate the new hooks required for file based capabilities. Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Cc: Serge Hallyn <serue@us.ibm.com> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: Paul Moore <paul.moore@hp.com> Cc: James Morris <jmorris@namei.org> Signed-off-by:
-
Srinivasa Ds authored
Kprobes makes use of preempt_disable(),preempt_enable_noresched() and these functions inturn call add/sub_preempt_count(). So we need to refuse user from inserting probe in to these functions. This patch disallows user from probing add/sub_preempt_count(). Signed-off-by:
Srinivasa DS <srinivasa@in.ibm.com> Acked-by:
Ananth N Mavinakayanahalli <ananth@in.ibm.com> Signed-off-by:
-
Andi Kleen authored
Document huge memory/cache overhead of memory controller in Kconfig I was a little surprised that 2.6.25-rc* increased struct page for the memory controller. At least on many x86-64 machines it will not fit into a single cache line now anymore and also costs considerable amounts of RAM. At earlier review I remembered asking for a external data structure for this. It's also quite unobvious that a innocent looking Kconfig option with a single line Kconfig description has such a negative effect. This patch attempts to document these disadvantages at least so that users configuring their kernel can make a informed decision. Signed-off-by:
Andi Kleen <ak@suse.de> Cc: Balbir Singh <balbir@in.ibm.com> Acked-by:
-
Richard Kennedy authored
When running "make htmldocs" I'm seeing some non-fatal perl errors caused by trying to parse the callback function definitions in blk-core.c. The errors are "Use of uninitialized value in concatenation (.)..." in combination with: Warning(linux-2.6.25-rc2/block/blk-core.c:1877): No description found for parameter '' The function pointers are defined without a * i.e. int (drv_callback)(struct request *) The compiler is happy with them, but kernel-doc isn't. This patch teaches create_parameterlist in kernel-doc to parse this type of function pointer definition, but is it the right way to fix the problem ? The problem only seems to occur in blk-core.c. However with the patch applied, kernel-doc finds the correct parameter description for the callback in blk_end_request_callback, which is doesn't normally. I thought it would be a bit odd to change to code to use the more normal form of function pointers just to get the documentation to work, so I fixed kernel-doc instead - even though this is teaching it to understand code that might go away (The comment for blk_end_request_callback says that it should not be used and will removed at some point). Signed-off-by:
Richard Kennedy <richard@rsk.demon.co.uk> Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Yoshinori Sato authored
defconfig update. Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
-
Yoshinori Sato authored
- add missing file and declare. - remove unused file and macros. - some cleanup. Signed-off-by:
-
Yoshinori Sato authored
get_user const *ptr access fix. Signed-off-by:
-
Yoshinori Sato authored
typo fix. Signed-off-by:
-
Thomas Gleixner authored
Not all architectures implement futex_atomic_cmpxchg_inatomic(). The default implementation returns -ENOSYS, which is currently not handled inside of the futex guts. Futex PI calls and robust list exits with a held futex result in an endless loop in the futex code on architectures which have no support. Fixing up every place where futex_atomic_cmpxchg_inatomic() is called would add a fair amount of extra if/else constructs to the already complex code. It is also not possible to disable the robust feature before user space tries to register robust lists. Compile time disabling is not a good idea either, as there are already architectures with runtime detection of futex_atomic_cmpxchg_inatomic support. Detect the functionality at runtime instead by calling cmpxchg_futex_value_locked() with a NULL pointer from the futex initialization code. This is guaranteed to fail, but the call of futex_atomic_cmpxchg_inatomic() happens with pagefaults disabled. On architectures, which use the asm-generic implementation or have a runtime CPU feature detection, a -ENOSYS return value disables the PI/robust features. On architectures with a working implementation the call returns -EFAULT and the PI/robust features are enabled. The relevant syscalls return -ENOSYS and the robust list exit code is blocked, when the detection fails. Fixes http://lkml.org/lkml/2008/2/11/149 Originally reported by: Lennart Buytenhek Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Cc: Lennert Buytenhek <buytenh@wantstofly.org> Cc: Riku Voipio <riku.voipio@movial.fi> Cc: <stable@kernel.org> Signed-off-by:
-
Thomas Gleixner authored
When the futex init code fails to initialize the futex pseudo file system it returns early without initializing the hash queues. Should the boot succeed then a futex syscall which tries to enqueue a waiter on the hashqueue will crash due to the unitilialized plist heads. Initialize the hash queues before the filesystem. Signed-off-by:
-
Jean Delvare authored
Adding the same item to a given linked list more than once is guaranteed to break and corrupt the list. This is however what we do in dmi_scan since commit 79da4721 ("x86: fix DMI out of memory problems"). Given that there is absolutely no interest in saving empty OEM strings anyway, I propose the simple and efficient fix below: we discard the empty OEM strings altogether. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Parag Warudkar <parag.warudkar@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by:
-
Sergio Luis authored
Fix following warnings: WARNING: drivers/video/built-in.o(.text+0x7c64a): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c65d): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c679): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c699): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c69f): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa3676): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa3689): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa36a5): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa36c5): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa36cb): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a079a): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a07ad): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a07c9): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a07e9): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a07ef): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan Remove __devinitdata annotation from the variable ypan. Signed-off-by:
Sergio Luis <sergio@larces.uece.br> Cc: Michal Januszewski <spock@gentoo.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by:
-
Eugene Teo authored
RLIMIT_RTTIME was introduced to allow the user to set a runtime timeout on real-time tasks: http://lkml.org/lkml/2007/12/18/218. This patch updates /proc/<pid>/limits with the new rlimit. Signed-off-by:
Eugene Teo <eugeneteo@kernel.sg> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Christoph Hellwig authored
Merge include/linux/efs_fs{_i,_dir}.h into fs/efs/efs.h. efs_vh.h remains there because this is the IRIX volume header and shouldn't really be handled by efs but by the partitioning code. efs_sb.h remains there for now because it's exported to userspace. Of course this wrong and aboot should have a copy of it's own, but I'll leave that to a separate patch to avoid any contention. Signed-off-by:Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Paul Clements authored
NBD doesn't work well with CFQ (or AS) schedulers, so let's default to something else. The two problems I have experienced with nbd and cfq are: 1) nbd hangs with cfq on RHEL 5 (2.6.18) -- this may well have been fixed There's a similar debian bug that has been filed as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447638 There have been posts to nbd-general mailing list about problems with cfq and nbd also. 2) nbd performs about 10% better (the last time I tested) with deadline vs. cfq (the overhead of cfq doesn't provide much advantage to nbd [not being a real disk], and you end up going through the I/O scheduler on the nbd server anyway, so it makes sense that deadline is better with nbd) Signed-off-by:
Paul Clements <paul.clements@steeleye.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Jeff Dike authored
Commit ee3d9bd4 ("uml: simplify SIGSEGV handling"), while greatly simplifying the kernel SIGSEGV handler that runs in the process address space, introduced a bug which corrupts FP state in the process. Previously, the SIGSEGV handler called the sigreturn system call by hand - it couldn't return through the restorer provided to it because that could try to call the libc restorer which likely wouldn't exist in the process address space. So, it blocked off some signals, including SIGUSR1, on entry to the SIGSEGV handler, queued a SIGUSR1 to itself, and invoked sigreturn. The SIGUSR1 was delivered, and was visible to the UML kernel after sigreturn finished. The commit eliminated the signal masking and the call to sigreturn. The handler simply hits itself with a SIGTRAP to let the UML kernel know that it is finished. UML then restores the process registers, which effectively longjmps the process out of the signal handler, skipping sigreturn's restoring of register state and the signal mask. The bug is that the host apparently sets used_fp to 0 when it saves the process FP state in the sigcontext on the process signal stack. Thus, when the process is longjmped out of the handler, its FP state is corrupt because it wasn't saved on the context switch to the UML kernel. This manifested itself as sleep hanging. For some reason, sleep uses floating point in order to calculate the sleep interval. When a page fault corrupts its FP state, it is faked into essentially sleeping forever. This patch saves the FP state before entering the SIGSEGV handler and restores it afterwards. Signed-off-by:
Jeff Dike <jdike@linux.intel.com> Signed-off-by:
-
Johann Felix Soden authored
In commit 1aa351a3 ("uml: tidy helper code") the arguments of helper_wait() were changed. The adaptation of harddog_user.c was forgotten, so this errors occur: /arch/um/drivers/harddog_user.c: In function 'start_watchdog': /arch/um/drivers/harddog_user.c:82: error: too many arguments to function 'helper_wait' /arch/um/drivers/harddog_user.c:89: error: too many arguments to function 'helper_wait' Signed-off-by:
Johann Felix Soden <johfel@users.sourceforge.net> Signed-off-by:
-
Jeff Dike authored
The macros which extract registers from a struct sigcontext are no longer needed and can be removed. They are starting not to build anyway, given the removal of the 'e' and 'r' from register names during the x86 merge. Cc: Jiri Olsa <olsajiri@gmail.com> Signed-off-by:
-
Jean Delvare authored
Now that we gather on-board devices from both DMI types 10 and 41, there is a possibility that we list the same device twice. In order to not confuse drivers, and also to save memory, make sure that we do not add duplicate devices to the dmi_devices list. Signed-off-by:
-
David Brownell authored
For the "cmos" RTC, have /proc/driver/rtc say whether HPET based IRQ emulation is in effect. Given the problems we've had with this particular hardware maldesign (and the fact that most BIOS code seems not to provide the IRQ routing needed to use the saner HPET modes), this should help troubleshooting. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Michael Buesch authored
It turns out that I rewrote the HWRNG core once to make it pluggable, but I'm not a crypto-expert at all. So I'm certainly the wrong person for being a maintainer of the HWRNG core. Let's orphan it. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
KOSAKI Motohiro authored
Current implementation of cpuset track N_HIGH_MEMORY instead N_MEMORY. (N_MEMORY doesn't exist in current implementation) Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by:
Paul Jackson <pj@sgi.com> Cc: Christoph Lameter <clameter@sgi.com> Cc: Paul Menage <menage@google.com> Signed-off-by:
-
Ned Forrester authored
Fixes a sequencing bug in spi driver pxa2xx_spi.c in which the chip select for a transfer may be asserted before the clock polarity is set on the interface. As a result of this bug, the clock signal may have the wrong polarity at transfer start, so it may need to make an extra half transition before the intended clock/data signals begin. (This probably means all transfers are one bit out of sequence.) This only occurs on the first transfer following a change in clock polarity in systems using more than one more than one such polarity. The fix assures that the clock mode is properly set before asserting chip select. This bug was introduced in a patch merged on 2006/12/10, kernel 2.6.20. The patch defines an additional bit in: include/asm-arm/arch-pxa/regs-ssp.h for 2.6.25 and newer kernels but this addition must be made in: include/asm-arm/arch-pxa/pxa-regs.h for kernels between 2.6.20 and 2.6.24, inclusive Signed-off-by:
Ned Forrester <nforrester@whoi.edu> Signed-off-by:
-
Atsushi Nemoto authored
The atmel_spi driver does not initialize clock polarity correctly (except for at91rm9200 CS0 channel) in some case. The atmel_spi driver uses gpio-controlled chipselect. OTOH spi clock signal is controlled by CSRn.CPOL bit, but this register controls clock signal correctly only in 'real transfer' duration. At the time of cs_activate() call, CSRn.CPOL will be initialized correctly, but the controller do not know which channel is to be used next, so clock signal will stay at the inactive state of last transfer. If clock polarity of new transfer and last transfer was differ, new transfer will start with wrong clock signal state. For example, if you started SPI MODE 2 or 3 transfer after SPI MODE 0 or 1 transfer, the clock signal state at the assertion of chipselect will be low. Of course this will violates SPI transfer. This patch is short term solution for this problem. It makes all CSRn.CPOL match for the transfer before activating chipselect. For longer term, the best fix might be to let NPCS0 stay selected permanently in MR and overwrite CSR0 with to the new slave's settings before asserting CS. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Acked-by:
Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
