- 26 Apr, 2010 40 commits
-
-
Eric Sandeen authored
commit a1de02dc upstream. The "offset" member in ext4_io_end holds bytes, not blocks, so ext4_lblk_t is wrong - and too small (u32). This caused the async i/o writes to sparse files beyond 4GB to fail when they wrapped around to 0. Also fix up the type of arguments to ext4_convert_unwritten_extents(), it gets ssize_t from ext4_end_aio_dio_nolock() and ext4_ext_direct_IO(). Reported-by:
Giel de Nijs <giel@vectorwise.com> Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Eric Sandeen authored
commit c8afb446 upstream. Creating many small files in rapid succession on a small filesystem can lead to spurious ENOSPC; on a 104MB filesystem: for i in `seq 1 22500`; do echo -n > $SCRATCH_MNT/$i echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i done leads to ENOSPC even though after a sync, 40% of the fs is free again. This is because we reserve worst-case metadata for delalloc writes, and when data is allocated that worst-case reservation is not usually needed. When freespace is low, kicking off an async writeback will start converting that worst-case space usage into something more realistic, almost always freeing up space to continue. This resolves the testcase for me, and survives all 4 generic ENOSPC tests in xfstests. We'll still need a hard synchronous sync to squeeze out the last bit, but this fixes things up to a large degree. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Eric Sandeen authored
commit 17bd55d0 upstream. ext4, at least, would like to start pushing on writeback if it starts to get close to ENOSPC when reserving worst-case blocks for delalloc writes. Writing out delalloc data will convert those worst-case predictions into usually smaller actual usage, freeing up space before we hit ENOSPC based on this speculation. Thanks to Jens for the suggestion for the helper function, & the naming help. I've made the helper return status on whether writeback was started even though I don't plan to use it in the ext4 patch; it seems like it would be potentially useful to test this in some cases. Signed-off-by:
Jan Kara <jack@suse.cz> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Johannes Berg authored
commit c0ce77b8 upstream. Reinette found the reason for the warnings that happened occasionally when a hw-offloaded scan finished; her description of the problem: mac80211 will defer the handling of scan requests if it is busy with management work at the time. The scan requests are deferred and run after the work has completed. When this occurs there are currently two problems. * The scan request for hardware scan is not fully populated with the band and channels to scan not initialized. * When the scan is queued the state is not correctly updated to reflect that a scan is in progress. The problem here is that when the driver completes the scan and calls ieee80211_scan_completed() a warning will be triggered since mac80211 was not aware that a scan was in progress. The reason is that the queued scan work will start the hw scan right away when the hw_scan_req struct has already been allocated. However, in the first pass it will not have been filled, which happens at the same time as setting the bits. To fix this, simply move the allocation after the pending work test as well, so that the first iteration of the scan work will call __ieee80211_start_scan() even in the hardware scan case. Bug-identified-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Chase Douglas <chase.douglas@canonical.com> Signed-off-by:
-
Daniel T Chen authored
commit e2595322 upstream. BugLink: https://bugs.launchpad.net/bugs/479373 The OR has verified with hda-verb that the internal microphone needs VREF50 set for audible capture. Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Neil Brown authored
commit 301e99ce upstream. One the changes in commit d7979ae4 "svc: Move close processing to a single place" is: err_delete: - svc_delete_socket(svsk); + set_bit(SK_CLOSE, &svsk->sk_flags); return -EAGAIN; This is insufficient. The recvfrom methods must always call svc_xprt_received on completion so that the socket gets re-queued if there is any more work to do. This particular path did not make that call because it actually destroyed the svsk, making requeue pointless. When the svc_delete_socket was change to just set a bit, we should have added a call to svc_xprt_received, This is the problem that b0401d72 attempted to fix, incorrectly. Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
J. Bruce Fields authored
commit 1b644b6e upstream. This reverts commit b0401d72, which moved svc_delete_xprt() outside of XPT_BUSY, and allowed it to be called after svc_xpt_recived(), removing its last reference and destroying it after it had already been queued for future processing. Signed-off-by:
-
J. Bruce Fields authored
commit f5822754 upstream. This reverts commit b292cf9c. The commit that it attempted to patch up, b0401d72, was fundamentally wrong, and will also be reverted. Signed-off-by:
-
J. Bruce Fields authored
commit dc83d6e2 upstream. For nfsd we provide users the option of mapping uid's to server-side supplementary group lists. That makes sense for nfsd, but not necessarily for other rpc users (such as the callback client). So move that lookup to svcauth_unix_set_client, which is a program-specific method. Signed-off-by:
-
NeilBrown authored
commit 627a2d3c upstream. If a component device has a merge_bvec_fn then as we never call it we must ensure we never need to. Currently this is done by setting max_sector to 1 PAGE, however this does not stop a bio being created with several sub-page iovecs that would violate the merge_bvec_fn. So instead set max_phys_segments to 1 and set the segment boundary to the same as a page boundary to ensure there is only ever one single-page segment of IO requested at a time. This can particularly be an issue when 'xen' is used as it is known to submit multiple small buffers in a single bio. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
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:
-
