- 24 Feb, 2008 36 commits
-
-
Yoshinori Sato authored
get_user const *ptr access fix. Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
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:
-
Hoang-Nam Nguyen authored
lib/vsprintf.c: Fix bug omitting minus sign of numbers (module_param) Signed-off-by:
Hoang-Nam Nguyen <hnguyen@de.ibm.com> Cc: Yi Yang <yi.y.yang@intel.com> Signed-off-by:
-
David Howells authored
Make is_vmalloc_addr() contingent on CONFIG_MMU=y, as it won't compile in !MMU mode. [ Bug introduced in commit 9e2779fa: "is_vmalloc_addr(): Check if an address is within the vmalloc boundaries" ]. Signed-off-by:
David Howells <dhowells@redhat.com> Cc: Greg Ungerer <gerg@snapgear.com> Cc: Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Haavard Skinnemoen authored
We should only return IRQ_HANDLED when we actually found something to handle. This is important since the USART interrupt handler may be shared with the timer interrupt on some chips. Pointed-out-by:
michael <trimarchi@gandalf.sssup.it> Signed-off-by:
-
mark gross authored
The following is a clean up and correction of the copyright holding entities for the files associated with the intel iommu code. Signed-off-by: <mgross@linux.intel.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
David Rientjes authored
Fix build failure on sparc: In file included from include/linux/mm.h:39, from include/linux/memcontrol.h:24, from include/linux/swap.h:8, from include/linux/suspend.h:7, from init/do_mounts.c:6: include/asm/pgtable.h:344: warning: parameter names (without types) in function declaration include/asm/pgtable.h:345: warning: parameter names (without types) in function declaration include/asm/pgtable.h:346: error: expected '=', ',', ';', 'asm' or '__attribute__' before '___f___swp_entry' viro sayeth: I've run allmodconfig builds on a bunch of target, FWIW (essentially the same patch). Note that these includes are recent addition caused by added inline function that had since then become a define. So while I agree with your comments in general, in _this_ case it's pretty safe. The commit that had done it is 3062fc67 ("memcontrol: move mm_cgroup to header file") and the switch to #define is in commit 60c12b12 ("memcontrol: add vm_match_cgroup()") (BTW, that probably warranted mentioning in the changelog of the latter). Cc: Adrian Bunk <bunk@kernel.org> Cc: Robert Reif <reif@earthlink.net> Signed-off-by:
David Rientjes <rientjes@google.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Harvey Harrison authored
char can be unsigned kernel/marker.c:64:20: error: dubious one-bit signed bitfield kernel/marker.c:65:14: error: dubious one-bit signed bitfield Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Acked-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by:
-
Serge E. Hallyn authored
Simplify the uid equivalence check in cap_task_kill(). Anyone can kill a process owned by the same uid. Without this patch wireshark is reported to fail. Signed-off-by:
Serge E. Hallyn <serue@us.ibm.com> Signed-off-by:
Andrew G. Morgan <morgan@kernel.org> Cc: <stable@kernel.org> Signed-off-by:
-
Andy Whitcroft authored
When we free a page via free_huge_page and we detect that we are in surplus the page will be returned to the buddy. After this we no longer own the page. However at the end free_huge_page we clear out our mapping pointer from page private. Even where the page is not a surplus we free the page to the hugepage pool, drop the pool locks and then clear page private. In either case the page may have been reallocated. BAD. Make sure we clear out page private before we free the page. Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Acked-by:
Adam Litke <agl@us.ibm.com> Cc: <stable@kernel.org> Signed-off-by:
-
Hans Rosenfeld authored
There seems to be a bug in the PM_SPECIAL macro for /proc/pid/pagemap. I think masking out those other bits makes more sense then setting all those mask bits. Signed-off-by:
Hans Rosenfeld <Hans.Rosenfeld@amd.com> Acked-by:
Matt Mackall <mpm@selenic.com> Cc: Dave Hansen <haveblue@us.ibm.com> Signed-off-by:
-
Geert Uytterhoeven authored
While linux-fbdev is subscribers-only, non-subscribers are not plainly rejected, but moderated, so the casual patch/comment/question comes through. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Roel Kluin authored
This bug snuck in with commit 252e211e Author: Mark Fortescue <mark@mtfhpc.demon.co.uk> Date: Tue Oct 16 23:26:31 2007 -0700 Add in SunOS 4.1.x compatible mode for UFS Signed-off-by:
Roel Kluin <12o3l@tiscali.nl> Acked-by:
Evgeniy Dushistov <dushistov@mail.ru> Cc: Mark Fortescue <mark@mtfhpc.demon.co.uk> Cc: <stable@kernel.org> Signed-off-by:
-
David Howells authored
Define SO_MARK for MN10300. Signed-off-by:
-
David Howells authored
Define HZ as a config option. Signed-off-by:
-
Miklos Szeredi authored
I added a nasty local variable shadowing bug to fuse in 2.6.24, with the result, that the 'default_permissions' mount option is basically ignored. How did this happen? - old err declaration in inner scope - new err getting declared in outer scope - 'return err' from inner scope getting removed - old declaration not being noticed -Wshadow would have saved us, but it doesn't seem practical for the kernel :( More testing would have also saved us :(( Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Cc: <stable@kernel.org> Signed-off-by:
-
Chris Snook authored
Make LKDTM depend on BLOCK to prevent build failures with certain configs. Signed-off-by:
Chris Snook <csnook@redhat.com> Acked-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
WANG Cong authored
Fix a shadowed variable in arch/um/kernel/mem.c, since there is a global variable has the same name. Cc: Jeff Dike <jdike@linux.intel.com> Signed-off-by:
WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by:
-
Jeff Dike authored
Update defconfig. Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Johann Felix Soden authored
If the initrd file has zero-length, the error message should contain the filepath. Cc: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by:
-
- 23 Feb, 2008 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: (25 commits) [SCSI] qlogicpt: section fixes [SCSI] mvsas: convert from rough draft to working driver [SCSI] mvsas: Add Marvell 6440 SAS/SATA driver [SCSI] libsas: correctly flush the LU queue on error recovery [SCSI] aic94xx: fix sequencer hang on error recovery [SCSI] st: compile fix when DEBUG set to one [SCSI] stex: stex_internal_copy should be called with sg_count in struct st_ccb [SCSI] stex: stex_direct_copy shouldn't call dma_map_sg [SCSI] lpfc: Balance locking [SCSI] qla4xxx: fix up residual handling [SCSI] libsas: fix error handling [SCSI] arcmsr: fix message allocation [SCSI] mptbase: fix use-after-free's [SCSI] iscsi transport: make 2 functions static [SCSI] lpfc: make lpfc_disable_node() static [SCSI] ips: fix data buffer accessors conversion bug [SCSI] gdth: don't call pci_free_consistent under spinlock [SCSI] qla2xxx: fix compile warning for printk format [SCSI] aic7xx: mitigate HOST_MSG_LOOP invalid SCB ff panic [SCSI] scsi_debug: disable clustering ...
-
Hugh Dickins authored
2.6.25-rc1 percpu changes broke CONFIG_DEBUG_PREEMPT's per_cpu checking on several architectures. On s390, sparc64 and x86 it's been weakened to not checking at all; whereas on powerpc64 it's become too strict, issuing warnings from __raw_get_cpu_var in io_schedule and init_timer for example. Fix this by weakening powerpc's __my_cpu_offset to use the non-checking local_paca instead of get_paca (which itself contains such a check); and strengthening the generic my_cpu_offset to go the old slow way via smp_processor_id when CONFIG_DEBUG_PREEMPT (debug_smp_processor_id is where all the knowledge of what's correct when lives). Signed-off-by:
Hugh Dickins <hugh@veritas.com> Reviewed-by:
Mike Travis <travis@sgi.com> Signed-off-by:
-
Rafael J. Wysocki authored
During the last step of hibernation in the "platform" mode (with the help of ACPI) we use the suspend code, including the devices' ->suspend() methods, to prepare the system for entering the ACPI S4 system sleep state. But at least for some devices the operations performed by the ->suspend() callback in that case must be different from its operations during regular suspend. For this reason, introduce the new PM event type PM_EVENT_HIBERNATE and pass it to the device drivers' ->suspend() methods during the last phase of hibernation, so that they can distinguish this case and handle it as appropriate. Modify the drivers that handle PM_EVENT_SUSPEND in a special way and need to handle PM_EVENT_HIBERNATE in the same way. These changes are necessary to fix a hibernation regression related to the i915 driver (ref. http://lkml.org/lkml/2008/2/22/488). Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Acked-by:
Pavel Machek <pavel@ucw.cz> Tested-by:
Jeff Chua <jeff.chua.linux@gmail.com> Signed-off-by:
-
Adrian Bunk authored
In current mainline, __devinit qpti_sbus_probe() still is calling __init qpti_chain_add(). Change occurrences of __init to __devinit to fix. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com>
-
