- 26 Apr, 2010 40 commits
-
-
Mathieu Desnoyers authored
The __module_ref_addr() problem disappears in 2.6.34-rc kernels because these percpu accesses were re-factored. __module_ref_addr() should use per_cpu_ptr() to obfuscate the pointer (RELOC_HIDE is needed for per cpu pointers). This non-standard per-cpu pointer use has been introduced by commit 720eba31 It causes a NULL pointer exception on some configurations when CONFIG_TRACING is enabled on 2.6.33. This patch fixes the problem (acknowledged by Randy who reported the bug). It did not appear to hurt previously because most of the accesses were done through local_inc, which probably obfuscated the access enough that no compiler optimizations were done. But with local_read() done when CONFIG_TRACING is active, this becomes a problem. Non-CONFIG_TRACING is probably affected as well (module.c contains local_set and local_read that use __module_ref_addr()), but I guess nobody noticed because we've been lucky enough that the compiler did not generate the inappropriate optimization pattern there. This patch should be queued for the 2.6.29.x through 2.6.33.x stable branches. (tested on 2.6.33.1 x86_64) Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Tested-by:
Randy Dunlap <randy.dunlap@oracle.com> CC: Eric Dumazet <dada1@cosmosbay.com> CC: Rusty Russell <rusty@rustcorp.com.au> CC: Peter Zijlstra <a.p.zijlstra@chello.nl> CC: Tejun Heo <tj@kernel.org> CC: Ingo Molnar <mingo@elte.hu> CC: Andrew Morton <akpm@linux-foundation.org> CC: Linus Torvalds <torvalds@linux-foundation.org> CC: Greg Kroah-Hartman <gregkh@suse.de> CC: Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mathieu Desnoyers authored
The mainline kernel as of 2.6.34-rc5 is not affected by this problem because commit 10fad5e4 fixed it by refactoring. lockdep fix incorrect percpu usage Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed for per cpu pointers). git blame points to commit: lockdep.c: commit 8e18257d But it's really just moving the code around. But it's enough to say that the problems appeared before Jul 19 01:48:54 2007, which brings us back to 2.6.23. It should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these stable branches are still maintained). (tested on 2.6.33.1 x86_64) Signed-off-by:
-
Mathieu Desnoyers authored
Mainline does not need this fix, as commit 259354de fixed the problem by refactoring. Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed for per cpu pointers). Introduced by commit: module.c: commit 6b588c18 This patch should be queued for the stable branch, for kernels 2.6.29.x to 2.6.33.x. (tested on 2.6.33.1 x86_64) Signed-off-by:
-
Ping Cheng authored
commit 014f6150 upstream. When Wacom devices wake up from a sleep, the switch mode command (wacom_query_tablet_data) is needed before wacom_open is called. wacom_query_tablet_data should not be executed inside wacom_open since wacom_open is called more than once during probe. Reported-and-tested-by:
Anton Anikin <Anton@Anikin.name> Signed-off-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Alexey Starikovskiy authored
commit 2060c445 upstream. access_bit_width field is u8 in ACPICA, thus 256 value written to it becomes 0, causing divide by zero later. Proper fix would be to remove access_bit_width at all, just because we already have access_byte_width, which is access_bit_width / 8. Limit access width to 64 bit for now. https://bugzilla.kernel.org/show_bug.cgi?id=15749 fixes regression caused by the fix for: https://bugzilla.kernel.org/show_bug.cgi?id=14667Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Alexey Starikovskiy authored
commit dadf28a1 upstream http://bugzilla.kernel.org/show_bug.cgi?id=14667 [bwh: Backport to 2.6.32; same applies to 2.6.33] Signed-off-by:
-
Peter Zijlstra authored
original patch commit ids: 452a339a and 134fbadf perf_events, x86: Implement Intel Westmere support The new Intel documentation includes Westmere arch specific event maps that are significantly different from the Nehalem ones. Add support for this generation. Found the CPUID model numbers on wikipedia. Also ammend some Nehalem constraints, spotted those when looking for the differences between Nehalem and Westmere. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Stephane Eranian <eranian@google.com> LKML-Reference: <20100127221122.151865645@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> perf, x86: Enable Nehalem-EX support According to Intel Software Devel Manual Volume 3B, the Nehalem-EX PMU is just like regular Nehalem (except for the uncore support, which is completely different). Signed-off-by:
Vince Weaver <vweaver1@eecs.utk.edu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Lin Ming <ming.m.lin@intel.com> LKML-Reference: <alpine.DEB.2.00.1004060956580.1417@cl320.eecs.utk.edu> Signed-off-by:
-
Damian Lukowski authored
commit 59885640 upstream. Make sure, that TCP has a nonzero RTT estimation after three-way handshake. Currently, a listening TCP has a value of 0 for srtt, rttvar and rto right after the three-way handshake is completed with TCP timestamps disabled. This will lead to corrupt RTO recalculation and retransmission flood when RTO is recalculated on backoff reversion as introduced in "Revert RTO on ICMP destination unreachable" (f1ecd5d9). This behaviour can be provoked by connecting to a server which "responds first" (like SMTP) and rejecting every packet after the handshake with dest-unreachable, which will lead to softirq load on the server (up to 30% per socket in some tests). Thanks to Ilpo Jarvinen for providing debug patches and to Denys Fedoryshchenko for reporting and testing. Changes since v3: Removed bad characters in patchfile. Reported-by:
Denys Fedoryshchenko <denys@visp.net.lb> Signed-off-by:
Damian Lukowski <damian@tvk.rwth-aachen.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Neil Horman authored
commit c0cd884a upstream. Official patch to fix the r8169 frame length check error. Based on this initial thread: http://marc.info/?l=linux-netdev&m=126202972828626&w=1 This is the official patch to fix the frame length problems in the r8169 driver. As noted in the previous thread, while this patch incurs a performance hit on the driver, its possible to improve performance dynamically by updating the mtu and rx_copybreak values at runtime to return performance to what it was for those NICS which are unaffected by the ideosyncracy (if there are any). Summary: A while back Eric submitted a patch for r8169 in which the proper allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too much data. This was done in commit fdd7b4c3. A long time prior to that however, Francois posted 126fa4b9, which expiclitly disabled the MaxSize setting due to the fact that the hardware behaved in odd ways when overlong frames were received on NIC's supported by this driver. This was mentioned in a security conference recently: http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html It seems that if we can't enable frame size filtering, then, as Eric correctly noticed, we can find ourselves DMA-ing too much data to a buffer, causing corruption. As a result is seems that we are forced to allocate a frame which is ready to handle a maximally sized receive. This obviously has performance issues with it, so to mitigate that issue, this patch does two things: 1) Raises the copybreak value to the frame allocation size, which should force appropriately sized packets to get allocated on rx, rather than a full new 16k buffer. 2) This patch only disables frame filtering initially (i.e., during the NIC open), changing the MTU results in ring buffer allocation of a size in relation to the new mtu (along with a warning indicating that this is dangerous). Because of item (2), individuals who can't cope with the performance hit (or can otherwise filter frames to prevent the bug), or who have hardware they are sure is unaffected by this issue, can manually lower the copybreak and reset the mtu such that performance is restored easily. Signed-off-by:
Neil Horman <nhorman@redhat.com> Signed-off-by:
-
Terry Loftin authored
commit dac87619 upstream. Tx ring buffers after tx_ring->next_to_use are volatile and could change, possibly causing a crash. Stop cleaning when we hit tx_ring->next_to_use. Signed-off-by:
Terry Loftin <terry.loftin@hp.com> Acked-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Reinette Chatre authored
commit bbcbb9ef upstream. There is a problem if an "internal short scan" is in progress when a mac80211 requested scan arrives. If this new scan request arrives within the "next_scan_jiffies" period then driver will immediately return success and complete the scan. The problem here is that the scan has not been fully initialized at this time (is_internal_short_scan is still set to true because of the currently running scan), which results in the scan completion never to be sent to mac80211. At this time also, evan though the internal short scan is still running the state (is_internal_short_scan) will be set to false, so when the internal scan does complete then mac80211 will receive a scan completion. Fix this by checking right away if a scan is in progress when a scan request arrives from mac80211. Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Wey-Yi Guy authored
commit dff010ac upstream. Reset and clear all the tx queues when finished downloading runtime uCode and ready to go into operation mode. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Oliver Neukum authored
commit f0730924 upstream. Stupid logic bug passing a just nulled pointer Signed-off-by:
Oliver Neukum <neukum@b1-systems.de> Signed-off-by:
-
Oliver Neukum authored
commit 97d35f95 upstream. Update cdc-acm to the async methods eliminating the workqueue [This fixes a reported lockup for the cdc-acm driver - gregkh] Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
John Wright authored
Based on commit e2912009 upstream, but done differently as this issue is not present in .33 or .34 kernels due to rework in this area. If a task is in the TASK_WAITING state, then try_to_wake_up() is working on it, and it will place it on the correct cpu. This commit ensures that neither migrate_task() nor __migrate_task() calls set_task_cpu(p) while p is in the TASK_WAKING state. Otherwise, there could be two concurrent calls to set_task_cpu(p), resulting in the task's cfs_rq being inconsistent with its cpu. Signed-off-by:
John Wright <john.wright@hp.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Christian Pulvermacher authored
commit cfce08c6 upstream. If the lower file system driver has extended attributes disabled, ecryptfs' own access functions return -ENOSYS instead of -EOPNOTSUPP. This breaks execution of programs in the ecryptfs mount, since the kernel expects the latter error when checking for security capabilities in xattrs. Signed-off-by:
Christian Pulvermacher <pulvermacher@gmx.de> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by:
-
Tyler Hicks authored
commit 3a60a168 upstream. Create a getattr handler for eCryptfs symlinks that is capable of reading the lower target and decrypting its path. Prior to this patch, a stat's st_size field would represent the strlen of the encrypted path, while readlink() would return the strlen of the decrypted path. This could lead to confusion in some userspace applications, since the two values should be equal. https://bugs.launchpad.net/bugs/524919Reported-by:
Loïc Minier <loic.minier@canonical.com> Signed-off-by:
-
Jeff Mahoney authored
commit 133b8f9d upstream. Since tmpfs has no persistent storage, it pins all its dentries in memory so they have d_count=1 when other file systems would have d_count=0. ->lookup is only used to create new dentries. If the caller doesn't instantiate it, it's freed immediately at dput(). ->readdir reads directly from the dcache and depends on the dentries being hashed. When an ecryptfs mount is mounted, it associates the lower file and dentry with the ecryptfs files as they're accessed. When it's umounted and destroys all the in-memory ecryptfs inodes, it fput's the lower_files and d_drop's the lower_dentries. Commit 4981e081 added this and a d_delete in 2008 and several months later commit caeeeecf removed the d_delete. I believe the d_drop() needs to be removed as well. The d_drop effectively hides any file that has been accessed via ecryptfs from the underlying tmpfs since it depends on it being hashed for it to be accessible. I've removed the d_drop on my development node and see no ill effects with basic testing on both tmpfs and persistent storage. As a side effect, after ecryptfs d_drops the dentries on tmpfs, tmpfs BUGs on umount. This is due to the dentries being unhashed. tmpfs->kill_sb is kill_litter_super which calls d_genocide to drop the reference pinning the dentry. It skips unhashed and negative dentries, but shrink_dcache_for_umount_subtree doesn't. Since those dentries still have an elevated d_count, we get a BUG(). This patch removes the d_drop call and fixes both issues. This issue was reported at: https://bugzilla.novell.com/show_bug.cgi?id=567887Reported-by:
Árpád Bíró <biroa@demasz.hu> Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Cc: Dustin Kirkland <kirkland@canonical.com> Signed-off-by:
-
Michael Buesch authored
commit 88499ab3 upstream. This optimizes the PIO scratchbuffer usage. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Bjorn Helgaas authored
commit 67fe63b0 upstream. Commit 15b8dd53 changed the string in info->hardware_id from a static array to a pointer and added a length field. But instead of changing "sizeof(array)" to "length", we changed it to "sizeof(length)" (== 4), which corrupts the string we're trying to null-terminate. We no longer even need to null-terminate the string, but we *do* need to check whether we found a HID. If there's no HID, we used to have an empty array, but now we have a null pointer. The combination of these defects causes this oops: Unable to handle kernel NULL pointer dereference (address 0000000000000003) modprobe[895]: Oops 8804682956800 [1] ip is at zx1_gart_probe+0xd0/0xcc0 [hp_agp] http://marc.info/?l=linux-ia64&m=126264484923647&w=2Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Reported-by:
Émeric Maschino <emeric.maschino@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Takashi Iwai authored
commit 8815cd03 upstream. The Biostar mobo seems to give a wrong DMA position, resulting in stuttering or skipping sounds on 2.6.34. Since the commit 7b3a177b, "ALSA: pcm_lib: fix "something must be really wrong" condition", makes the position check more strictly, the DMA position problem is revealed more clearly now. The fix is to use only LPIB for obtaining the position, i.e. passing position_fix=1. This patch adds a static quirk to achieve it as default. Reported-by:
Frank Griffin <ftg@roadrunner.com> Cc: Eric Piel <Eric.Piel@tremplin-utc.net> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Linus Torvalds authored
commit 9e3bd919 upstream. This makes the b43 driver just automatically fall back to PIO mode when DMA doesn't work. The driver already told the user to do it, so rather than have the user reload the module with a new flag, just make the driver do it automatically. We keep the message as an indication that something is wrong, but now just automatically fall back to the hopefully working PIO case. (Some post-2.6.33 merge fixups by Larry Finger <Larry.Finger@lwfinger.net> and yours truly... -- JWL) Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Larry Finger authored
commit b02914af upstream. If userencounter the "Fatal DMA Problem" with a BCM43XX device, and still wish to use b43 as the driver, their only option is to rebuild the kernel with CONFIG_B43_FORCE_PIO. This patch removes this option and allows PIO mode to be selected with a load-time parameter for the module. Note that the configuration variable CONFIG_B43_PIO is also removed. Once the DMA problem with the BCM4312 devices is solved, this patch will likely be reverted. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Tested-by:
John Daiker <daikerjohn@gmail.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Larry Finger authored
commit 214ac9a4 upstream. As shown in Kernel Bugzilla #14761, doing a controller restart after a fatal DMA error does not accomplish anything other than consume the CPU on an affected system. Accordingly, substitute a meaningful message for the restart. Signed-off-by:
-
Seth Heasley authored
commit 39376434 upstream. Add the Intel Cougar Point (PCH) SMBus controller device IDs. Signed-off-by:
Seth Heasley <seth.heasley@intel.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Seth Heasley authored
commit 5623cab8 upstream. Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Seth Heasley authored
commit 88e8201e upstream. Signed-off-by:
-
Seth Heasley authored
commit 32679f95 upstream. This patch enables snoop, eliminating static during playback. This patch supersedes the previous Cougar Point audio patch. Signed-off-by:
-
Seth Heasley authored
commit d2f2fcd2 upstream. This patch adds the Intel Cougar Point (PCH) HD Audio Controller DeviceIDs. Signed-off-by:
-
Seth Heasley authored
commit 93da6202 upstream. This patch adds the Intel Cougar Point (PCH) LPC and SMBus Controller DeviceIDs. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Eli Cohen authored
commit f0dc117a upstream. The IPoIB UD QP reports send completions to priv->send_cq, which is usually left unarmed; it only gets armed when the number of outstanding send requests reaches the size of the TX queue. This arming is done only in the send path for the UD QP. However, when sending CM packets, the net queue may be stopped for the same reasons but no measures are taken to recover the UD path from a lockup. Consider this scenario: a host sends high rate of both CM and UD packets, with a TX queue length of N. If at some time the number of outstanding UD packets is more than N/2 and the overall outstanding packets is N-1, and CM sends a packet (making the number of outstanding sends equal N), the TX queue will be stopped. When all the CM packets complete, the number of outstanding packets will still be higher than N/2 so the TX queue will not be restarted. Fix this by calling ib_req_notify_cq() when the queue is stopped in the CM path. Signed-off-by:
Eli Cohen <eli@mellanox.co.il> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Andrew Patterson authored
commit bd1f46de upstream. The aer_inject module hangs in aer_inject() when checking the device's error masks. The hang is due to a recursive use of the aer_inject lock. The aer_inject() routine grabs the lock while processing the error and then calls pci_read_config_dword to read the masks. The pci_read_config_dword routine is earlier overridden by pci_read_aer, which among other things, grabs the aer_inject lock. Fixed by moving the pci_read_config_dword calls to read the masks to before the lock is taken. Acked-by:
Huang Ying <ying.huang@intel.com> Signed-off-by:
Andrew Patterson <andrew.patterson@hp.com> Signed-off-by:
-
Paul Mundt authored
commit ded1d8f2 upstream. When pci_register_set_vga_state() was made __init, the EXPORT_SYMBOL() was retained, which now leaves us with a section mismatch. Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Cc: Mike Travis <travis@sgi.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Mike Travis authored
commit 95a8b6ef upstream. Update pci_set_vga_state to call arch dependent functions to enable Legacy VGA I/O transactions to be redirected to correct target. [akpm@linux-foundation.org: make pci_register_set_vga_state() __init] Signed-off-by:
Mike Travis <travis@sgi.com> LKML-Reference: <201002022238.o12McE1J018723@imap1.linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Robin Holt <holt@sgi.com> Cc: Jack Steiner <steiner@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: David Airlie <airlied@linux.ie> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Harish Zunjarrao authored
commit eda05a28 upstream. The 32bit kernel does not add padding bytes in the fc_bsg_request structure whereas the 64bit kernel adds padding bytes in the fc_bsg_request structure. Due to this, structure elements gets mismatched with 32bit application and 64bit kernel.To resolve this, used packed modifier to avoid adding padding bytes. Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Mike Travis authored
commit 773a38db upstream. Update the VGA Arbiter to accept PCI Domains other than 0. Signed-off-by:
-
Youquan Song authored
commit b49bfd32 upstream. The Correcteable/Uncorrectable Error Mask Registers are used by PCIe AER driver which will controls the reporting of individual errors to PCIe RC via PCIe error messages. If hardware masks special error reporting to RC, the aer_inject driver should not inject aer error. Acked-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Youquan Song <youquan.song@intel.com> Acked-by:
-
Alexander Duyck authored
commit 747d49ba upstream. This patch adds the device ID necessary to support the 82576NS SerDes adapter. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
Mike Christie authored
commit 3f9daedf upstream. The scsi ioctl code path was missing scsi target reset support. This patch just adds it. Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Mike Christie authored
commit 2bc1c59d upstream. If the port state is blocked and the fast io fail tmo has fired then this patch will fail bsg requests immediately. This is needed if userspace is sending IOs to test the transport like with fcping, so it will not have to wait for the dev loss tmo. With this patch he bsg req fast io fail code behaves like the normal and sg io/passthrough fast io fail. Signed-off-by:
James Smart <james.smart@emulex.com> Signed-off-by:
-
