- 22 Mar, 2014 37 commits
-
-
Linus Walleij authored
commit 052450fd upstream. Due to a problem in the MFD Kconfig it was not possible to compile the UCB battery driver for the Collie SA1100 system, in turn making it impossible to compile in the battery driver. (See patch "mfd: include all drivers in subsystem menu".) After fixing the MFD Kconfig (separate patch) a compile error appears in the Collie battery driver due to the <mach/collie.h> implicitly requiring <mach/hardware.h> through <linux/gpio.h> via <mach/gpio.h> prior to commit 40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface". Fix this up by including the required header into <mach/collie.h>. Cc: Andrea Adami <andrea.adami@gmail.com> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Anton Blanchard authored
commit a5b2cf5b upstream. The 64bit relocation code places a few symbols in the text segment. These symbols are only 4 byte aligned where they need to be 8 byte aligned. Add an explicit alignment. Signed-off-by:
Anton Blanchard <anton@samba.org> Tested-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Michael Neuling authored
commit 621b5060 upstream. When we fork/clone we currently don't copy any of the TM state to the new thread. This results in a TM bad thing (program check) when the new process is switched in as the kernel does a tmrechkpt with TEXASR FS not set. Also, since R1 is from userspace, we trigger the bad kernel stack pointer detection. So we end up with something like this: Bad kernel stack pointer 0 at c0000000000404fc cpu 0x2: Vector: 700 (Program Check) at [c00000003ffefd40] pc: c0000000000404fc: restore_gprs+0xc0/0x148 lr: 0000000000000000 sp: 0 msr: 9000000100201030 current = 0xc000001dd1417c30 paca = 0xc00000000fe00800 softe: 0 irq_happened: 0x01 pid = 0, comm = swapper/2 WARNING: exception is not recoverable, can't continue The below fixes this by flushing the TM state before we copy the task_struct to the clone. To do this we go through the tmreclaim patch, which removes the checkpointed registers from the CPU and transitions the CPU out of TM suspend mode. Hence we need to call tmrechkpt after to restore the checkpointed state and the TM mode for the current task. To make this fail from userspace is simply: tbegin li r0, 2 sc <boom> Kudos to Adhemerval Zanella Neto for finding this. Signed-off-by:
Michael Neuling <mikey@neuling.org> cc: Adhemerval Zanella Neto <azanella@br.ibm.com> Signed-off-by:
-
Chen-Yu Tsai authored
commit 905a5117 upstream. On tha Allwinner A20 SoC, the external interrupts on the pin controller device are connected to the GIC. Without chained_irq_{enter, exit}, external GPIO interrupts, such as used by mmc core card detect, cause the system to hang. This issue was first encountered during my attempt to get out-of-band interrupts for WiFi on the Cubietruck working. With David's new series of sunci-mci using mmc slot-gpio for (GPIO interrupt based) card detection, removing the SD card also causes my Cubietruck to hang. This problem should extend to all Allwinner A20 based boards. With this fix, the system no longer hangs when I remove or insert the SD card. /proc/interrupts show that the interrupt has correctly fired. However the system still does not detect card removal/insertion. I believe this is another unrelated issue. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Takashi Iwai authored
commit 9b745ab8 upstream. Lenovo IdeaPad 410Y with ALC282 codec makes loud click noises at boot and shutdown. Also, it wrongly misdetects the acpi_thinkpad hook. This patch adds a device-specific fixup for disabling the shutup callback that is the cause of the click noise and also avoiding the thinpad_helper calls. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=71511Reported-and-tested-by:
Guilherme Amadio <guilherme.amadio@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit c5eda4c1 upstream. The mixer widget (NID 0x20) of AD1884 and AD1984 codecs isn't connected directly to the actual I/O paths but only via another mixer widget (NID 0x21). We need a similar fix as we did for AD1882. Signed-off-by:
-
Marius Knaust authored
commit a6b92b66 upstream. Signed-off-by:
Marius Knaust <marius.knaust@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit e805ca8b upstream. Logitech C500 (046d:0807) needs the same workaround like other Logitech Webcams. Signed-off-by:
-
Roman Volkov authored
commit 3dd77654 upstream. Actually CS4245 connected to the I2S channel 1 for capture, not channel 2. Otherwise capturing and playback does not work for CS4245. Signed-off-by:
Roman Volkov <v1ron@mail.ru> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Lauri Kasanen authored
commit 14eedc32 upstream. Without this, a bo may get created in the cpu-inaccessible vram. Before the CP engines get setup, all copies are done via cpu memcpy. This means that the cpu tries to read from inaccessible memory, fails, and the radeon module proceeds to disable acceleration. Doing this has no downsides, as the real VRAM size gets set as soon as the CP engines get init. This is a candidate for 3.14 fixes. v2: Add comment on why the function is used Signed-off-by:
Lauri Kasanen <cand@gmx.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Amitkumar Karwar authored
commit d5124648 upstream. While preparing association request, intersection of device's VHT capability information and corresponding field advertised by AP is used. This patch fixes a couple errors while saving and copying vht_cap and vht_oper fields from AP's beacon. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Amitkumar Karwar authored
commit c99b1861 upstream. While preparing association request, intersection of device's HT capability information and corresponding fields advertised by AP is used. This patch fixes an error while copying this field from AP's beacon. Signed-off-by:
-
Bing Zhao authored
commit adb07df1 upstream. As many Surface Pro I & II users have found out, the mwifiex_usb doesn't support usb autosuspend, and it has caused some system stability issues. Bug 69661 - mwifiex_usb on MS Surface Pro 1 is unstable Bug 60815 - Interface hangs in mwifiex_usb Bug 64111 - mwifiex_usb USB8797 crash failed to get signal information USB autosuspend get triggered when Surface Pro's AC power is removed or powertop enables power saving on USB8797 device. Driver's suspend handler is called here, but resume handler won't be called until the AC power is put back on or powertop disables power saving for USB8797. We need to refactor the suspend/resume handlers to support usb autosuspend properly. For now let's just remove it. Signed-off-by:
-
Amitkumar Karwar authored
commit 1c97560f upstream. We are sending sleep confirm done interrupt in the middle of sleep handshake. There is a corner case when Tx done interrupt is received from firmware during sleep handshake due to which host and firmware power states go out of sync causing cmd and Tx data timeout problem. Hence sleep confirm done interrupt is sent at the end of sleep handshake to fix the problem. Signed-off-by:
-
Amitkumar Karwar authored
commit bb8e6a1e upstream. We may get a NULL pointer here if skb allocation for Rx packet was failed earlier. Signed-off-by:
-
Avinash Patil authored
commit 4f7ba432 upstream. Write io memory to clean PCIe buffer only when PCIe device is present else this results into crash because of invalid memory access. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 205e2210 upstream. NICs supported by iwldvm don't handle well TX AMPDU. Disable it by default, still leave the possibility to the user to force enable it with a debug parameter. NICs supported by iwlmvm don't suffer from the same issue, leave TX AMPDU enabled by default for these. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 143582c6 upstream. Only the first packet is currently handled correctly, but then all others are assumed to have failed which is problematic. Fix this, marking them all successful instead (since if they're not then the firmware will have transmitted them as single frames.) This fixes the lost packet reporting. Also do a tiny variable scoping cleanup. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> [Add the dvm part] Signed-off-by:
-
Emmanuel Grumbach authored
commit ec6f678c upstream. We set IWL_STA_UCODE_INPROGRESS flag when we add a station and clear it when we send the LQ command for it. But the LQ command is sent only when the association succeeds. If the association doesn't succeed, we would leave this flag set and that wouldn't indicate the station entry as vacant. This probably fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1065663Reviewed-by:
-
Max Stepanov authored
commit e7eb65ca upstream. Some APs reject STA association request if a listen interval value exceeds a threshold of 10. Thus, for example, Cisco APs may deny STA associations returning status code 12 (Association denied due to reason outside the scope of 802.11 standard) in the association response frame. Fixing the issue by setting the default IWL_CONN_MAX_LISTEN_INTERVAL value from 70 to 10. Signed-off-by:
Max Stepanov <Max.Stepanov@intel.com> Reviewed-by:
Alexander Bondar <alexander.bondar@intel.com> Signed-off-by:
-
Felix Fietkau authored
commit b7b146c9 upstream. Only set sc->rx.discard_next to rx_stats->rs_more when actually discarding the current descriptor. Also, fix a detection of broken descriptors: First the code checks if the current descriptor is not done. Then it checks if the next descriptor is done. Add a check that afterwards checks the first descriptor again, because it might have been completed in the mean time. This fixes a regression introduced in commit 723e7113 "ath9k: fix handling of broken descriptors" Reported-by:
Marco André Dinis <marcoandredinis@gmail.com> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
commit 558ff225 upstream. When passing tx frames to the U-APSD queue for powersave poll responses, the ath_atx_tid pointer needs to be passed to ath_tx_setup_buffer for proper sequence number accounting. This fixes high latency and connection stability issues with ath9k running as AP and a few kinds of mobile phones as client, when PS-Poll is heavily used Signed-off-by:
-
Stanislaw Gruszka authored
commit 21f8aaee upstream. We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That is race condition which can result of doing list_del(&tid->list) twice (second time with poisoned list node) and cause crash like shown below: [424271.637220] BUG: unable to handle kernel paging request at 00100104 [424271.637328] IP: [<f90fc072>] ath_tx_aggr_sleep+0x62/0xe0 [ath9k] ... [424271.639953] Call Trace: [424271.639998] [<f90f6900>] ? ath9k_get_survey+0x110/0x110 [ath9k] [424271.640083] [<f90f6942>] ath9k_sta_notify+0x42/0x50 [ath9k] [424271.640177] [<f809cfef>] sta_ps_start+0x8f/0x1c0 [mac80211] [424271.640258] [<c10f730e>] ? free_compound_page+0x2e/0x40 [424271.640346] [<f809e915>] ieee80211_rx_handlers+0x9d5/0x2340 [mac80211] [424271.640437] [<c112f048>] ? kmem_cache_free+0x1d8/0x1f0 [424271.640510] [<c1345a84>] ? kfree_skbmem+0x34/0x90 [424271.640578] [<c10fc23c>] ? put_page+0x2c/0x40 [424271.640640] [<c1345a84>] ? kfree_skbmem+0x34/0x90 [424271.640706] [<c1345a84>] ? kfree_skbmem+0x34/0x90 [424271.640787] [<f809dde3>] ? ieee80211_rx_handlers_result+0x73/0x1d0 [mac80211] [424271.640897] [<f80a07a0>] ieee80211_prepare_and_rx_handle+0x520/0xad0 [mac80211] [424271.641009] [<f809e22d>] ? ieee80211_rx_handlers+0x2ed/0x2340 [mac80211] [424271.641104] [<c13846ce>] ? ip_output+0x7e/0xd0 [424271.641182] [<f80a1057>] ieee80211_rx+0x307/0x7c0 [mac80211] [424271.641266] [<f90fa6ee>] ath_rx_tasklet+0x88e/0xf70 [ath9k] [424271.641358] [<f80a0f2c>] ? ieee80211_rx+0x1dc/0x7c0 [mac80211] [424271.641445] [<f90f82db>] ath9k_tasklet+0xcb/0x130 [ath9k] Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=70551Reported-and-tested-by:
Max Sydorenko <maxim.stargazer@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Sujith Manoharan authored
commit b3050248 upstream. The minimum CCA power threshold values have to be adjusted for existing cards to be in compliance with new regulations. Newer cards will make use of the values obtained from EEPROM, support for this was added earlier. To make sure that cards that are already in use and don't have proper values in EEPROM, do not violate regulations, use the initvals instead. Reported-by:
Jeang Daniel <dyjeong@qca.qualcomm.com> Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Johannes Berg authored
commit 864a6040 upstream. Avoid leaking data by sending uninitialized memory and setting an invalid (non-zero) fragment number (the sequence number is ignored anyway) by setting the seq_ctrl field to zero. Fixes: 3f52b7e3 ("mac80211: mesh power save basics") Fixes: ce662b44 ("mac80211: send (QoS) Null if no buffered frames") Reviewed-by:
-
Johannes Berg authored
commit cb664981 upstream. When a VHT network uses 20 or 40 MHz as per the HT operation information, the channel center frequency segment 0 field in the VHT operation information is reserved, so ignore it. This fixes association with such networks when the AP puts 0 into the field, previously we'd disconnect due to an invalid channel with the message wlan0: AP VHT information is invalid, disable VHT Fixes: f2d9d270 ("mac80211: support VHT association") Reported-by:
Tim Nelson <tim.l.nelson@gmail.com> Signed-off-by:
-
Johannes Berg authored
commit 963a1852 upstream. The MLME code in mac80211 must track whether or not the AP changed bandwidth, but if there's no change while tracking it shouldn't do anything, otherwise regulatory updates can make it impossible to connect to certain APs if the regulatory database doesn't match the information from the AP. See the precise scenario described in the code. This still leaves some possible problems with CSA or if the AP actually changed bandwidth, but those cases are less common and won't completely prevent using it. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=70881Reported-and-tested-by:
Nate Carlson <kernel@natecarlson.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 1d147bfa upstream. There is a race between the TX path and the STA wakeup: while a station is sleeping, mac80211 buffers frames until it wakes up, then the frames are transmitted. However, the RX and TX path are concurrent, so the packet indicating wakeup can be processed while a packet is being transmitted. This can lead to a situation where the buffered frames list is emptied on the one side, while a frame is being added on the other side, as the station is still seen as sleeping in the TX path. As a result, the newly added frame will not be send anytime soon. It might be sent much later (and out of order) when the station goes to sleep and wakes up the next time. Additionally, it can lead to the crash below. Fix all this by synchronising both paths with a new lock. Both path are not fastpath since they handle PS situations. In a later patch we'll remove the extra skb queue locks to reduce locking overhead. BUG: unable to handle kernel NULL pointer dereference at 000000b0 IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211] *pde = 00000000 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1 EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211] EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000 ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000) iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9 Stack: e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0 ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210 ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002 Call Trace: [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211] [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211] [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211] [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211] [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211] [<c149ef70>] dev_hard_start_xmit+0x450/0x950 [<c14b9aa9>] sch_direct_xmit+0xa9/0x250 [<c14b9c9b>] __qdisc_run+0x4b/0x150 [<c149f732>] dev_queue_xmit+0x2c2/0xca0 Reported-by:
Yaara Rozenblum <yaara.rozenblum@intel.com> Signed-off-by:
-
Felix Fietkau authored
commit 1bf4bbb4 upstream. Improves reliability of wifi connections with WPA, since authentication frames are prioritized over normal traffic and also typically exempt from aggregation. Signed-off-by:
-
Alexandre Bounine authored
commit 04379dff upstream. This patch is a modification of the patch originally proposed by Xiaotian Feng <xtfeng@gmail.com>: https://lkml.org/lkml/2012/11/5/413 This new version disables DMA channel interrupts and ensures that the tasklet wil not be scheduled again before calling tasklet_kill(). Unfortunately the updated patch was not released at that time due to planned rework of Tsi721 mport driver to use threaded interrupts (which has yet to happen). Recently the issue was reported again: https://lkml.org/lkml/2014/2/19/762. Description from the original Xiaotian's patch: "Some drivers use tasklet_disable in device remove/release process, tasklet_disable will inc tasklet->count and return. If the tasklet is not handled yet under some softirq pressure, the tasklet will be placed on the tasklet_vec, never have a chance to be excuted. This might lead to a heavy loaded ksoftirqd, wakeup with pending_softirq, but tasklet is disabled. tasklet_kill should be used in this case." This patch is applicable to kernel versions starting from v3.5. Signed-off-by:
Alexandre Bounine <alexandre.bounine@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Xiaotian Feng <xtfeng@gmail.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Mike Galbraith <bitbucket@online.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
George McCollister authored
commit 791c9e02 upstream. dequeue_entity() is called when p->on_rq and sets se->on_rq = 0 which appears to guarentee that the !se->on_rq condition is met. If the task has done set_current_state(TASK_INTERRUPTIBLE) without schedule() the second condition will be met and vruntime will be incorrectly adjusted twice. In certain cases this can result in the task's vruntime never increasing past the vruntime of other tasks on the CFS' run queue, starving them of CPU time. This patch changes switched_from_fair() to use !p->on_rq instead of !se->on_rq. I'm able to cause a task with a priority of 120 to starve all other tasks with the same priority on an ARM platform running 3.2.51-rt72 PREEMPT RT by writing one character at time to a serial tty (16550 UART) in a tight loop. I'm also able to verify making this change corrects the problem on that platform and kernel version. Signed-off-by:
George McCollister <george.mccollister@gmail.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1392767811-28916-1-git-send-email-george.mccollister@gmail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Hugh Dickins authored
commit ce48225f upstream. Commit 0eef6156 ("memcg: fix css reference leak and endless loop in mem_cgroup_iter") got the interaction with the commit a few before it d8ad3055 ("mm/memcg: iteration skip memcgs not yet fully initialized") slightly wrong, and we didn't notice at the time. It's elusive, and harder to get than the original, but for a couple of days before rc1, I several times saw a endless loop similar to that supposedly being fixed. This time it was a tighter loop in __mem_cgroup_iter_next(): because we can get here when our root has already been offlined, and the ordering of conditions was such that we then just cycled around forever. Fixes: 0eef6156 ("memcg: fix css reference leak and endless loop in mem_cgroup_iter"). Signed-off-by:
Hugh Dickins <hughd@google.com> Acked-by:
Michal Hocko <mhocko@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Greg Thelen <gthelen@google.com> Signed-off-by:
-
Al Viro authored
commit 1b56e989 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Jan Kara authored
commit 15c34a76 upstream. Global quota files are accessed from different nodes. Thus we cannot cache offset of quota structure in the quota file after we drop our node reference count to it because after that moment quota structure may be freed and reallocated elsewhere by a different node resulting in corruption of quota file. Fix the problem by clearing dq_off when we are releasing dquot structure. We also remove the DB_READ_B handling because it is useless - DQ_ACTIVE_B is set iff DQ_READ_B is set. Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Goldwyn Rodrigues <rgoldwyn@suse.de> Cc: Joel Becker <jlbec@evilplan.org> Reviewed-by:
Mark Fasheh <mfasheh@suse.de> Signed-off-by:
-
Vlastimil Babka authored
commit 9050d7eb upstream. Daniel Borkmann reported a VM_BUG_ON assertion failing: ------------[ cut here ]------------ kernel BUG at mm/mlock.c:528! invalid opcode: 0000 [#1] SMP Modules linked in: ccm arc4 iwldvm [...] video CPU: 3 PID: 2266 Comm: netsniff-ng Not tainted 3.14.0-rc2+ #8 Hardware name: LENOVO 2429BP3/2429BP3, BIOS G4ET37WW (1.12 ) 05/29/2012 task: ffff8801f87f9820 ti: ffff88002cb44000 task.ti: ffff88002cb44000 RIP: 0010:[<ffffffff81171ad0>] [<ffffffff81171ad0>] munlock_vma_pages_range+0x2e0/0x2f0 Call Trace: do_munmap+0x18f/0x3b0 vm_munmap+0x41/0x60 SyS_munmap+0x22/0x30 system_call_fastpath+0x1a/0x1f RIP munlock_vma_pages_range+0x2e0/0x2f0 ---[ end trace a0088dcf07ae10f2 ]--- because munlock_vma_pages_range() thinks it's unexpectedly in the middle of a THP page. This can be reproduced with default config since 3.11 kernels. A reproducer can be found in the kernel's selftest directory for networking by running ./psock_tpacket. The problem is that an order=2 compound page (allocated by alloc_one_pg_vec_page() is part of the munlocked VM_MIXEDMAP vma (mapped by packet_mmap()) and mistaken for a THP page and assumed to be order=9. The checks for THP in munlock came with commit ff6a6da6 ("mm: accelerate munlock() treatment of THP pages"), i.e. since 3.9, but did not trigger a bug. It just makes munlock_vma_pages_range() skip such compound pages until the next 512-pages-aligned page, when it encounters a head page. This is however not a problem for vma's where mlocking has no effect anyway, but it can distort the accounting. Since commit 7225522b ("mm: munlock: batch non-THP page isolation and munlock+putback using pagevec") this can trigger a VM_BUG_ON in PageTransHuge() check. This patch fixes the issue by adding VM_MIXEDMAP flag to VM_SPECIAL, a list of flags that make vma's non-mlockable and non-mergeable. The reasoning is that VM_MIXEDMAP vma's are similar to VM_PFNMAP, which is already on the VM_SPECIAL list, and both are intended for non-LRU pages where mlocking makes no sense anyway. Related Lkml discussion can be found in [2]. [1] tools/testing/selftests/net/psock_tpacket [2] https://lkml.org/lkml/2014/1/10/427Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Reported-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by:
Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by:
-
Johannes Weiner authored
commit 27329369 upstream. Jan Stancek reports manual page migration encountering allocation failures after some pages when there is still plenty of memory free, and bisected the problem down to commit 81c0a2bb ("mm: page_alloc: fair zone allocator policy"). The problem is that GFP_THISNODE obeys the zone fairness allocation batches on one hand, but doesn't reset them and wake kswapd on the other hand. After a few of those allocations, the batches are exhausted and the allocations fail. Fixing this means either having GFP_THISNODE wake up kswapd, or GFP_THISNODE not participating in zone fairness at all. The latter seems safer as an acute bugfix, we can clean up later. Reported-by:
Jan Stancek <jstancek@redhat.com> Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Mel Gorman <mgorman@suse.de> Signed-off-by:
-
Minchan Kim authored
commit db5d711e upstream. zram_meta_alloc could fail so caller should check it. Otherwise, your system will hang. Signed-off-by:
Minchan Kim <minchan@kernel.org> Acked-by:
Jerome Marchand <jmarchan@redhat.com> Signed-off-by:
-
- 21 Mar, 2014 2 commits
-
-
Rob Clark authored
commit 9ef7506f upstream. A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement this function. Yet can end up somehow with an evicted bo: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) PGD 16e761067 PUD 16e6cf067 PMD 0 Oops: 0010 [#1] SMP Modules linked in: bnep bluetooth rfkill fuse ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables sg btrfs zlib_deflate raid6_pq xor dm_queue_length iTCO_wdt iTCO_vendor_support coretemp kvm dcdbas dm_service_time microcode serio_raw pcspkr lpc_ich mfd_core i7core_edac edac_core ses enclosure ipmi_si ipmi_msghandler shpchp acpi_power_meter mperf nfsd auth_rpcgss nfs_acl lockd uinput sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sr_mod cdrom sd_mod usb_storage mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit lpfc drm_kms_helper ttm crc32c_intel ata_piix bfa drm ixgbe libata i2c_core mdio crc_t10dif ptp crct10dif_common pps_core scsi_transport_fc dca scsi_tgt megaraid_sas bnx2 dm_mirror dm_region_hash dm_log dm_mod CPU: 16 PID: 2572 Comm: X Not tainted 3.10.0-86.el7.x86_64 #1 Hardware name: Dell Inc. PowerEdge R810/0H235N, BIOS 0.3.0 11/14/2009 task: ffff8801799dabc0 ti: ffff88016c884000 task.ti: ffff88016c884000 RIP: 0010:[<0000000000000000>] [< (null)>] (null) RSP: 0018:ffff88016c885ad8 EFLAGS: 00010202 RAX: ffffffffa04e94c0 RBX: ffff880178937a20 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000240004 RDI: ffff880178937a00 RBP: ffff88016c885b60 R08: 00000000000171a0 R09: ffff88007cf171a0 R10: ffffea0005842540 R11: ffffffff810487b9 R12: ffff880178937b30 R13: ffff880178937a00 R14: ffff88016c885b78 R15: ffff880179929400 FS: 00007f81ba2ef980(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000016e763000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffffffffa0306fae ffff8801799295c0 0000000000260004 0000000000000001 ffff88016c885b60 ffffffffa0307669 00ff88007cf17738 ffff88017cf17700 ffff880178937a00 ffff880100000000 ffff880100000000 0000000079929400 Call Trace: [<ffffffffa0306fae>] ? ttm_bo_handle_move_mem+0x54e/0x5b0 [ttm] [<ffffffffa0307669>] ? ttm_bo_mem_space+0x169/0x340 [ttm] [<ffffffffa0307bd7>] ttm_bo_move_buffer+0x117/0x130 [ttm] [<ffffffff81130001>] ? perf_event_init_context+0x141/0x220 [<ffffffffa0307cb1>] ttm_bo_validate+0xc1/0x130 [ttm] [<ffffffffa04e7377>] mgag200_bo_pin+0x87/0xc0 [mgag200] [<ffffffffa04e56c4>] mga_crtc_cursor_set+0x474/0xbb0 [mgag200] [<ffffffff811971d2>] ? __mem_cgroup_commit_charge+0x152/0x3b0 [<ffffffff815c4182>] ? mutex_lock+0x12/0x2f [<ffffffffa0201433>] drm_mode_cursor_common+0x123/0x170 [drm] [<ffffffffa0205231>] drm_mode_cursor_ioctl+0x41/0x50 [drm] [<ffffffffa01f5ca2>] drm_ioctl+0x502/0x630 [drm] [<ffffffff815cbab4>] ? __do_page_fault+0x1f4/0x510 [<ffffffff8101cb68>] ? __restore_xstate_sig+0x218/0x4f0 [<ffffffff811b4445>] do_vfs_ioctl+0x2e5/0x4d0 [<ffffffff8124488e>] ? file_has_perm+0x8e/0xa0 [<ffffffff811b46b1>] SyS_ioctl+0x81/0xa0 [<ffffffff815d05d9>] system_call_fastpath+0x16/0x1b Code: Bad RIP value. RIP [< (null)>] (null) RSP <ffff88016c885ad8> CR2: 0000000000000000 Signed-off-by:
Rob Clark <rclark@redhat.com> Reviewed-by:
Jérôme Glisse <jglisse@redhat.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Filipe Brandenburger authored
commit 4fb1a86f upstream. Sometimes the cleanup after memcg hierarchy testing gets stuck in mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0. There may turn out to be several causes, but a major cause is this: the workitem to offline parent can get run before workitem to offline child; parent's mem_cgroup_reparent_charges() circles around waiting for the child's pages to be reparented to its lrus, but it's holding cgroup_mutex which prevents the child from reaching its mem_cgroup_reparent_charges(). Further testing showed that an ordered workqueue for cgroup_destroy_wq is not always good enough: percpu_ref_kill_and_confirm's call_rcu_sched stage on the way can mess up the order before reaching the workqueue. Instead, when offlining a memcg, call mem_cgroup_reparent_charges() on all its children (and grandchildren, in the correct order) to have their charges reparented first. Fixes: e5fca243 ("cgroup: use a dedicated workqueue for cgroup destruction") Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Acked-by:
-
- 14 Mar, 2014 1 commit
-
-
Florian Westphal authored
commit 08629354 upstream. Halve mss table size to make blind cookie guessing more difficult. This is sad since the tables were already small, but there is little alternative except perhaps adding more precise mss information in the tcp timestamp. Timestamps are unfortunately not ubiquitous. Guessing all possible cookie values still has 8-in 2**32 chance. Reported-by:
Jakob Lell <jakob@jakoblell.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
