- 06 Jan, 2012 40 commits
-
-
Christoph Hellwig authored
Commit be4f1ac8 upstream. Since Linux 2.6.36 the writeback code has introduces various measures for live lock prevention during sync(). Unfortunately some of these are actively harmful for the XFS model, where the inode gets marked dirty for metadata from the data I/O handler. The older_than_this checks that are now more strictly enforced since writeback: avoid livelocking WB_SYNC_ALL writeback by only calling into __writeback_inodes_sb and thus only sampling the current cut off time once. But on a slow enough devices the previous asynchronous sync pass might not have fully completed yet, and thus XFS might mark metadata dirty only after that sampling of the cut off time for the blocking pass already happened. I have not myself reproduced this myself on a real system, but by introducing artificial delay into the XFS I/O completion workqueues it can be reproduced easily. Fix this by iterating over all XFS inodes in ->sync_fs and log all that are dirty. This might log inode that only got redirtied after the previous pass, but given how cheap delayed logging of inodes is it isn't a major concern for performance. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Tested-by:
Mark Tinguely <tinguely@sgi.com> Reviewed-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Christoph Hellwig authored
Commit 0b8fd303 upstream. If the writeback code writes back an inode because it has expired we currently use the non-blockin ->write_inode path. This means any inode that is pinned is skipped. With delayed logging and a workload that has very little log traffic otherwise it is very likely that an inode that gets constantly written to is always pinned, and thus we keep refusing to write it. The VM writeback code at that point redirties it and doesn't try to write it again for another 30 seconds. This means under certain scenarious time based metadata writeback never happens. Fix this by calling into xfs_log_inode for kupdate in addition to data integrity syncs, and thus transfer the inode to the log ASAP. Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit 63a74175 upstream. This fixes an odd bug found on a Dell PowerEdge 1850/0RC130 (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask would fail with: ata_piix 0000:00:1f.1: enabling device (0005 -> 0007) ata_piix 0000:00:1f.1: can't derive routing for PCI INT A ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO The issue was the Xen-SWIOTLB was allocated such as that the end of buffer was stradling a page (and also above 4GB). The fix was spotted by Kalev Leonid which was to piggyback on git commit e79f86b2 "swiotlb: Use page alignment for early buffer allocation" which: We could call free_bootmem_late() if swiotlb is not used, and it will shrink to page alignment. So alloc them with page alignment at first, to avoid lose two pages And doing that fixes the outstanding issue. Suggested-by:
"Kalev, Leonid" <Leonid.Kalev@ca.com> Reported-and-Tested-by:
"Taylor, Neal E" <Neal.Taylor@ca.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Kyle Manna authored
commit 3d6271f9 upstream. Without turning the MADC clock on, no MADC conversions occur. $ cat /sys/class/hwmon/hwmon0/device/in8_input [ 53.428436] twl4030_madc twl4030_madc: conversion timeout! cat: read error: Resource temporarily unavailable Signed-off-by:
Kyle Manna <kyle@kylemanna.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Kyle Manna authored
commit d0e84cae upstream. If the twl4030-madc device wasn't registered, and another device, such as twl4030-madc-hwmon, calls twl4030_madc_conversion() a NULL pointer is dereferenced. Signed-off-by:
-
Kyle Manna authored
commit 66cc5b8e upstream. Worst case this fixes the following error: [ 72.086212] (NULL device *): conversion timeout! Best case it prevents a crash Signed-off-by:
-
Sanjeev Premi authored
commit e178ccb3 upstream. A mutex is locked on entry into twl4030_madc_conversion(). Immediate return on some error conditions leaves the mutex locked. This patch ensures that mutex is always unlocked before leaving the function. Signed-off-by:
Sanjeev Premi <premi@ti.com> Cc: Keerthy <j-keerthy@ti.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 96f1f05a upstream. Since we configure all the queues as CHAINABLE, we need to update the byte count for all the queues, not only the AGGREGATABLE ones. Not doing so can confuse the SCD and make the fw assert. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Stephen Rothwell authored
[ Upstream commit b9eda06f ] Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Acked-by:
David Miller <davem@davemloft.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 9f28a2fc ] Commit 2c8cec5c (ipv4: Cache learned PMTU information in inetpeer) removed IP route cache garbage collector a bit too soon, as this gc was responsible for expired routes cleanup, releasing their neighbour reference. As pointed out by Robert Gladewitz, recent kernels can fill and exhaust their neighbour cache. Reintroduce the garbage collection, since we'll have to wait our neighbour lookups become refcount-less to not depend on this stuff. Reported-by:
Robert Gladewitz <gladewitz@gmx.de> Signed-off-by:
-
Weiping Pan authored
[ Upstream commit d01ff0a0 ] After reset ipv4_devconf->data[IPV4_DEVCONF_ACCEPT_LOCAL] to 0, we should flush route cache, or it will continue receive packets with local source address, which should be dropped. Signed-off-by:
Weiping Pan <panweiping3@gmail.com> Signed-off-by:
-
Thomas Graf authored
[ Upstream commit a76c0adf ] When checking whether a DATA chunk fits into the estimated rwnd a full sizeof(struct sk_buff) is added to the needed chunk size. This quickly exhausts the available rwnd space and leads to packets being sent which are much below the PMTU limit. This can lead to much worse performance. The reason for this behaviour was to avoid putting too much memory pressure on the receiver. The concept is not completely irational because a Linux receiver does in fact clone an skb for each DATA chunk delivered. However, Linux also reserves half the available socket buffer space for data structures therefore usage of it is already accounted for. When proposing to change this the last time it was noted that this behaviour was introduced to solve a performance issue caused by rwnd overusage in combination with small DATA chunks. Trying to reproduce this I found that with the sk_buff overhead removed, the performance would improve significantly unless socket buffer limits are increased. The following numbers have been gathered using a patched iperf supporting SCTP over a live 1 Gbit ethernet network. The -l option was used to limit DATA chunk sizes. The numbers listed are based on the average of 3 test runs each. Default values have been used for sk_(r|w)mem. Chunk Size Unpatched No Overhead ------------------------------------- 4 15.2 Kbit [!] 12.2 Mbit [!] 8 35.8 Kbit [!] 26.0 Mbit [!] 16 95.5 Kbit [!] 54.4 Mbit [!] 32 106.7 Mbit 102.3 Mbit 64 189.2 Mbit 188.3 Mbit 128 331.2 Mbit 334.8 Mbit 256 537.7 Mbit 536.0 Mbit 512 766.9 Mbit 766.6 Mbit 1024 810.1 Mbit 808.6 Mbit Signed-off-by:
Thomas Graf <tgraf@redhat.com> Signed-off-by:
-
Xi Wang authored
[ Upstream commit 2692ba61 ] Commit 8ffd3208 voids the previous patches f6778aab and 810c0719 for limiting the autoclose value. If userspace passes in -1 on 32-bit platform, the overflow check didn't work and autoclose would be set to 0xffffffff. This patch defines a max_autoclose (in seconds) for limiting the value and exposes it through sysctl, with the following intentions. 1) Avoid overflowing autoclose * HZ. 2) Keep the default autoclose bound consistent across 32- and 64-bit platforms (INT_MAX / HZ in this patch). 3) Keep the autoclose value consistent between setsockopt() and getsockopt() calls. Suggested-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 3f1e6d3f ] gred_change_vq() is called under sch_tree_lock(sch). This means a spinlock is held, and we are not allowed to sleep in this context. We might pre-allocate memory using GFP_KERNEL before taking spinlock, but this is not suitable for stable material. Signed-off-by:
-
Gerlando Falauto authored
[ Upstream commit cd7816d1 ] previous commit 3fb72f1e makes IP-Config wait for carrier on at least one network device. Before waiting (predefined value 120s), check that at least one device was successfully brought up. Otherwise (e.g. buggy bootloader which does not set the MAC address) there is no point in waiting for carrier. Cc: Micha Nelissen <micha@neli.hopto.org> Cc: Holger Brunck <holger.brunck@keymile.com> Signed-off-by:
Gerlando Falauto <gerlando.falauto@keymile.com> Signed-off-by:
-
Thomas Graf authored
[ Upstream commit 7838f2ce ] Userspace may not provide TCA_OPTIONS, in fact tc currently does so not do so if no arguments are specified on the command line. Return EINVAL instead of panicing. Signed-off-by:
-
Alex Juncu authored
[ Upstream commit 9cef310f ] Received non stream protocol packets were calling llc_cmsg_rcv that used a skb after that skb was released by sk_eat_skb. This caused received STP packets to generate kernel panics. Signed-off-by:
Alexandru Juncu <ajuncu@ixiacom.com> Signed-off-by:
Kunjan Naik <knaik@ixiacom.com> Signed-off-by:
-
Djalal Harouni authored
[ Upstream commit a454dace ] Signed-off-by:
Djalal Harouni <tixxdz@opendz.org> Acked-by:
-
Markus Kötter authored
[ Upstream commit a03ffcf8 ] x86 jump instruction size is 2 or 5 bytes (near/long jump), not 2 or 6 bytes. In case a conditional jump is followed by a long jump, conditional jump target is one byte past the start of target instruction. Signed-off-by:
Markus Kötter <nepenthesdev@gmail.com> Signed-off-by:
-
David S. Miller authored
[ A combination of upstream commits 1d299bc7 and e88d2468 ] Although we provide a proper way for a debugger to control whether syscall restart occurs, we run into problems because orig_i0 is not saved and restored properly. Luckily we can solve this problem without having to make debuggers aware of the issue. Across system calls, several registers are considered volatile and can be safely clobbered. Therefore we use the pt_regs save area of one of those registers, %g6, as a place to save and restore orig_i0. Debuggers transparently will do the right thing because they save and restore this register already. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 2e8ecdc0 ] Signed-off-by:
-
David S. Miller authored
[ Upstream commit a52312b8 ] Properly return the original destination buffer pointer. Signed-off-by:
Kjetil Oftedal <oftedal@gmail.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 21f74d36 ] This is setting things up so that we can correct the return value, so that it properly returns the original destination buffer pointer. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 045b7de9 ] Signed-off-by:
-
David S. Miller authored
[ Upstream commit 3e37fd31 ] To handle the large physical addresses, just make a simple wrapper around remap_pfn_range() like MIPS does. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 0b64120c ] Some of the sun4v code patching occurs in inline functions visible to, and usable by, modules. Therefore we have to patch them up during module load. Signed-off-by:
-
David S. Miller authored
[ Upstream commit b1f44e13 ] The "(insn & 0x01800000) != 0x01800000" test matches 'restore' but that is a legitimate place to see the %lo() part of a 32-bit symbol relocation, particularly in tail calls. Signed-off-by:
Sergei Trofimovich <slyfox@gentoo.org> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 7cc85833 ] This silently was working for many years and stopped working on Niagara-T3 machines. We need to set the MSIQ to VALID before we can set it's state to IDLE. On Niagara-T3, setting the state to IDLE first was causing HV_EINVAL errors. The hypervisor documentation says, rather ambiguously, that the MSIQ must be "initialized" before one can set the state. I previously understood this to mean merely that a successful setconf() operation has been performed on the MSIQ, which we have done at this point. But it seems to also mean that it has been set VALID too. Signed-off-by:
-
Nagalakshmi Nandigama authored
Upstrem commit: 911ae943 There's a bug in the MSIX backup and restore routines that cause a crash on non-x86 (direct access to PCI space not via read/write). These routines are unnecessary and were removed by the above commit, so also remove them from stable to fix the crash. Signed-off-by:
Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Hillf Danton authored
commit b0365c8d upstream. If a huge page is enqueued under the protection of hugetlb_lock, then the operation is atomic and safe. Signed-off-by:
Hillf Danton <dhillf@gmail.com> Reviewed-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Alex Deucher authored
commit 77e00f2e upstream. We already do this for cayman, need to also do it for BTC parts. The default memory and voltage setup is not adequate for advanced operation. Continuing will result in an unusable display. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Mingarelli, Thomas authored
commit e67d668e upstream. This patch makes use of the set_memory_x() kernel API in order to make necessary BIOS calls to source NMIs. This is needed for SLES11 SP2 and the latest upstream kernel as it appears the NX Execute Disable has grown in its control. Signed-off by: Thomas Mingarelli <thomas.mingarelli@hp.com> Signed-off by: Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Hugh Dickins authored
commit e6780f72 upstream. It was found (by Sasha) that if you use a futex located in the gate area we get stuck in an uninterruptible infinite loop, much like the ZERO_PAGE issue. While looking at this problem, PeterZ realized you'll get into similar trouble when hitting any install_special_pages() mapping. And are there still drivers setting up their own special mmaps without page->mapping, and without special VM or pte flags to make get_user_pages fail? In most cases, if page->mapping is NULL, we do not need to retry at all: Linus points out that even /proc/sys/vm/drop_caches poses no problem, because it ends up using remove_mapping(), which takes care not to interfere when the page reference count is raised. But there is still one case which does need a retry: if memory pressure called shmem_writepage in between get_user_pages_fast dropping page table lock and our acquiring page lock, then the page gets switched from filecache to swapcache (and ->mapping set to NULL) whatever the refcount. Fault it back in to get the page->mapping needed for key->shared.inode. Reported-by:
Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
Vladimir Zapolskiy authored
commit 55205c91 upstream. This change fixes a linking problem, which happens if oprofile is selected to be compiled as built-in: `oprofile_arch_exit' referenced in section `.init.text' of arch/arm/oprofile/built-in.o: defined in discarded section `.exit.text' of arch/arm/oprofile/built-in.o The problem is appeared after commit 87121ca5, which introduced oprofile_arch_exit() calls from __init function. Note that the aforementioned commit has been backported to stable branches, and the problem is known to be reproduced at least with 3.0.13 and 3.1.5 kernels. Signed-off-by:
Vladimir Zapolskiy <vladimir.zapolskiy@nokia.com> Signed-off-by:
Robert Richter <robert.richter@amd.com> Cc: Will Deacon <will.deacon@arm.com> Cc: oprofile-list <oprofile-list@lists.sourceforge.net> Link: http://lkml.kernel.org/r/20111222151540.GB16765@erda.amd.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Ulf Hansson authored
commit 3b6e3c73 upstream. When getting a cmd irq during an ongoing data transfer with dma, the dma job were never terminated. This is now corrected. Tested-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Per Forlin <per.forlin@stericsson.com> Signed-off-by:
Ulf Hansson <ulf.hansson@stericsson.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Ulf Hansson authored
commit b63038d6 upstream. The interrupt was previously enabled and then correctly cleared. Now we also handle it correctly. Tested-by:
-
Jason Chen authored
commit 5776ac2e upstream. According to imx pwm RM, the real period value should be PERIOD value in PWMPR plus 2. PWMO (Hz) = PCLK(Hz) / (period +2) Signed-off-by:
Jason Chen <jason.chen@linaro.org> Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Srivatsa S. Bhat authored
commit e30e2fdf upstream. Currently, the *_global_[un]lock_online() routines are not at all synchronized with CPU hotplug. Soft-lockups detected as a consequence of this race was reported earlier at https://lkml.org/lkml/2011/8/24/185. (Thanks to Cong Meng for finding out that the root-cause of this issue is the race condition between br_write_[un]lock() and CPU hotplug, which results in the lock states getting messed up). Fixing this race by just adding {get,put}_online_cpus() at appropriate places in *_global_[un]lock_online() is not a good option, because, then suddenly br_write_[un]lock() would become blocking, whereas they have been kept as non-blocking all this time, and we would want to keep them that way. So, overall, we want to ensure 3 things: 1. br_write_lock() and br_write_unlock() must remain as non-blocking. 2. The corresponding lock and unlock of the per-cpu spinlocks must not happen for different sets of CPUs. 3. Either prevent any new CPU online operation in between this lock-unlock, or ensure that the newly onlined CPU does not proceed with its corresponding per-cpu spinlock unlocked. To achieve all this: (a) We introduce a new spinlock that is taken by the *_global_lock_online() routine and released by the *_global_unlock_online() routine. (b) We register a callback for CPU hotplug notifications, and this callback takes the same spinlock as above. (c) We maintain a bitmap which is close to the cpu_online_mask, and once it is initialized in the lock_init() code, all future updates to it are done in the callback, under the above spinlock. (d) The above bitmap is used (instead of cpu_online_mask) while locking and unlocking the per-cpu locks. The callback takes the spinlock upon the CPU_UP_PREPARE event. So, if the br_write_lock-unlock sequence is in progress, the callback keeps spinning, thus preventing the CPU online operation till the lock-unlock sequence is complete. This takes care of requirement (3). The bitmap that we maintain remains unmodified throughout the lock-unlock sequence, since all updates to it are managed by the callback, which takes the same spinlock as the one taken by the lock code and released only by the unlock routine. Combining this with (d) above, satisfies requirement (2). Overall, since we use a spinlock (mentioned in (a)) to prevent CPU hotplug operations from racing with br_write_lock-unlock, requirement (1) is also taken care of. By the way, it is to be noted that a CPU offline operation can actually run in parallel with our lock-unlock sequence, because our callback doesn't react to notifications earlier than CPU_DEAD (in order to maintain our bitmap properly). And this means, since we use our own bitmap (which is stale, on purpose) during the lock-unlock sequence, we could end up unlocking the per-cpu lock of an offline CPU (because we had locked it earlier, when the CPU was online), in order to satisfy requirement (2). But this is harmless, though it looks a bit awkward. Debugged-by:
Cong Meng <mc@linux.vnet.ibm.com> Signed-off-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Hillf Danton authored
commit a41c58a6 upstream. If the request is to create non-root group and we fail to meet it, we should leave the root unchanged. Signed-off-by:
-
Wey-Yi Guy authored
commit 78feb35b upstream. My previous patch 34a5b4b6 iwlwifi: do not re-configure HT40 after associated Fix the case of HT40 after association on specified AP, but it break the association for some APs and cause not able to establish connection. We need to address HT40 before and after addociation. Reported-by:
Andrej Gelenberg <andrej.gelenberg@udo.edu> Signed-off-by:
-
