- 26 Nov, 2012 40 commits
-
-
Jan Kara authored
commit b9e06ef2 upstream. In reiserfs_quota_on() we do quite some work - for example unpacking tail of a quota file. Thus we have to hold write lock until a moment we call back into the quota code. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit 3bb3e1fc upstream. When remounting reiserfs dquot_suspend() or dquot_resume() can be called. These functions take dqonoff_mutex which ranks above write lock so we have to drop it before calling into quota code. Signed-off-by:
-
Bryan Schumaker authored
commit 399f11c3 upstream. Currently, we will schedule session recovery and then return to the caller of nfs4_handle_exception. This works for most cases, but causes a hang on the following test case: Client Server ------ ------ Open file over NFS v4.1 Write to file Expire client Try to lock file The server will return NFS4ERR_BADSESSION, prompting the client to schedule recovery. However, the client will continue placing lock attempts and the open recovery never seems to be scheduled. The simplest solution is to wait for session recovery to run before retrying the lock. Signed-off-by:
Bryan Schumaker <bjschuma@netapp.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Daniel Vetter authored
commit a9193983 upstream. The overlay on the i830M has a peculiar failure mode: It works the first time around after boot-up, but consistenly hangs the second time it's used. Chris Wilson has dug out a nice errata: "1.5.12 Clock Gating Disable for Display Register Address Offset: 06200h–06203h "Bit 3 Ovrunit Clock Gating Disable. 0 = Clock gating controlled by unit enabling logic 1 = Disable clock gating function DevALM Errata ALM049: Overlay Clock Gating Must be Disabled: Overlay & L2 Cache clock gating must be disabled in order to prevent device hangs when turning off overlay.SW must turn off Ovrunit clock gating (6200h) and L2 Cache clock gating (C8h)." Now I've nowhere found that 0xc8 register and hence couldn't apply the l2 cache workaround. But I've remembered that part of the magic that the OVERLAY_ON/OFF commands are supposed to do is to rearrange cache allocations so that the overlay scaler has some scratch space. And while pondering how that could explain the hang the 2nd time we enable the overlay, I've remembered that the old ums overlay code did _not_ issue the OVERLAY_OFF cmd. And indeed, disabling the OFF cmd results in the overlay working flawlessly, so I guess we can workaround the lack of the above workaround by simply never disabling the overlay engine once it's enabled. Note that we have the first part of the above w/a already implemented in i830_init_clock_gating - leave that as-is to avoid surprises. v2: Add a comment in the code. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47827Tested-by:
Rhys <rhyspuk@gmail.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: - Adjust context - s/intel_ring_emit(ring, /OUT_RING(/] Signed-off-by:
-
Martin Schwidefsky authored
commit fa968ee2 upstream. If user space is running in primary mode it can switch to secondary or access register mode, this is used e.g. in the clock_gettime code of the vdso. If a signal is delivered to the user space process while it has been running in access register mode the signal handler is executed in access register mode as well which will result in a crash most of the time. Set the address space control bits in the PSW to the default for the execution of the signal handler and make sure that the previous address space control is restored on signal return. Take care that user space can not switch to the kernel address space by modifying the registers in the signal frame. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Mirko Lindner authored
commit d663d181 upstream. Re-enable interrupts if it is not our interrupt Signed-off-by:
Mirko Lindner <mlindner@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Tim Sally authored
commit 5f5b331d upstream. The issue occurs when eCryptfs is mounted with a cipher supported by the crypto subsystem but not by eCryptfs. The mount succeeds and an error does not occur until a write. This change checks for eCryptfs cipher support at mount time. Resolves Launchpad issue #338914, reported by Tyler Hicks in 03/2009. https://bugs.launchpad.net/ecryptfs/+bug/338914Signed-off-by:
Tim Sally <tsally@atomicpeace.com> Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
-
Tyler Hicks authored
commit 069ddcda upstream. When the eCryptfs mount options do not include '-o acl', but the lower filesystem's mount options do include 'acl', the MS_POSIXACL flag is not flipped on in the eCryptfs super block flags. This flag is what the VFS checks in do_last() when deciding if the current umask should be applied to a newly created inode's mode or not. When a default POSIX ACL mask is set on a directory, the current umask is incorrectly applied to new inodes created in the directory. This patch ignores the MS_POSIXACL flag passed into ecryptfs_mount() and sets the flag on the eCryptfs super block depending on the flag's presence on the lower super block. Additionally, it is incorrect to allow a writeable eCryptfs mount on top of a read-only lower mount. This missing check did not allow writes to the read-only lower mount because permissions checks are still performed on the lower filesystem's objects but it is best to simply not allow a rw mount on top of ro mount. However, a ro eCryptfs mount on top of a rw mount is valid and still allowed. https://launchpad.net/bugs/1009207Signed-off-by:
Stefan Beller <stefanbeller@googlemail.com> Cc: John Johansen <john.johansen@canonical.com> Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
-
Jan Safrata authored
commit 0658a336 upstream. The use of kfree(serial) in error cases of usb_serial_probe was invalid - usb_serial structure allocated in create_serial() gets reference of usb_device that needs to be put, so we need to use usb_serial_put() instead of simple kfree(). Signed-off-by:
Jan Safrata <jan.nikitenko@gmail.com> Acked-by:
Johan Hovold <jhovold@gmail.com> Cc: Richard Retanubun <richardretanubun@ruggedcom.com> Signed-off-by:
-
Ulrich Weber authored
commit 38fe36a2 upstream. ICMP tuples have id in src and type/code in dst. So comparing src.u.all with dst.u.all will always fail here and ip_xfrm_me_harder() is called for every ICMP packet, even if there was no NAT. Signed-off-by:
Ulrich Weber <ulrich.weber@sophos.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Jozsef Kadlecsik authored
commit 64f509ce upstream. Clients should not send such packets. By accepting them, we open up a hole by wich ephemeral ports can be discovered in an off-path attack. See: "Reflection scan: an Off-Path Attack on TCP" by Jan Wrobel, http://arxiv.org/abs/1201.2074Signed-off-by:
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Signed-off-by:
-
Jozsef Kadlecsik authored
commit 4a70bbfa upstream. We spare nothing by not validating the sequence number of dataless ACK packets and enabling it makes harder off-path attacks. See: "Reflection scan: an Off-Path Attack on TCP" by Jan Wrobel, http://arxiv.org/abs/1201.2074Signed-off-by:
-
Nathan Walp authored
commit 0481776b upstream. RTL_GIGA_MAC_VER_35 includes no multicast hardware filter. Signed-off-by:
Nathan Walp <faceprint@faceprint.com> Suggested-by:
Hayes Wang <hayeswang@realtek.com> Acked-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Cyril Brulebois authored
commit b00e69de upstream. This regression was spotted between Debian squeeze and Debian wheezy kernels (respectively based on 2.6.32 and 3.2). More info about Wake-on-LAN issues with Realtek's 816x chipsets can be found in the following thread: http://marc.info/?t=132079219400004 Probable regression from d4ed95d7; more chipsets are likely affected. Tested on top of a 3.2.23 kernel. Reported-by:
Florent Fourcot <florent.fourcot@enst-bretagne.fr> Tested-by:
Cyril Brulebois <kibi@debian.org> Signed-off-by:
-
Mojiong Qiu authored
commit 772aebce upstream. exit_idle() should be called after irq_enter(), otherwise it throws: [ INFO: suspicious RCU usage. ] 3.6.5 #1 Not tainted ------------------------------- include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 1 RCU used illegally from extended quiescent state! 1 lock held by swapper/0/0: #0: (rcu_read_lock){......}, at: [<ffffffff810e9fe0>] __atomic_notifier_call_chain+0x0/0x140 stack backtrace: Pid: 0, comm: swapper/0 Not tainted 3.6.5 #1 Call Trace: <IRQ> [<ffffffff811259a2>] lockdep_rcu_suspicious+0xe2/0x130 [<ffffffff810ea10c>] __atomic_notifier_call_chain+0x12c/0x140 [<ffffffff810e9fe0>] ? atomic_notifier_chain_unregister+0x90/0x90 [<ffffffff811216cd>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff810ea136>] atomic_notifier_call_chain+0x16/0x20 [<ffffffff810777c3>] exit_idle+0x43/0x50 [<ffffffff81568865>] xen_evtchn_do_upcall+0x25/0x50 [<ffffffff81aa690e>] xen_do_hypervisor_callback+0x1e/0x30 <EOI> [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000 [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000 [<ffffffff81061540>] ? xen_safe_halt+0x10/0x20 [<ffffffff81075cfa>] ? default_idle+0xba/0x570 [<ffffffff810778af>] ? cpu_idle+0xdf/0x140 [<ffffffff81a4d881>] ? rest_init+0x135/0x144 [<ffffffff81a4d74c>] ? csum_partial_copy_generic+0x16c/0x16c [<ffffffff82520c45>] ? start_kernel+0x3db/0x3e8 [<ffffffff8252066a>] ? repair_env_string+0x5a/0x5a [<ffffffff82520356>] ? x86_64_start_reservations+0x131/0x135 [<ffffffff82524aca>] ? xen_start_kernel+0x465/0x46 Git commit 98ad1cc1 Author: Frederic Weisbecker <fweisbec@gmail.com> Date: Fri Oct 7 18:22:09 2011 +0200 x86: Call idle notifier after irq_enter() did this, but it missed the Xen code. Signed-off-by:
Mojiong Qiu <mjqiu@tencent.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Michal Schmidt authored
commit aee77e4a upstream. The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have a box where this prevents the interface from using the gigabit line to its full potential. This patch solves the problem by setting TX_DMA_BURST to unlimited. The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl (XID 0c900880). TSO is enabled. I used netperf (TCP_STREAM test) to measure the dependency of TX throughput on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024, '7'=unlimited). This chart shows the results: http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png Interesting points: - With the current DMA burst limit (1024): - at the default MTU=1500 I get only 842 Mbit/s. - when going from small MTU, the performance rises monotonically with increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's a sudden drop to 762 MBit/s from which the throughput rises monotonically again with further MTU increases. - With a smaller DMA burst limit (512): - there's a similar peak at MTU=1076 and another one at MTU=564. - With unlimited DMA burst: - at the default MTU=1500 I get nice 940 Mbit/s. - the throughput rises monotonically with increasing MTU with no strange peaks. Notice that the peaks occur at MTU sizes that are multiples of the DMA burst limit plus 52. Why 52? Because: 20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52 The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too, except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes. CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B", i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs the smaller burst limit, or if any other versions have similar requirements. Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Acked-by:
-
Hugh Dickins authored
commit 0f3c42f5 upstream. Under a particular load on one machine, I have hit shmem_evict_inode()'s BUG_ON(inode->i_blocks), enough times to narrow it down to a particular race between swapout and eviction. It comes from the "if (freed > 0)" asymmetry in shmem_recalc_inode(), and the lack of coherent locking between mapping's nrpages and shmem's swapped count. There's a window in shmem_writepage(), between lowering nrpages in shmem_delete_from_page_cache() and then raising swapped count, when the freed count appears to be +1 when it should be 0, and then the asymmetry stops it from being corrected with -1 before hitting the BUG. One answer is coherent locking: using tree_lock throughout, without info->lock; reasonable, but the raw_spin_lock in percpu_counter_add() on used_blocks makes that messier than expected. Another answer may be a further effort to eliminate the weird shmem_recalc_inode() altogether, but previous attempts at that failed. So far undecided, but for now change the BUG_ON to WARN_ON: in usual circumstances it remains a useful consistency check. Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Tom Herbert authored
[ Upstream commit baefa31d ] In commit c445477d which adds aRFS to the kernel, the CPU selected for RFS is not set correctly when CPU is changing. This is causing OOO packets and probably other issues. Signed-off-by:
Tom Herbert <therbert@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
-
Jiri Pirko authored
[ Upstream commit a652208e ] Check (ha->addr == dev->dev_addr) is always true because dev_addr_init() sets this. Correct the check to behave properly on addr removal. Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Hannes Frederic Sowa authored
[ Upstream commit d4596bad ] Cc: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Xi Wang authored
[ Upstream commit 0c9f79be ] (1<<optname) is undefined behavior in C with a negative optname or optname larger than 31. In those cases the result of the shift is not necessarily zero (e.g., on x86). This patch simplifies the code with a switch statement on optname. It also allows the compiler to generate better code (e.g., using a 64-bit mask). Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
-
Andreas Schwab authored
commit 34fa78b5 upstream. The sigaddset/sigdelset/sigismember functions that are implemented with bitfield insn cannot allow the sigset argument to be placed in a data register since the sigset is wider than 32 bits. Remove the "d" constraint from the asm statements. The effect of the bug is that sending RT signals does not work, the signal number is truncated modulo 32. Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Johannes Berg authored
commit 43c771a1 upstream. When in world roaming mode, allow 40 MHz to be used on channels 12 and 13 so that an AP that is, e.g., using HT40+ on channel 9 (in the UK) can be used. Reported-by:
Eddie Chapman <eddie@ehuk.net> Tested-by:
Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Michal Hocko authored
commit 9a5a8f19 upstream. oom_badness() takes a totalpages argument which says how many pages are available and it uses it as a base for the score calculation. The value is calculated by mem_cgroup_get_limit which considers both limit and total_swap_pages (resp. memsw portion of it). This is usually correct but since fe35004f ("mm: avoid swapping out with swappiness==0") we do not swap when swappiness is 0 which means that we cannot really use up all the totalpages pages. This in turn confuses oom score calculation if the memcg limit is much smaller than the available swap because the used memory (capped by the limit) is negligible comparing to totalpages so the resulting score is too small if adj!=0 (typically task with CAP_SYS_ADMIN or non zero oom_score_adj). A wrong process might be selected as result. The problem can be worked around by checking mem_cgroup_swappiness==0 and not considering swap at all in such a case. Signed-off-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
David Rientjes <rientjes@google.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Zhao Yakui authored
commit ac207ed2 upstream. The TTM page can be allocated from high memory. In such case it is wrong to use the page_address(page) as the virtual address for the high memory page. bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50241Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit b9196395 upstream. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=50431Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Dan Williams authored
commit c0bc3098 upstream. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Dan Williams authored
commit fcb21645 upstream. The Dell 5800 appears to be a simple rebrand of the Novatel E362. Signed-off-by:
-
Heiko Carstens authored
commit d55c4c61 upstream. When walking page tables we need to make sure that everything is within bounds of the ASCE limit of the task's address space. Otherwise we might calculate e.g. a pud pointer which is not within a pud and dereference it. So check against TASK_SIZE (which is the ASCE limit) before walking page tables. Reviewed-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Colin Cross authored
commit d38e0e3f upstream. Commit 6bd4a5d9 changed the ANDROID_ALARM_GET_TIME ioctls from IOW to IOR. While technically correct, the _IOC_DIR bits are ignored by alarm_ioctl, so the commit breaks a userspace ABI used by all existing Android devices for a purely cosmetic reason. Revert it. Cc: Dae S. Kim <dae@velatum.com> Signed-off-by:
Colin Cross <ccross@android.com> Signed-off-by:
-
Artem Bityutskiy authored
commit 98a1eebd upstream. This commit is a preparation for a subsequent bugfix. We introduce a counter for categorized lprops. Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
-
Artem Bityutskiy authored
commit a28ad42a upstream. This is a bugfix for a problem with the following symptoms: 1. A power cut happens 2. After reboot, we try to mount UBIFS 3. Mount fails with "No space left on device" error message UBIFS complains like this: UBIFS error (pid 28225): grab_empty_leb: could not find an empty LEB The root cause of this problem is that when we mount, not all LEBs are categorized. Only those which were read are. However, the 'ubifs_find_free_leb_for_idx()' function assumes that all LEBs were categorized and 'c->freeable_cnt' is valid, which is a false assumption. This patch fixes the problem by teaching 'ubifs_find_free_leb_for_idx()' to always fall back to LPT scanning if no freeable LEBs were found. This problem was reported by few people in the past, but Brent Taylor was able to reproduce it and send me a flash image which cannot be mounted, which made it easy to hunt the bug. Kudos to Brent. Reported-by:
Brent Taylor <motobud@gmail.com> Signed-off-by:
-
Misael Lopez Cruz authored
commit 445632ad upstream. DAPM shutdown incorrectly uses "list" field of codec struct while iterating over probed components (codec_dev_list). "list" field refers to codecs registered in the system, "card_list" field is used for probed components. Signed-off-by:
Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Eric Millbrandt authored
commit 55c6f4cb upstream. When MCLK is supplied externally and BCLK and LRC are configured as outputs (codec is master), the PLL values are only calculated correctly on the first transmission. On subsequent transmissions, at differenct sample rates, the wrong PLL values are used. Test for f_opclk instead of f_pllout to determine if the PLL values are needed. Signed-off-by:
Eric Millbrandt <emillbrandt@dekaresearch.com> Signed-off-by:
-
Takashi Iwai authored
commit 05193639 upstream. This is another variant of iMac 9,1 with a different codec SSID. Reported-and-tested-by:
Everaldo Canuto <everaldo.canuto@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kailang Yang authored
commit 19a62823 upstream. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
-
Takashi Iwai authored
commit ef4da458 upstream. VT1802 codec provides the invalid connection lists of NID 0x24 and 0x33 containing the routes to a non-exist widget 0x3e. This confuses the auto-parser. Fix it up in the driver by overriding these connections. Reported-by:
Massimo Del Fedele <max@veneto.com> Signed-off-by:
-
Takashi Iwai authored
commit 5b376195 upstream. In via_auto_fill_adc_nids(), the parser tries to fill dac_nids[] at the point of the current line-out (i). When no valid path is found for this output, this results in dac = 0, thus it creates a hole in dac_nids[]. This confuses is_empty_dac() and trims the detected DAC in later reference. This patch fixes the bug by appending DAC properly to dac_nids[] in via_auto_fill_adc_nids(). Reported-by:
-
Takashi Iwai authored
commit ae24c319 upstream. Several bug reports suggest that the forcibly resetting IEC958 status bits is required for AD codecs to get the SPDIF output working properly after changing streams. Original fix credit to Javeed Shaikh. BugLink: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/359361Reported-by:
Robin Kreis <r.kreis@uni-bremen.de> Signed-off-by:
-
Daniel J Blueman authored
commit 16337e02 upstream. Correctly enable the digital microphones with the right bits in the right coeffecient registers on Cirrus CS4206/7 codecs. It also prevents misconfiguring ADC1/2. This fixes the digital mic on the Macbook Pro 10,1/Retina. Based-on-patch-by:
Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by:
Daniel J Blueman <daniel@quora.org> Signed-off-by:
-
