- 06 Aug, 2005 3 commits
-
-
Marcel Holtmann authored
There's no need to check for NULL before calling kfree() on a pointer. Signed-off-by:
Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The fix for the reference counting problem of the signal DLC introduced a race condition which leads to an oops. The reason for it is not fully understood by now and so revert this fix, because the reference counting problem is not crashing the RFCOMM layer and its appearance it rare. Signed-off-by: -
Marcel Holtmann authored
The Kensington Bluetooth USB adapter is based on a Broadcom chip with the HID proxy support. To initialize these kind of devices correctly it is necessary to send HCI_Reset as the first command. Signed-off-by:
-
- 05 Aug, 2005 21 commits
-
-
Matt Porter authored
This patch fixes a bug in the PPC440 pagetable attributes that breaks swap support. It also adds some notes on the PPC440 attribute fields. Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF Signed-off-by:
Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Tim Yamin authored
These bugs have been fixed in the standard zlib for a while. See for example a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html b) http://bugs.gentoo.org/show_bug.cgi?id=94584Signed-off-by:
Tim Yamin <plasmaroo@gentoo.org> Signed-off-by:
Tavis Ormandy <taviso@gentoo.org> Signed-off-by:
-
Ingo Molnar authored
semundo->lock can leak if semundo->refcount goes from 2 to 1 while another thread has it locked. This causes major problems for PREEMPT kernels. The simplest fix for now is to undo the single-thread optimization. This bug was found via relentless testing by Dominik Karall. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Tejun Heo authored
My patch in commit fa72b903 incorrectly removed blk_queue_tag->real_max_depth. The original resize implementation was incorrect in the following points. * actual allocation size of tag_index was shorter than real_max_size, but assumed to be of the same size, possibly causing memory access beyond the allocated area. * bits in tag_map between max_deptn and real_max_depth were initialized to 1's, making the tags permanently reserved. In an attempt to fix above two bugs, I had removed allocation optimization in init_tag_map and real_max_size. Tag map/index were allocated and freed immediately during resize. Unfortunately, I wasn't considering that tag map/index can be resized dynamically with tags beyond new_depth active. This led to accessing freed area after shrinking tags and led to the following bug reporting thread on linux-scsi. http://marc.theaimsgroup.com/?l=linux-scsi&m=112319898111885&w=2 To fix the problem, I've revived real_max_depth without allocation optimization in init_tag_map, and Andrew Vasquez confirmed that the problem was fixed. As Jens is not going to be available for a week, he asked me to make sure that this patch reaches you. http://marc.theaimsgroup.com/?l=linux-scsi&m=112325778530886&w=2 Also, a comment was added to make sure that real_max_size is needed for dynamic shrinking. Signed-off-by:
Tejun Heo <htejun@gmail.com> Signed-off-by:
-
David Gibson authored
This patch fixes a crash in the hugepage code. unmap_hugepage_area() was assuming that (due to prefault) PTEs must exist for all the area in question. However, this may not be the case, if mmap() encounters an error before the prefault and calls unmap_region() to clean up any partial mapping. Depending on the hugepage configuration, this crash can be triggered by an unpriveleged user. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Cc: William Lee Irwin III <wli@holomorphy.com> Signed-off-by:
-
James Bottomley authored
[PATCH] i386: Implement machine_emergency_reboot introduced this new function into arch/i386/reboot.c. However, subarchitectures are entitled to implement their own copies of reboot.c from which this new function is now missing. It looks like visws will also need a similar fixup Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Marcel Selhorst authored
This patch includes support for the new Infineon Trusted Platform Module SLB 9635 TT 1.2 and does further include ACPI-support for both chip versions (SLD 9630 TT 1.1 and SLB9635 TT 1.2). Since the ioports and configuration registers are not correctly set on some machines, the configuration is now done via PNPACPI, which reads out the correct values out of the DSDT-table. Note that you have to have CONFIG_PNP, CONFIG_ACPI_BUS and CONFIG_PNPACPI enabled to run this driver (assuming that mainboards including a TPM do have the need for ACPI anyway). Signed-off-by:
Marcel Selhorst <selhorst@crypto.rub.de> Signed-off-by:
-
Andrew Morton authored
Add a new record to the REPORTING-BUGS template: "Most recent kernel version which did not have the bug:". So we can spot regressions more easily. Signed-off-by:
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Petr Vandrovec authored
Since the beginning of July my Opteron box was randomly crashing and being rebooted by hardware watchdog. Today it finally did it in front of me, and this patch will hopefully fix it. The problem is that at the end of June (the 28th, to be exact: commit 47f176fd, "[PATCH] Using msleep() instead of HZ") rtc_get_rtc_time was converted to use msleep() instead of busy waiting. But rtc_get_rtc_time is used by hpet_rtc_interrupt, and scheduling is not allowed during interrupt. So I'm reverting this part of original change, replacing msleep() back with busy loop. The original code was busy waiting for up to 20ms, but on my hardware in the worst case update-in-progress bit was asserted for at most 363 passes through loop (on 2GHz dual Opteron), much less than even one jiffie, not even talking about 20ms. So I changed code to just wait only as long as necessary. Otherwise when RTC was set to generate 8192Hz timer, it stopped doing anything for 20ms (160 pulses were skipped!) from time to time, and this is rather suboptimal as far as I can tell. Signed-off-by:
Petr Vandrovec <vandrove@vc.cvut.cz> Signed-off-by:
-
David S. Miller authored
When we grow the tables, we forget to free the olds ones up. Noticed by Yan Zheng. Signed-off-by:David S. Miller <davem@davemloft.net>
-
Simon Derr authored
We have found what seems to be a small bug in __vm_enough_memory() when sysctl_overcommit_memory is set to OVERCOMMIT_NEVER. When this bug occurs the systems fails to boot, with /sbin/init whining about fork() returning ENOMEM. We hunted down the problem to this: The deferred update mecanism used in vm_acct_memory(), on a SMP system, allows the vm_committed_space counter to have a negative value. This should not be a problem since this counter is known to be inaccurate. But in __vm_enough_memory() this counter is compared to the `allowed' variable, which is an unsigned long. This comparison is broken since it will consider the negative values of vm_committed_space to be huge positive values, resulting in a memory allocation failure. Signed-off-by: <Jean-Marc.Saffroy@ext.bull.net> Signed-off-by: <Simon.Derr@bull.net> Signed-off-by:
-
Herbert Xu authored
tcp_write_xmit caches the cwnd value indirectly in cwnd_quota. When tcp_transmit_skb reduces the cwnd because of tcp_enter_cwr, the cached value becomes invalid. This patch ensures that the cwnd value is always reread after each tcp_transmit_skb call. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
MSS changes can be lost since we preemptively initialize the tso_segs count for an SKB before we %100 commit to sending it out. So, by the time we send it out, the tso_size information can be stale due to PMTU events. This mucks up all of the logic in our send engine, and can even result in the BUG() triggering in tcp_tso_should_defer(). Another problem we have is that we're storing the tp->mss_cache, not the SACK block normalized MSS, as the tso_size. That's wrong too. Signed-off-by:
-
John McCutchan authored
This avoids the whole #ifdef mess by just getting a copy of dentry->d_inode before d_delete is called - that makes the codepaths the same for the INOTIFY/DNOTIFY cases as for the regular no-notify case. I've been running this under a Gnome session for the last 10 minutes. Inotify is being used extensively. Signed-off-by:
John McCutchan <ttb@tentacle.dhs.org> Signed-off-by:
-
Olav Kongas authored
When recently addressing remarks by Alexey Dobriyan about the isp116x-hcd, I introduced a bug in the driver. Please apply the attached patch to fix it. Signed-off-by:
Olav Kongas <ok@artecdesign.ee> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
David Brownell authored
This patch has a one line oops fix, plus related cleanups. - The bugfix uses microframe scheduling data given to the hardware to test "is this a periodic QH", rather than testing for nonzero period. (Prevents an oops by providing the correct answer.) - The cleanup going along with the patch should make it clearer what's going on whenever those bitfields are accessed. The bug came about when, around January, two new kinds of EHCI interrupt scheduling operation were added, involving both the high speed (24 KBytes per millisec) and low/full speed (1-64 bytes per millisec) microframe scheduling. A driver for the Edirol UA-1000 Audio Capture Unit ran into the oops; it used one of the newly supported high speed modes. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Pete Zaitcev authored
The patch which went in was correct, but not quite what I had in mind. Here is a patch to update that a little bit. Original patch is at: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4749f32da939d4e4160541b2cadc22492bb507ecSigned-off-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Dominik Brodowski authored
In yenta_socket, we default to using the resource setting of the CardBus bridge. However, this is a PCI-bus-centric view of resources and thus needs to be converted to generic resources first. Therefore, add a call to pcibios_bus_to_resource() call in between. This function is a mere wrapper on x86 and friends, however on some others it already exists, is added in this patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where is its pcibios_resource_to_bus() ?). Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
John W. Linville authored
Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration (including BARs) when transitioning from D3hot->D0. This leaves such a device in an inaccessible state. The patch below causes the BARs to be restored when enabling such a device, so that its driver will be able to access it. The patch also adds pci_restore_bars as a new global symbol, and adds a correpsonding EXPORT_SYMBOL_GPL for that. Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a (re)boot. Most drivers call pci_enable_device very early, so devices left in D3hot that lose configuration during the D3hot->D0 transition will be inaccessible to their drivers. Drivers could be modified to account for this, but it would be difficult to know which drivers need modification. This is especially true since often many devices are covered by the same driver. It likely would be necessary to replicate code across dozens of drivers. The patch below should trigger only when transitioning from D3hot->D0 (or at boot), and only for devices that have the "no soft reset" bit cleared in the PM control register. I believe it is safe to include this patch as part of the PCI infrastructure. The cleanest implementation of pci_restore_bars was to call pci_update_resource. Unfortunately, that does not currently exist for the sparc64 architecture. The patch below includes a null implemenation of pci_update_resource for sparc64. Some have expressed interest in making general use of the the pci_restore_bars function, so that has been exported to GPL licensed modules. Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
- 04 Aug, 2005 16 commits
-
-
Andrew Morton authored
Revert this June 17 patch: it broke persistence of timers across execve(). Cc: Roland McGrath <roland@redhat.com> Cc: george anzinger <george@mvista.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Daniel Jacobowitz authored
The IA32 ptrace emulation currently returns the wrong registers for fs/gs; it's returning what x86_64 calls gs_base. We need regs.gsindex in order for GDB to correctly locate the TLS area. Without this patch, the 32-bit GDB testsuite bombs on a 64-bit kernel. With it, results look about like I'd expect, although there are still a handful of kernel-related failures (vsyscall related?). Signed-off-by:
Daniel Jacobowitz <dan@codesourcery.com> Acked-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Venkatesh Pallipadi authored
We had a user whose apps weren't working correctly because his "rtc" wasn't working fully. For the sake of simplicity, it seems sensible to always enable HPET RTC emulation. Remove a special config option for HPET_EMULATE_RTC and make it directly depend on HPET_TIMER and RTC. This will avoid the hangs when EMULATE_RTC is not configured and when some userlevel script depends on RTC interrupt, as in: http://bugzilla.kernel.org/show_bug.cgi?id=4904Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
-
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:
-
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:
Robert Love <rml@novell.com> Signed-off-by:
-
Robert Love authored
The inotify help text still refers to the character device. Update it. Fixes kernel bug #4993. Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
Jim Keniston authored
Acked-by:
Prasanna S Panchamukhi <prasanna@in.ibm.com> Signed-off-by:
Jim Keniston <jkenisto@us.ibm.com> Signed-off-by:
-
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:
-
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:
-
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:
-
