- 05 Aug, 2005 14 commits
-
-
Len Brown authored
Signed-off-by: Len Brown <len.brown@intel.com>
-
Pavel Machek authored
Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Len Brown <len.brown@intel.com>
-
Len Brown authored
Signed-off-by: Len Brown <len.brown@intel.com>
-
Adrian Bunk authored
prevent: HOTPLUG_CPU=y ACPI_PROCESSOR=y ACPI_HOTPLUG_CPU=n Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Andrew Morton authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Karol Kozimor authored
The video driver doesn't properly remove all the notify handlers on module unload. This has a side effect of subdevices failing to register on module reload, but sudden death looms if the handlers trigger after the module is unloaded. Signed-off-by: Karol Kozimor <sziwan@hell.org.pl> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Andrew Morton authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intelc.com>
-
Andrew Morton authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Kenji Kaneshige authored
error condition is passed along by acpi_register_gsi(). Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Kenji Kaneshige authored
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Kenji Kaneshige authored
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Kenji Kaneshige authored
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Kenji Kaneshige authored
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
Kenji Kaneshige authored
Current acpi_register_gsi() function has no way to indicate errors to its callers even though acpi_register_gsi() can fail to register gsi because of some reasons (out of memory, lack of interrupt vectors, incorrect BIOS, and so on). As a result, caller of acpi_register_gsi() cannot handle the case that acpi_register_gsi() fails. I think failure of acpi_register_gsi() should be handled properly. This series of patches changes acpi_register_gsi() to return negative value on error, and also changes callers of acpi_register_gsi() to handle failure of acpi_register_gsi(). This patch changes the type of return value of acpi_register_gsi() from "unsigned int" to "int" to indicate an error. If acpi_register_gsi() fails to register gsi, it returns negative value. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
-
- 04 Aug, 2005 26 commits
-
-
Len Brown authored
-
Hugh Dickins authored
mremap's move_vma is applying __vm_stat_account to the old vma which may have already been freed: move it to just before the do_munmap. mremapping to and fro with CONFIG_DEBUG_SLAB=y showed /proc/<pid>/status VmSize and VmData wrapping just like in kernel bugzilla #4842, and fixed by this patch - worth including in 2.6.13, though not yet confirmed that it fixes that specific report from Frank van Maarseveen. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
John McCutchan authored
The included patch fixes a problem where a inotify client would receive a delete event before the file was actually deleted. The bug affects both dnotify & inotify. Signed-off-by: John McCutchan <ttb@tentacle.dhs.org> Signed-off-by: Robert Love <rml@novell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Robert Love authored
The inotify help text still refers to the character device. Update it. Fixes kernel bug #4993. Signed-off-by: Robert Love <rml@novell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
David Howells authored
The attached patch makes sure that a keyring that failed to instantiate properly is destroyed without oopsing [CAN-2005-2099]. The problem occurs in three stages: (1) The key allocator initialises the type-specific data to all zeroes. In the case of a keyring, this will become a link in the keyring name list when the keyring is instantiated. (2) If a user (any user) attempts to add a keyring with anything other than an empty payload, the keyring instantiation function will fail with an error and won't add the keyring to the name list. (3) The keyring's destructor then sees that the keyring has a description (name) and tries to remove the keyring from the name list, which oopses because the link pointers are both zero. This bug permits any user to take down a box trivially. Signed-Off-By: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
David Howells authored
The attached patch prevents an error during the key session joining operation from hanging future joins in the D state [CAN-2005-2098]. The problem is that the error handling path for the KEYCTL_JOIN_SESSION_KEYRING operation has one error path that doesn't release the session management semaphore. Further attempts to get the semaphore will then sleep for ever in the D state. This can happen in four situations, all involving an attempt to allocate a new session keyring: (1) ENOMEM. (2) The users key quota being reached. (3) A keyring name that is an empty string. (4) A keyring name that is too long. Any user may attempt this operation, and so any user can cause the problem to occur. Signed-Off-By: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Paul Mackerras authored
The kexec boot is not successful on some power machines since all CPUs are getting removed from global interrupt queue (GIQ) before kexec boot. Some systems always expect at least one CPU in GIQ. Hence, this patch will make sure that only secondary CPUs are removed from GIQ. Signed-off-by: Haren Myneni <hbabu@us.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Alasdair G Kergon authored
This code was never designed to handle more than one instance of do_work() running at once. Signed-Off-By: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jim Keniston authored
Acked-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> Signed-off-by: Jim Keniston <jkenisto@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
The recent change to never ignore the bitmap, revealed that the bitmap isn't begin flushed properly when an array is stopped. We call bitmap_daemon_work three times as there is a three-stage pipeline for flushing updates to the bitmap file. Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
Firstly, R1BIO_Degraded was being set in a number of places in the resync code, but is never used there, so get rid of those settings. Then: When doing a resync, we want to clear the bit in the bitmap iff the array will be non-degraded when the sync has completed. However the current code would clear the bitmap if the array was non-degraded when the resync *started*, which obviously isn't right (it is for 'resync' but not for 'recovery' - i.e. rebuilding a failed drive). This patch calculated 'still_degraded' and uses the to tell bitmap_start_sync whether this sync should clear the corresponding bit. Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
The code currently will ignore the bitmap if the array seem to be in-sync. This is wrong if the array is degraded, and probably wrong anyway. If the bitmap says some chunks are not in in-sync, and the superblock says everything IS in sync, then something is clearly wrong, and it is safer to trust the bitmap. Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
Until the bitmap code was added, modprobe md would load the md module. But now the md module is called 'md-mod', so we really need an alias for backwards comparability. Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Mauro Carvalho Chehab authored
no_overlay bttv parameter implemented to fix OOPS on some PCI chipsets (like some VIA) with these behaviors: 1) If pci_quicks does identify the chip as having troubles to handle PCI2PCI transfers, no_overlay defaults to 1. The user may force it to 0, to reenable (not recommended). 2) For newer chipsets not blacklisted, no_overlay=1 is provided as a workaround until PCI chipset included on /drivers/pci/quirks.c Thanks to Bodo Eggert <7eggert@gmx.de> Signed-off-by: Michael Krufky <mkrufky@m1k.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Olof Johansson authored
CONFIG_KEXEC breaks UP builds because of a misspelled smp_release_cpus(). Also, the function isn't defined unless built with CONFIG_SMP but it is needed if we are to go from a UP to SMP kernel. Enable it and document it. Thanks to Steven Winiecki for reporting this and to Milton for remembering how it's supposed to work and why. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Ravikiran G Thirumalai authored
Patch fixes oops caused by ide interfaces not on pci. pcibus_to_node causes the kernel to crash otherwise. Patch also adds a BUG_ON to check if hwif is NULL. Signed-off-by: Christoph Lameter <christoph@lameter.com> Signed-off-by: Shai Fultheim <shai@scalex86.org> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Cc: Andi Kleen <ak@muc.de> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Michael Gernoth authored
Patch from Michael Gernoth As discussed on the handhelds.org Jornada mailinglist, I take over maintainership of the currently unmaintained Jornada 720-port in the mainline kernel. Signed-off-by: Michael Gernoth <michael@gernoth.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
James Bottomley authored
Several people noticed we dropped quite a bit on benchmark figures. OK, it was my fault but unfortunately I discovered I ran out of brown paper bags a while ago and forgot to reorder them. The issue is that a construct introduced in the conversion of the driver to use the transport class keyed off whether the block request was tagged or not. However, the aic7xxx driver doesn't properly set up the block layer TCQ (it uses the wrong API), so the driver now things all requests are untagged and we keep it to a queue depth of a single element. Oops. The fix is to use the correct TCQ API. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
Fix up arm26, cris, frv, m68k, parisc and sh64 too..
-
Alexander Nyberg authored
x86_64 had hardcoded the VM_ numbers so it broke down when the numbers were changed. Signed-off-by: Alexander Nyberg <alexn@telia.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-