- 03 Mar, 2016 40 commits
-
-
Alex Deucher authored
commit 8e7cedc6 upstream. set_power_state defaults to no displays, so we need to update the display configuration after setting up the powerstate on the first call. In most cases this is not an issue since ends up getting called multiple times at any given modeset and the proper order is achieved in the display changed handling at the top of the function. Reviewed-by:
Christian König <christian.koenig@amd.com> Acked-by:
Jordan Lazare <Jordan.Lazare@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mario Kleiner authored
commit e1d09dc0 upstream. This fixes a regression introduced in Linux 4.4. This is a port of the same fix for radeon-kms in the patch "drm/radeon: Don't hang in radeon_flip_work_func on disabled crtc. (v2)" Limit the amount of time amdgpu_flip_work_func can delay programming a page flip, by both limiting the maximum amount of time per wait cycle and the maximum number of wait cycles. Continue the flip if the limit is exceeded, even if that may result in a visual or timing glitch. This is to prevent a hang of page flips, as reported in fdo bug #93746: Disconnecting a DisplayPort display in parallel to a kms pageflip getting queued can cause the following hang of page flips and thereby an unusable desktop: 1. kms pageflip ioctl() queues pageflip -> queues execution of amdgpu_flip_work_func. 2. Hotunplug of display causes the driver to DPMS OFF the unplugged display. Display engine shuts down, scanout no longer moves, but stays at its resting position at start line of vblank. 3. amdgpu_flip_work_func executes while crtc is off, and due to the non-moving scanout position, the new flip delay code introduced into Linux 4.4 by commit 8e36f9d3 ("drm/amdgpu: Fixup hw vblank counter/ts..") enters an infinite wait loop. 4. After reconnecting the display, the pageflip continues to hang in 3. and the display doesn't update its view of the desktop. This patch fixes the Linux 4.4 regression from fdo bug #93746 <https://bugs.freedesktop.org/show_bug.cgi?id=93746> Reported-by:
Bernd Steinhauser <linux@bernd-steinhauser.de> Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Rasmus Villemoes authored
commit 09ccbb74 upstream. We need to use post-decrement to get the pci_map_page undone also for i==0, and to avoid some very unpleasant behaviour if pci_map_page failed already at i==0. Reviewed-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Christian König authored
commit cc1de6e8 upstream. Otherwise we could try to evict overlapping userptr BOs in get_user_pages(), leading to a possible circular locking dependency. Signed-off-by:
-
Nicolai Hähnle authored
commit a8d81b36 upstream. An arbitrary amount of time can pass between spin_unlock and fence_wait_any_timeout, so we need to ensure that nobody frees the fences from under us. A stress test (rapidly starting and killing hundreds of glxgears instances) ran into a deadlock in fence_wait_any_timeout after about an hour, and this race condition appears to be a plausible cause. v2: agd: rebase on upstream Signed-off-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by:
-
Nicolai Hähnle authored
commit b19763d0 upstream. Signed-off-by:
-
Flora Cui authored
commit ca198528 upstream. No need to re-init asic if it's already been initialized. Skip IB tests since kernel processes are frozen in thaw. Signed-off-by:
Flora Cui <Flora.Cui@amd.com> Reviewed-by:
-
Alex Deucher authored
commit dba280b2 upstream. It's working now. bug: https://bugs.freedesktop.org/show_bug.cgi?id=92270Reviewed-by:
Ken Wang <Qingqing.Wang@amd.com> Reviewed-by:
-
Alex Deucher authored
commit 97dde76a upstream. Not validated. Reviewed-by:
-
Alex Deucher authored
commit 8878d854 upstream. topaz is actually gmc7. Reviewed-by:
-
Alex Deucher authored
commit 72b459c8 upstream. Add the topaz golden settings into the gmc7 module. Reviewed-by:
-
Ken Wang authored
commit 8f3c1629 upstream. Reviewed-by:
-
Ken Wang authored
commit 429c45de upstream. Reviewed-by:
-
Alex Deucher authored
commit e42d8526 upstream. It's used by iceland which is VI. Reviewed-by:
-
Alex Deucher authored
commit ad32152e upstream. Vbios does this for us on asic_init. Reviewed-by: Ken Wang >Qingqing.Wang@amd.com> Signed-off-by:
-
Christian König authored
commit 78d0e182 upstream. We could pin BOs into invisible VRAM otherwise. v2: make logic more readable as suggested by Michel Signed-off-by:
-
Alex Deucher authored
commit e160e4db upstream. Need to make sure smu buffers are pinned on resume. This matches what Fiji does. Reviewed-by:
Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by:
-
Chunming Zhou authored
commit 888c9e33 upstream. when scheduler is enabled, the semaphore isn't used at all. Signed-off-by:
Chunming Zhou <David1.Zhou@amd.com> Reviewed-by:
-
Alex Deucher authored
commit 54fb2a5c upstream. Need to call this on resume if displays changes during suspend in order to properly be notified of changes. Signed-off-by:
-
Felix Kuehling authored
commit 005ae95e upstream. eaddr is sometimes treated as the last address inside the address range, and sometimes as the first address outside the range. This was resulting in errors when a test filled up the entire address space. Make it consistent to always be the last address within the range. Signed-off-by:
Felix.Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
Rob Clark authored
commit 96c5d076 upstream. Signed-off-by:
Rob Clark <robdclark@gmail.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Thomas Hellstrom authored
commit a50e2bf5 upstream. When the framebuffer is a vmwgfx dma buffer and a proxy surface is created, the vmw_kms_update_proxy() function requires that the proxy surface width and the framebuffer pitch are compatible, otherwise display corruption occurs as seen in gnome-shell/native with software 3D. Since the framebuffer pitch is determined by user-space, allocate a proxy surface the width of which is based on the framebuffer pitch rather than on the framebuffer width. Reported-by:
Raphael Hertzog <buxy@kali.org> Tested-by:
Mati Aharoni <muts@kali.org> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Brian Paul <brianp@vmware.com> Signed-off-by:
-
Thomas Hellstrom authored
commit fb89ac51 upstream. With CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y the vmwgfx kernel module would unconditionally throw a bug when checking for a held spinlock in the command buffer code. Fix this by using a lockdep check. Reported-and-tested-by:
Tetsuo Handa <penguin-kernel@i-love-sakura.ne.jp> Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
-
Michael S. Tsirkin authored
commit 2989be09 upstream. KASan detected a use-after-free error in virtio-pci remove code. In virtio_pci_remove(), vp_dev is still used after being freed in unregister_virtio_device() (in virtio_pci_release_dev() more precisely). To fix, keep a reference until cleanup is done. Fixes: 63bd62a0 ("virtio_pci: defer kfree until release callback") Reported-by:
Jerome Marchand <jmarchan@redhat.com> Cc: Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Tested-by:
-
Minchan Kim authored
commit 21ea9fb6 upstream. In balloon_page_dequeue, pages_lock should cover the loop (ie, list_for_each_entry_safe). Otherwise, the cursor page could be isolated by compaction and then list_del by isolation could poison the page->lru.{prev,next} so the loop finally could access wrong address like this. This patch fixes the bug. general protection fault: 0000 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 2 PID: 82 Comm: vballoon Not tainted 4.4.0-rc5-mm1-access_bit+ #1906 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff8800a7ff0000 ti: ffff8800a7fec000 task.ti: ffff8800a7fec000 RIP: 0010:[<ffffffff8115e754>] [<ffffffff8115e754>] balloon_page_dequeue+0x54/0x130 RSP: 0018:ffff8800a7fefdc0 EFLAGS: 00010246 RAX: ffff88013fff9a70 RBX: ffffea000056fe00 RCX: 0000000000002b7d RDX: ffff88013fff9a70 RSI: ffffea000056fe00 RDI: ffff88013fff9a68 RBP: ffff8800a7fefde8 R08: ffffea000056fda0 R09: 0000000000000000 R10: ffff8800a7fefd90 R11: 0000000000000001 R12: dead0000000000e0 R13: ffffea000056fe20 R14: ffff880138809070 R15: ffff880138809060 FS: 0000000000000000(0000) GS:ffff88013fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f229c10e000 CR3: 00000000b8b53000 CR4: 00000000000006a0 Stack: 0000000000000100 ffff880138809088 ffff880138809000 ffff880138809060 0000000000000046 ffff8800a7fefe28 ffffffff812c86d3 ffff880138809020 ffff880138809000 fffffffffff91900 0000000000000100 ffff880138809060 Call Trace: [<ffffffff812c86d3>] leak_balloon+0x93/0x1a0 [<ffffffff812c8bc7>] balloon+0x217/0x2a0 [<ffffffff8143739e>] ? __schedule+0x31e/0x8b0 [<ffffffff81078160>] ? abort_exclusive_wait+0xb0/0xb0 [<ffffffff812c89b0>] ? update_balloon_stats+0xf0/0xf0 [<ffffffff8105b6e9>] kthread+0xc9/0xe0 [<ffffffff8105b620>] ? kthread_park+0x60/0x60 [<ffffffff8143b4af>] ret_from_fork+0x3f/0x70 [<ffffffff8105b620>] ? kthread_park+0x60/0x60 Code: 8d 60 e0 0f 84 af 00 00 00 48 8b 43 20 a8 01 75 3b 48 89 d8 f0 0f ba 28 00 72 10 48 8b 03 f6 c4 08 75 2f 48 89 df e8 8c 83 f9 ff <49> 8b 44 24 20 4d 8d 6c 24 20 48 83 e8 20 4d 39 f5 74 7a 4c 89 RIP [<ffffffff8115e754>] balloon_page_dequeue+0x54/0x130 RSP <ffff8800a7fefdc0> ---[ end trace 43cf28060d708d5f ]--- Kernel panic - not syncing: Fatal exception Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Signed-off-by:
Minchan Kim <minchan@kernel.org> Signed-off-by:
Rafael Aquini <aquini@redhat.com> Signed-off-by:
-
Minchan Kim authored
commit f68b992b upstream. During my compaction-related stuff, I encountered a bug with ballooning. With repeated inflating and deflating cycle, guest memory( ie, cat /proc/meminfo | grep MemTotal) is decreased and couldn't be recovered. The reason is balloon_lock doesn't cover release_pages_balloon so struct virtio_balloon fields could be overwritten by race of fill_balloon(e,g, vb->*pfns could be critical). This patch fixes it in my test. Signed-off-by:
-
Henry Chen authored
commit aab3c3f3 upstream. This patch fix the below build error: drivers/regulator/mt6311-regulator.c:111: undefined reference to `__devm_regmap_init_i2c' Signed-off-by:
Henry Chen <henryc.chen@mediatek.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Chen-Yu Tsai authored
commit 3cb99e2e upstream. The enable/disable values for GPIO LDOs are reversed. It seems no one noticed as AXP22x support was introduced recently, and no one was using the GPIO LDOs, either because no designs actually use them or board support hasn't caught up. Fixes: 1b82b4e4 ("regulator: axp20x: Add support for AXP22X regulators") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Marek Szyprowski authored
commit 6b4feaea upstream. It is allowed to enable/disable clocks from interrupts, so common Exynos ARM clock management code for CPUfreq should use 'irqsave' version of spin_lock calls to avoid potential deadlock caused by spin_lock recursion. The same spin_lock is used by gate/mux clocks during enable/disable calls. This deadlock, can be reproduced by enabling CPUfreq (ondemand or userspace) and decoding video with s5p-mfc driver. Relevant stack trace: [ 5928.061534] BUG: spinlock recursion on CPU#0, bash/1252 [ 5928.061609] lock: 0xee80454c, .magic: dead4ead, .owner: bash/1252, .owner_cpu: 0 [ 5928.068586] CPU: 0 PID: 1252 Comm: bash Tainted: G W 4.4.0-rc4-00001-g447a7fd #678 [ 5928.077260] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 5928.083359] [<c00153dc>] (unwind_backtrace) from [<c00121b4>] (show_stack+0x10/0x14) [ 5928.091072] [<c00121b4>] (show_stack) from [<c0213e28>] (dump_stack+0x68/0xb8) [ 5928.098275] [<c0213e28>] (dump_stack) from [<c005c1ec>] (do_raw_spin_lock+0x184/0x1ac) [ 5928.106177] [<c005c1ec>] (do_raw_spin_lock) from [<c05cfa98>] (_raw_spin_lock_irqsave+0x20/0x28) [ 5928.114943] [<c05cfa98>] (_raw_spin_lock_irqsave) from [<c0468698>] (clk_gate_endisable+0x24/0x98) [ 5928.123882] [<c0468698>] (clk_gate_endisable) from [<c0464d40>] (clk_core_disable+0x60/0x84) [ 5928.132299] [<c0464d40>] (clk_core_disable) from [<c0465e00>] (clk_disable+0x24/0x30) [ 5928.140117] [<c0465e00>] (clk_disable) from [<c03f3b80>] (s5p_mfc_handle_frame+0x254/0x860) [ 5928.148445] [<c03f3b80>] (s5p_mfc_handle_frame) from [<c03f4b34>] (s5p_mfc_irq+0x890/0xa24) [ 5928.156778] [<c03f4b34>] (s5p_mfc_irq) from [<c00627bc>] (handle_irq_event_percpu+0x50/0x14c) [ 5928.165283] [<c00627bc>] (handle_irq_event_percpu) from [<c00628f0>] (handle_irq_event+0x38/0x5c) [ 5928.174143] [<c00628f0>] (handle_irq_event) from [<c0065864>] (handle_fasteoi_irq+0xdc/0x1a4) [ 5928.182645] [<c0065864>] (handle_fasteoi_irq) from [<c0062090>] (generic_handle_irq+0x18/0x28) [ 5928.191236] [<c0062090>] (generic_handle_irq) from [<c00621a4>] (__handle_domain_irq+0x6c/0xdc) [ 5928.199917] [<c00621a4>] (__handle_domain_irq) from [<c0009470>] (gic_handle_irq+0x4c/0x98) [ 5928.208249] [<c0009470>] (gic_handle_irq) from [<c0012c54>] (__irq_svc+0x54/0x90) [ 5928.215709] Exception stack(0xeddb5cb8 to 0xeddb5d00) [ 5928.220745] 5ca0: ee80454c faddfadc [ 5928.228906] 5cc0: 00000000 01000001 ee831ce0 f8114200 ee807c00 01130520 00000403 eddb5d84 [ 5928.237063] 5ce0: ee807c48 2faf0800 ee807c0c eddb5d08 c046b618 c046b634 20000053 ffffffff [ 5928.245225] [<c0012c54>] (__irq_svc) from [<c046b634>] (exynos_cpuclk_notifier_cb+0x170/0x270) [ 5928.253823] [<c046b634>] (exynos_cpuclk_notifier_cb) from [<c003cb58>] (notifier_call_chain+0x44/0x84) [ 5928.263106] [<c003cb58>] (notifier_call_chain) from [<c003ccd4>] (__srcu_notifier_call_chain+0x6c/0x9c) [ 5928.272480] [<c003ccd4>] (__srcu_notifier_call_chain) from [<c003cd1c>] (srcu_notifier_call_chain+0x18/0x20) [ 5928.282288] [<c003cd1c>] (srcu_notifier_call_chain) from [<c0464ed0>] (__clk_notify+0x6c/0x74) [ 5928.290881] [<c0464ed0>] (__clk_notify) from [<c0465388>] (clk_propagate_rate_change+0xa0/0xac) [ 5928.299561] [<c0465388>] (clk_propagate_rate_change) from [<c0465378>] (clk_propagate_rate_change+0x90/0xac) [ 5928.309370] [<c0465378>] (clk_propagate_rate_change) from [<c04666fc>] (clk_core_set_rate_nolock+0x64/0xa8) [ 5928.319091] [<c04666fc>] (clk_core_set_rate_nolock) from [<c0466760>] (clk_set_rate+0x20/0x30) [ 5928.327686] [<c0466760>] (clk_set_rate) from [<c0428c70>] (set_target+0xe8/0x23c) [ 5928.335152] [<c0428c70>] (set_target) from [<c04244d0>] (__cpufreq_driver_target+0x184/0x29c) [ 5928.343655] [<c04244d0>] (__cpufreq_driver_target) from [<c0427128>] (cpufreq_set+0x44/0x64) [ 5928.352074] [<c0427128>] (cpufreq_set) from [<c0423948>] (store_scaling_setspeed+0x5c/0x74) [ 5928.360407] [<c0423948>] (store_scaling_setspeed) from [<c04238d0>] (store+0x7c/0x98) [ 5928.368221] [<c04238d0>] (store) from [<c0132540>] (sysfs_kf_write+0x44/0x48) [ 5928.375338] [<c0132540>] (sysfs_kf_write) from [<c0131b9c>] (kernfs_fop_write+0xb8/0x1bc) [ 5928.383496] [<c0131b9c>] (kernfs_fop_write) from [<c00d71f8>] (__vfs_write+0x2c/0xd4) [ 5928.391308] [<c00d71f8>] (__vfs_write) from [<c00d7de8>] (vfs_write+0xa0/0x144) [ 5928.398598] [<c00d7de8>] (vfs_write) from [<c00d8048>] (SyS_write+0x44/0x84) [ 5928.405631] [<c00d8048>] (SyS_write) from [<c000f540>] (ret_fast_syscall+0x0/0x3c) Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Andrew Donnellan authored
commit 48f0f6b7 upstream. When writing a value to config space, cxl_pcie_write_config() calls cxl_pcie_config_info() to obtain a mask and shift value, shifts the new value accordingly, then uses the mask to combine the shifted value with the existing value at the address as part of a read-modify-write pattern. Currently, we use a logical OR operator rather than a bitwise OR operator, which means any use of this function results in an incorrect value being written. Replace the logical OR operator with a bitwise OR operator so the value is written correctly. Reported-by:
Michael Ellerman <mpe@ellerman.id.au> Fixes: 6f7f0b3d ("cxl: Add AFU virtual PHB and kernel API") Signed-off-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Acked-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
-
Dmitry V. Levin authored
commit 525fd5a9 upstream. The value returned by sys_personality has type "long int". It is saved to a variable of type "int", which is not a problem yet because the type of task_struct->pesonality is "unsigned int". The problem is the sign extension from "int" to "long int" that happens on return from sys_sparc64_personality. For example, a userspace call personality((unsigned) -EINVAL) will result to any subsequent personality call, including absolutely harmless read-only personality(0xffffffff) call, failing with errno set to EINVAL. Signed-off-by:
Dmitry V. Levin <ldv@altlinux.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Borislav Petkov authored
commit 12e26969 upstream. I get the splat below when modprobing/rmmoding EDAC drivers. It happens because bus->name is invalid after bus_unregister() has run. The Code: section below corresponds to: .loc 1 1108 0 movq 672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus .loc 1 1109 0 popq %rbx # .loc 1 1108 0 movq (%rax), %rdi # _7->name, jmp kfree # and %rax has some funky stuff 2030203020312030 which looks a lot like something walked over it. Fix that by saving the name ptr before doing stuff to string it points to. general protection fault: 0000 [#1] SMP Modules linked in: ... CPU: 4 PID: 10318 Comm: modprobe Tainted: G I EN 3.12.51-11-default+ #48 Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011 task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000 RIP: 0010:[<ffffffffa019da92>] [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core] RSP: 0018:ffff88030da3fe28 EFLAGS: 00010292 RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286 RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110 R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68 R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000 FS: 00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0 Stack: Call Trace: i7core_unregister_mci.isra.9 i7core_remove pci_device_remove __device_release_driver driver_detach bus_remove_driver pci_unregister_driver i7core_exit SyS_delete_module system_call_fastpath 0x7fc9bf426536 Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b RIP [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core] RSP <ffff88030da3fe28> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Fixes: 7a623c03 ("edac: rewrite the sysfs code to use struct device") Signed-off-by:
-
Borislav Petkov authored
commit fcd5c4dd upstream. EDAC workqueue destruction is really fragile. We cancel delayed work but if it is still running and requeues itself, we still go ahead and destroy the workqueue and the queued work explodes when workqueue core attempts to run it. Make the destruction more robust by switching op_state to offline so that requeuing stops. Cancel any pending work *synchronously* too. EDAC i7core: Driver loaded. general protection fault: 0000 [#1] SMP CPU 12 Modules linked in: Supported: Yes Pid: 0, comm: kworker/0:1 Tainted: G IE 3.0.101-0-default #1 HP ProLiant DL380 G7 RIP: 0010:[<ffffffff8107dcd7>] [<ffffffff8107dcd7>] __queue_work+0x17/0x3f0 < ... regs ...> Process kworker/0:1 (pid: 0, threadinfo ffff88019def6000, task ffff88019def4600) Stack: ... Call Trace: call_timer_fn run_timer_softirq __do_softirq call_softirq do_softirq irq_exit smp_apic_timer_interrupt apic_timer_interrupt intel_idle cpuidle_idle_call cpu_idle Code: ... RIP __queue_work RSP <...> Signed-off-by:
-
James Hogan authored
commit f4dce1ff upstream. Since commit 4c21b8fd ("MIPS: seccomp: Handle indirect system calls (o32)"), syscall_get_arguments() attempts to handle o32 indirect syscall arguments by incrementing both the start argument number and the number of arguments to fetch. However only the start argument number needs to be incremented. The number of arguments does not change, they're just shifted up by one, and in fact the output array is provided by the caller and is likely only n entries long, so reading more arguments overflows the output buffer. In the case of seccomp, this results in it fetching 7 arguments starting at the 2nd one, which overflows the unsigned long args[6] in populate_seccomp_data(). This clobbers the $s0 register from syscall_trace_enter() which __seccomp_phase1_filter() saved onto the stack, into which syscall_trace_enter() had placed its syscall number argument. This caused Chromium to crash. Credit goes to Milko for tracking it down as far as $s0 being clobbered. Fixes: 4c21b8fd ("MIPS: seccomp: Handle indirect system calls (o32)") Reported-by:
Milko Leporis <milko.leporis@imgtec.com> Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12213/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Huacai Chen authored
commit 4f33f6c5 upstream. Commit be0c37c9 (MIPS: Rearrange PTE bits into fixed positions.) defines fixed PTE bits for MIPS R2. Then, commit d7b63141 (MIPS: pgtable-bits: Fix XPA damage to R6 definitions.) adds the MIPS R6 definitions in the same way as MIPS R2. But some R6 #ifdefs in the later commit are missing, so in this patch I fix that. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12164/Signed-off-by:
-
Huacai Chen authored
commit 5610b125 upstream. This patch is borrowed from x86 hpet driver and explaind below: Due to the overly intelligent design of HPETs, we need to workaround the problem that the compare value which we write is already behind the actual counter value at the point where the value hits the real compare register. This happens for two reasons: 1) We read out the counter, add the delta and write the result to the compare register. When a NMI hits between the read out and the write then the counter can be ahead of the event already. 2) The write to the compare register is delayed by up to two HPET cycles in AMD chipsets. We can work around this by reading back the compare register to make sure that the written value has hit the hardware. But that is bad performance wise for the normal case where the event is far enough in the future. As we already know that the write can be delayed by up to two cycles we can avoid the read back of the compare register completely if we make the decision whether the delta has elapsed already or not based on the following calculation: cmp = event - actual_count; If cmp is less than 64 HPET clock cycles, then we decide that the event has happened already and return -ETIME. That covers the above #1 and #2 problems which would cause a wait for HPET wraparound (~306 seconds). Signed-off-by:
-
Huacai Chen authored
commit 57548432 upstream. When Core-0 handle SMP_ASK_C0COUNT IPI, we should make other cores to see the result as soon as possible (especially when Store-Fill-Buffer is enabled). Otherwise, C0_Count syncronization makes no sense. BTW, array is more suitable than per-cpu variable for syncronization, and there is a corner case should be avoid: C0_Count of Core-0 can be really 0. Signed-off-by:
-
Dan Williams authored
commit 800dc4f4 upstream. This reverts commit 22b14523. It was originally sent in an earlier revision of the pfn_t patchset. Besides being broken, the warning is also fixed by PFN_FLAGS_MASK casting the PAGE_MASK to an unsigned long. Reported-by:
Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Cc: linux-kernel@vger.kernel.org Cc: Linux-MIPS <linux-mips@linux-mips.org> Patchwork: https://patchwork.linux-mips.org/patch/12182/Signed-off-by:
-
zengtao authored
commit 0f26922f upstream. The datatype __kernel_time_t is u32 on 32bit platform, so its subject to overflows in the timeval/timespec to cputime conversion. Currently the following functions are affected: 1. setitimer() 2. timer_create/timer_settime() 3. sys_clock_nanosleep This can happen on MIPS32 and ARM32 with "Full dynticks CPU time accounting" enabled, which is required for CONFIG_NO_HZ_FULL. Enforce u64 conversion to prevent the overflow. Fixes: 31c1fc81 ("ARM: Kconfig: allow full nohz CPU accounting") Signed-off-by:
zengtao <prime.zeng@huawei.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Cc: <fweisbec@gmail.com> Link: http://lkml.kernel.org/r/1454384314-154784-1-git-send-email-prime.zeng@huawei.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
David Gibson authored
commit 35a4933a upstream. 1e75fa8b "time: Condense timekeeper.xtime into xtime_sec" replaced a call to clocksource_cyc2ns() from timekeeping_get_ns() with an open-coded version of the same logic to avoid keeping a semi-redundant struct timespec in struct timekeeper. However, the commit also introduced a subtle semantic change - where clocksource_cyc2ns() uses purely unsigned math, the new version introduces a signed temporary, meaning that if (delta * tk->mult) has a 63-bit overflow the following shift will still give a negative result. The choice of 'maxsec' in __clocksource_updatefreq_scale() means this will generally happen if there's a ~10 minute pause in examining the clocksource. This can be triggered on a powerpc KVM guest by stopping it from qemu for a bit over 10 minutes. After resuming time has jumped backwards several minutes causing numerous problems (jiffies does not advance, msleep()s can be extended by minutes..). It doesn't happen on x86 KVM guests, because the guest TSC is effectively frozen while the guest is stopped, which is not the case for the powerpc timebase. Obviously an unsigned (64 bit) overflow will only take twice as long as a signed, 63-bit overflow. I don't know the time code well enough to know if that will still cause incorrect calculations, or if a 64-bit overflow is avoided elsewhere. Still, an incorrect forwards clock adjustment will cause less trouble than time going backwards. So, this patch removes the potential for intermediate signed overflow. Suggested-by:
Laurent Vivier <lvivier@redhat.com> Tested-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
