- 15 Jun, 2019 8 commits
-
-
Brian Masney authored
[ Upstream commit 90f94660 ] msm_gem_describe() would attempt to dereference a NULL pointer via the address space pointer when no IOMMU is present. Correct this by adding the appropriate check. Signed-off-by:
Brian Masney <masneyb@onstation.org> Fixes: 575f0485 ("drm/msm: Clean up and enhance the output of the 'gem' debugfs node") Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190513234105.7531-2-masneyb@onstation.orgSigned-off-by:
Sasha Levin <sashal@kernel.org>
-
Li Rongqing authored
[ Upstream commit d6a2946a ] msgctl10 of ltp triggers the following lockup When CONFIG_KASAN is enabled on large memory SMP systems, the pages initialization can take a long time, if msgctl10 requests a huge block memory, and it will block rcu scheduler, so release cpu actively. After adding schedule() in free_msg, free_msg can not be called when holding spinlock, so adding msg to a tmp list, and free it out of spinlock rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-1 rcu_node (CPUs 16-31): P32505 rcu: Tasks blocked on level-1 rcu_node (CPUs 48-63): P34978 rcu: (detected by 11, t=35024 jiffies, g=44237529, q=16542267) msgctl10 R running task 21608 32505 2794 0x00000082 Call Trace: preempt_schedule_irq+0x4c/0xb0 retint_kernel+0x1b/0x2d RIP: 0010:__is_insn_slot_addr+0xfb/0x250 Code: 82 1d 00 48 8b 9b 90 00 00 00 4c 89 f7 49 c1 ee 03 e8 59 83 1d 00 48 b8 00 00 00 00 00 fc ff df 4c 39 eb 48 89 9d 58 ff ff ff <41> c6 04 06 f8 74 66 4c 8d 75 98 4c 89 f1 48 c1 e9 03 48 01 c8 48 RSP: 0018:ffff88bce041f758 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: dffffc0000000000 RBX: ffffffff8471bc50 RCX: ffffffff828a2a57 RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff88bce041f780 RBP: ffff88bce041f828 R08: ffffed15f3f4c5b3 R09: ffffed15f3f4c5b3 R10: 0000000000000001 R11: ffffed15f3f4c5b2 R12: 000000318aee9b73 R13: ffffffff8471bc50 R14: 1ffff1179c083ef0 R15: 1ffff1179c083eec kernel_text_address+0xc1/0x100 __kernel_text_address+0xe/0x30 unwind_get_return_address+0x2f/0x50 __save_stack_trace+0x92/0x100 create_object+0x380/0x650 __kmalloc+0x14c/0x2b0 load_msg+0x38/0x1a0 do_msgsnd+0x19e/0xcf0 do_syscall_64+0x117/0x400 entry_SYSCALL_64_after_hwframe+0x49/0xbe rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-1 rcu_node (CPUs 0-15): P32170 rcu: (detected by 14, t=35016 jiffies, g=44237525, q=12423063) msgctl10 R running task 21608 32170 32155 0x00000082 Call Trace: preempt_schedule_irq+0x4c/0xb0 retint_kernel+0x1b/0x2d RIP: 0010:lock_acquire+0x4d/0x340 Code: 48 81 ec c0 00 00 00 45 89 c6 4d 89 cf 48 8d 6c 24 20 48 89 3c 24 48 8d bb e4 0c 00 00 89 74 24 0c 48 c7 44 24 20 b3 8a b5 41 <48> c1 ed 03 48 c7 44 24 28 b4 25 18 84 48 c7 44 24 30 d0 54 7a 82 RSP: 0018:ffff88af83417738 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13 RAX: dffffc0000000000 RBX: ffff88bd335f3080 RCX: 0000000000000002 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88bd335f3d64 RBP: ffff88af83417758 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffffed13f3f745b2 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 is_bpf_text_address+0x32/0xe0 kernel_text_address+0xec/0x100 __kernel_text_address+0xe/0x30 unwind_get_return_address+0x2f/0x50 __save_stack_trace+0x92/0x100 save_stack+0x32/0xb0 __kasan_slab_free+0x130/0x180 kfree+0xfa/0x2d0 free_msg+0x24/0x50 do_msgrcv+0x508/0xe60 do_syscall_64+0x117/0x400 entry_SYSCALL_64_after_hwframe+0x49/0xbe Davidlohr said: "So after releasing the lock, the msg rbtree/list is empty and new calls will not see those in the newly populated tmp_msg list, and therefore they cannot access the delayed msg freeing pointers, which is good. Also the fact that the node_cache is now freed before the actual messages seems to be harmless as this is wanted for msg_insert() avoiding GFP_ATOMIC allocations, and after releasing the info->lock the thing is freed anyway so it should not change things" Link: http://lkml.kernel.org/r/1552029161-4957-1-git-send-email-lirongqing@baidu.comSigned-off-by:
Li RongQing <lirongqing@baidu.com> Signed-off-by:
Zhang Yu <zhangyu31@baidu.com> Reviewed-by:
Davidlohr Bueso <dbueso@suse.de> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Christian Brauner authored
[ Upstream commit e260ad01 ] Currently when userspace gives us a values that overflow e.g. file-max and other callers of __do_proc_doulongvec_minmax() we simply ignore the new value and leave the current value untouched. This can be problematic as it gives the illusion that the limit has indeed be bumped when in fact it failed. This commit makes sure to return EINVAL when an overflow is detected. Please note that this is a userspace facing change. Link: http://lkml.kernel.org/r/20190210203943.8227-4-christian@brauner.ioSigned-off-by:
Christian Brauner <christian@brauner.io> Acked-by:
Luis Chamberlain <mcgrof@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Joe Lawrence <joe.lawrence@redhat.com> Cc: Waiman Long <longman@redhat.com> Signed-off-by:
-
Hou Tao authored
[ Upstream commit bd8309de ] fsync() needs to make sure the data & meta-data of file are persistent after the return of fsync(), even when a power-failure occurs later. In the case of fat-fs, the FAT belongs to the meta-data of file, so we need to issue a flush after the writeback of FAT instead before. Also bail out early when any stage of fsync fails. Link: http://lkml.kernel.org/r/20190409030158.136316-1-houtao1@huawei.comSigned-off-by:
Hou Tao <houtao1@huawei.com> Acked-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Jan Kara <jack@suse.cz> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 23015b22 ] In case create_workqueue fails, the fix releases resources and returns -ENOMEM to avoid NULL pointer dereference. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Acked-by:
Alexandre Bounine <alex.bou9@gmail.com> Cc: Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Jonas Karlman authored
[ Upstream commit 5c5b90f5 ] Those calls are needed to restore a clean PM state when the probe fails or when the driver is unloaded such that future ->probe() calls can initialize runtime PM again. Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Jonas Karlman authored
[ Upstream commit fc8670d1 ] media_device_cleanup() and v4l2_m2m_unregister_media_controller() were missing in the probe error path. While at it, re-order calls in the remove path to unregister/cleanup things in the reverse order they were initialized/registered. Signed-off-by:
-
Dave Airlie authored
[ Upstream commit dbb92471 ] This reverts commit 8059add0. This commit while seemingly a good idea, breaks a radv check, for a node being master because something succeeds where it failed before now. Apply the Linus rule, revert early and try again, we don't break userspace. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
- 11 Jun, 2019 32 commits
-
-
Greg Kroah-Hartman authored
-
David Ahern authored
commit 9b3040a6 upstream. Define __ipv4_neigh_lookup_noref to return NULL when CONFIG_INET is disabled. Fixes: 4b2a2bfe ("neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
commit 4cdd17ba upstream. We need to compute the uart state only on the first open. This is usually what is done in the ->install hook. serial_core used to do this in ->open on every open. So move it to ->install. As a side effect, it ensures the state is set properly in the window after tty_init_dev is called, but before uart_open. This fixes a bunch of races between tty_open and flush_to_ldisc we were dealing with recently. One of such bugs was attempted to fix in commit fedb5760 (serial: fix race between flush_to_ldisc and tty_open), but it only took care of a couple of functions (uart_start and uart_unthrottle). I was able to reproduce the crash on a SLE system, but in uart_write_room which is also called from flush_to_ldisc via process_echoes. I was *unable* to reproduce the bug locally. It is due to having this patch in my queue since 2012! general protection fault: 0000 [#1] SMP KASAN PTI CPU: 1 PID: 5 Comm: kworker/u4:0 Tainted: G L 4.12.14-396-default #1 SLE15-SP1 (unreleased) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c89-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound flush_to_ldisc task: ffff8800427d8040 task.stack: ffff8800427f0000 RIP: 0010:uart_write_room+0xc4/0x590 RSP: 0018:ffff8800427f7088 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 000000000000002f RSI: 00000000000000ee RDI: ffff88003888bd90 RBP: ffffffffb9545850 R08: 0000000000000001 R09: 0000000000000400 R10: ffff8800427d825c R11: 000000000000006e R12: 1ffff100084fee12 R13: ffffc900004c5000 R14: ffff88003888bb28 R15: 0000000000000178 FS: 0000000000000000(0000) GS:ffff880043300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000561da0794148 CR3: 000000000ebf4000 CR4: 00000000000006e0 Call Trace: tty_write_room+0x6d/0xc0 __process_echoes+0x55/0x870 n_tty_receive_buf_common+0x105e/0x26d0 tty_ldisc_receive_buf+0xb7/0x1c0 tty_port_default_receive_buf+0x107/0x180 flush_to_ldisc+0x35d/0x5c0 ... 0 in rbx means tty->driver_data is NULL in uart_write_room. 0x178 is tried to be dereferenced (0x178 >> 3 is 0x2f in rdx) at uart_write_room+0xc4. 0x178 is exactly (struct uart_state *)NULL->refcount used in uart_port_lock from uart_write_room. So revert the upstream commit here as my local patch should fix the whole family. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Li RongQing <lirongqing@baidu.com> Cc: Wang Li <wangli39@baidu.com> Cc: Zhang Yu <zhangyu31@baidu.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Helen Koike authored
commit 332af874 upstream. Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <stable@vger.kernel.org> # v4.20+ Fixes: 674e78ac ("drm/amd/display: Add fast path for cursor plane updates") Suggested-by:
Helen Koike <helen.koike@collabora.com> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Tina Zhang authored
commit 387a4c2b upstream. Stack struct intel_gvt_gtt_entry value needs to be initialized before being used, as the fields may contain garbage values. W/o this patch, set_ggtt_entry prints: ------------------------------------- 274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900 274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001 274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900 0x9bed8000 is the stack grabage. W/ this patch, set_ggtt_entry prints: ------------------------------------ 274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900 274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001 274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900 v2: - Initialize during declaration. (Zhenyu) Fixes: 7598e870 ("drm/i915/gvt: Missed to cancel dma map for ggtt entries") Cc: stable@vger.kernel.org # v4.20+ Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Tina Zhang <tina.zhang@intel.com> Signed-off-by:
-
Helen Koike authored
commit 89a4aac0 upstream. In the case of a normal sync update, the preparation of framebuffers (be it calling drm_atomic_helper_prepare_planes() or doing setups with drm_framebuffer_get()) are performed in the new_state and the respective cleanups are performed in the old_state. In the case of async updates, the preparation is also done in the new_state but the cleanups are done in the new_state (because updates are performed in place, i.e. in the current state). The current code blocks async udpates when the fb is changed, turning async updates into sync updates, slowing down cursor updates and introducing regressions in igt tests with errors of type: "CRITICAL: completed 97 cursor updated in a period of 30 flips, we expect to complete approximately 15360 updates, with the threshold set at 7680" Fb changes in async updates were prevented to avoid the following scenario: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1 - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong) Where we have a single call to prepare fb2 but double cleanup call to fb2. To solve the above problems, instead of blocking async fb changes, we place the old framebuffer in the new_state object, so when the code performs cleanups in the new_state it will cleanup the old_fb and we will have the following scenario instead: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 Where calls to prepare/cleanup are balanced. Cc: <stable@vger.kernel.org> # v4.14+ Fixes: 25dc194b ("drm: Block fb changes for async plane updates") Suggested-by:
-
Jonathan Corbet authored
commit 551bd336 upstream. With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the docs build fails with: Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent: Global GTT Fence Handling ~~~~~~~~~~~~~~~~~~~~~~~~~ reST markup error: Documentation/gpu/i915.rst:403: (SEVERE/4) Title level inconsistent: I "fixed" it by changing the subsections in i915.rst, but that didn't seem like the correct change. It turns out that a couple of i915 files create their own subsections in kerneldoc comments using apostrophes as the heading marker: Layout '''''' That breaks the normal subsection marker ordering, and newer Sphinx is rather more strict about enforcing that ordering. So fix the offending comments to make Sphinx happy. (This is unfortunate, in that kerneldoc comments shouldn't need to be aware of where they might be included in the heading hierarchy, but I don't see a better way around it). Cc: stable@vger.kernel.org # v4.14+ Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Weinan authored
commit a8c2d5ab upstream. "To track whether a request has started on HW, we can emit a breadcrumb at the beginning of the request and check its timeline's HWSP to see if the breadcrumb has advanced past the start of this request." It means all the request which timeline's has_init_breadcrumb is true, then the emit_init_breadcrumb process must have before emitting the real commands, otherwise, the scheduler might get a wrong state of this request during reset. If the request is exactly the guilty one, the scheduler won't terminate it with the wrong state. To avoid this, do emit_init_breadcrumb for all the requests from gvt. v2: cc to stable kernel Fixes: 85474441 ("drm/i915: Identify active requests") Cc: stable@vger.kernel.org Acked-by:
Weinan <weinan.z.li@intel.com> Signed-off-by:
-
Daniel Drake authored
commit 396dd814 upstream. On many (all?) the Gemini Lake systems we work with, there is frequent momentary graphical corruption at the top of the screen, and it seems that disabling framebuffer compression can avoid this. The ticket was reported 6 months ago and has already affected a multitude of users, without any real progress being made. So, lets disable framebuffer compression on GeminiLake until a solution is found. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108085 Fixes: fd7d6c5c ("drm/i915: enable FBC on gen9+ too") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.11+ Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Drake <drake@endlessm.com> Signed-off-by:
Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Louis Li authored
commit ce0e22f5 upstream. [What] vce ring test fails consistently during resume in s3 cycle, due to mismatch read & write pointers. On debug/analysis its found that rptr to be compared is not being correctly updated/read, which leads to this failure. Below is the failure signature: [drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed [drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block <vce_v3_0> failed -110 [drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110). [How] fetch rptr appropriately, meaning move its read location further down in the code flow. With this patch applied the s3 failure is no more seen for >5k s3 cycles, which otherwise is pretty consistent. V2: remove reduntant fetch of rptr Signed-off-by:
Louis Li <Ching-shih.Li@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Harry Wentland authored
commit ada637e7 upstream. [WHY] We only want to load DMCU FW on Picasso and Raven 2, not on Raven 1. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
Alex Deucher authored
commit 5887a599 upstream. Not necessary on soc15 and breaks driver reload on server cards. Acked-by:
Amber Lin <Amber.Lin@amd.com> Signed-off-by:
-
Chris Wilson authored
commit d90c06d5 upstream. This was supposed to be a mask of all known rings, but it is being used by execbuffer to filter out invalid rings, and so is instead mapping high unused values onto valid rings. Instead of a mask of all known rings, we need it to be the mask of all possible rings. Fixes: 549f7365 ("drm/i915: Enable SandyBridge blitter ring") Fixes: de1add36 ("drm/i915: Decouple execbuf uAPI from internal implementation") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v4.6+ Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190301140404.26690-21-chris@chris-wilson.co.ukSigned-off-by:
-
Aaron Liu authored
commit bdb1ccb0 upstream. In amdgpu_atif_handler, when hotplug event received, remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check. This bit's check will cause missing system resume. Signed-off-by:
Aaron Liu <aaron.liu@amd.com> Reviewed-by:
-
Christian König authored
commit 2e26ccb1 upstream. Instead of the closest reference divider prefer the lowest, this fixes flickering issues on HP Compaq nx9420. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=108514Suggested-by:
Paul Dufresne <dufresnep@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit 9d6fea57 upstream. In case we need to use them for GPU reset prior initializing the asic. Fixes a crash if the driver attempts to reset the GPU at driver load time. Acked-by:
-
Mario Kleiner authored
commit 0cbd0adc upstream. As discussed with Nicholas and Daniel Vetter (patchwork link to discussion below), the VRR timestamping behaviour produced utterly useless and bogus vblank/pageflip timestamps. We have found a way to fix this and provide sane behaviour. As of Linux 5.2, the amdgpu driver will be able to provide exactly the same vblank / pageflip timestamp semantic in variable refresh rate mode as in standard fixed refresh rate mode. This is achieved by deferring core vblank handling (drm_crtc_handle_vblank()) until the end of front porch, and also defer the sending of pageflip completion events until end of front porch, when we can safely compute correct pageflip/vblank timestamps. The same approach will be possible for other VRR capable kms drivers, so we can actually have sane and useful timestamps in VRR mode. This patch removes the section of the docs that describes the broken timestamp behaviour present in Linux 5.0/5.1. Fixes: ab7a664f ("drm: Document variable refresh properties") Link: https://patchwork.freedesktop.org/patch/285333/Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
-
Ryan Pavlik authored
commit 29054230 upstream. Add two EDID vendor/product pairs used across a variety of Sensics products, as well as the OSVR HDK and HDK 2. Signed-off-by:
Ryan Pavlik <ryan.pavlik@collabora.com> Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20181203164644.13974-1-ryan.pavlik@collabora.com Cc: <stable@vger.kernel.org> # v4.15+ Signed-off-by:
-
Dave Airlie authored
commit b30a43ac upstream. There was a nouveau DDX that relied on legacy context ioctls to work, but we fixed it years ago, give distros that have a modern DDX the option to break the uAPI and close the mess of holes that legacy context support is. Full context of the story: commit 0e975980 Author: Peter Antoine <peter.antoine@intel.com> Date: Tue Jun 23 08:18:49 2015 +0100 drm: Turn off Legacy Context Functions The context functions are not used by the i915 driver and should not be used by modeset drivers. These driver functions contain several bugs and security holes. This change makes these functions optional can be turned on by a setting, they are turned off by default for modeset driver with the exception of the nouvea driver that may require them with an old version of libdrm. The previous attempt was commit 7c510133 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 8 15:41:21 2013 +0200 drm: mark context support as a legacy subsystem but this had to be reverted commit c21eb21c Author: Dave Airlie <airlied@redhat.com> Date: Fri Sep 20 08:32:59 2013 +1000 Revert "drm: mark context support as a legacy subsystem" v2: remove returns from void function, and formatting (Daniel Vetter) v3: - s/Nova/nouveau/ in the commit message, and add references to the previous attempts - drop the part touching the drm hw lock, that should be a separate patch. Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2) Cc: Peter Antoine <peter.antoine@intel.com> (v2) Reviewed-by:
Peter Antoine <peter.antoine@intel.com> Signed-off-by:
-
Andres Rodriguez authored
commit 30d62d44 upstream. Add vendor/product pairs for the Valve Index HMDs. Signed-off-by:
Andres Rodriguez <andresx7@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Cc: <stable@vger.kernel.org> # v4.15 Signed-off-by:
-
Helen Koike authored
commit 474d952b upstream. Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Cc: <stable@vger.kernel.org> # v4.14+ Fixes: 224a4c97 ("drm/msm: update cursors asynchronously through atomic") Suggested-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Patrik Jakobsson authored
commit 7c420636 upstream. Some machines have an lvds child device in vbt even though a panel is not attached. To make detection more reliable we now also check the lvds config bits available in the vbt. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766 Cc: stable@vger.kernel.org Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416114607.1072-1-patrik.r.jakobsson@gmail.comSigned-off-by:
-
Helen Koike authored
commit c16b8555 upstream. Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <stable@vger.kernel.org> # v4.19+ Fixes: 539c320b ("drm/vc4: update cursors asynchronously through atomic") Suggested-by:
-
Helen Koike authored
commit d985a353 upstream. In the case of async update, modifications are done in place, i.e. in the current plane state, so the new_state is prepared and the new_state is cleaned up (instead of the old_state, unlike what happens in a normal sync update). To cleanup the old_fb properly, it needs to be placed in the new_state in the end of async_update, so cleanup call will unreference the old_fb correctly. Also, the previous code had a: plane_state = plane->funcs->atomic_duplicate_state(plane); ... swap(plane_state, plane->state); if (plane->state->fb && plane->state->fb != new_state->fb) { ... } Which was wrong, as the fb were just assigned to be equal, so this if statement nevers evaluates to true. Another details is that the function drm_crtc_vblank_get() can only be called when vop->is_enabled is true, otherwise it has no effect and trows a WARN_ON(). Calling drm_atomic_set_fb_for_plane() (which get a referent of the new fb and pus the old fb) is not required, as it is taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Fixes: 15609559 ("drm/rockchip: update cursors asynchronously through atomic.") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by:
-
Dan Carpenter authored
commit bd17cc5a upstream. The limit here is supposed to be how much of the page is left, but it's just using PAGE_SIZE as the limit. The other thing to remember is that snprintf() returns the number of bytes which would have been copied if we had had enough room. So that means that if we run out of space then this code would end up passing a negative value as the limit and the kernel would print an error message. I have change the code to use scnprintf() which returns the number of bytes that were successfully printed (not counting the NUL terminator). Fixes: c92316bf ("test_firmware: add batched firmware tests") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Dan Carpenter authored
commit 110080ce upstream. There are a couple potential integer overflows here. round_up(m->size + (m->addr & ~PAGE_MASK), PAGE_SIZE); The first thing is that the "m->size + (...)" addition could overflow, and the second is that round_up() overflows to zero if the result is within PAGE_SIZE of the type max. In this code, the "m->size" variable is an u64 but we're saving the result in "map_size" which is an unsigned long and genwqe_user_vmap() takes an unsigned long as well. So I have used ULONG_MAX as the upper bound. From a practical perspective unsigned long is fine/better than trying to change all the types to u64. Fixes: eaf4722d ("GenWQE Character device and DDCB queue") Signed-off-by:
-
Paul Burton authored
commit e4f2d1af upstream. The pistachio platform uses the U-Boot bootloader & generally boots a kernel in the uImage format. As such it's useful to build one when building the kernel, but to do so currently requires the user to manually specify a uImage target on the make command line. Make uImage.gz the pistachio platform's default build target, so that the default is to build a kernel image that we can actually boot on a board such as the MIPS Creator Ci40. Marked for stable backport as far as v4.1 where pistachio support was introduced. This is primarily useful for CI systems such as kernelci.org which will benefit from us building a suitable image which can then be booted as part of automated testing, extending our test coverage to the affected stable branches. Signed-off-by:
Paul Burton <paul.burton@mips.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Tested-by:
-
Paul Burton authored
commit 074a1e11 upstream. The virt_addr_valid() function is meant to return true iff virt_to_page() will return a valid struct page reference. This is true iff the address provided is found within the unmapped address range between PAGE_OFFSET & MAP_BASE, but we don't currently check for that condition. Instead we simply mask the address to obtain what will be a physical address if the virtual address is indeed in the desired range, shift it to form a PFN & then call pfn_valid(). This can incorrectly return true if called with a virtual address which, after masking, happens to form a physical address corresponding to a valid PFN. For example we may vmalloc an address in the kernel mapped region starting a MAP_BASE & obtain the virtual address: addr = 0xc000000000002000 When masked by virt_to_phys(), which uses __pa() & in turn CPHYSADDR(), we obtain the following (bogus) physical address: addr = 0x2000 In a common system with PHYS_OFFSET=0 this will correspond to a valid struct page which should really be accessed by virtual address PAGE_OFFSET+0x2000, causing virt_addr_valid() to incorrectly return 1 indicating that the original address corresponds to a struct page. This is equivalent to the ARM64 change made in commit ca219452 ("arm64: Correctly bounds check virt_addr_valid"). This fixes fallout when hardened usercopy is enabled caused by the related commit 517e1fbe ("mm/usercopy: Drop extra is_vmalloc_or_module() check") which removed a check for the vmalloc range that was present from the introduction of the hardened usercopy feature. Signed-off-by:
Julien Cristau <jcristau@debian.org> Reviewed-by:
YunQiang Su <ysu@wavecomp.com> URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929366 Cc: stable@vger.kernel.org # v4.12+ Cc: linux-mips@vger.kernel.org Cc: Yunqiang Su <ysu@wavecomp.com> Signed-off-by:
-
Roger Pau Monne authored
commit 1d5c76e6 upstream. There's no reason to request physically contiguous memory for those allocations. [boris: added CC to stable] Cc: stable@vger.kernel.org Reported-by:
Ian Jackson <ian.jackson@citrix.com> Signed-off-by:
Roger Pau Monné <roger.pau@citrix.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Acked-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Sagi Grimberg authored
commit 5651cd3c upstream. When the controller supports less queues than requested, we should make sure that queue mapping does the right thing and not assume that all queues are available. This fixes a crash when the controller supports less queues than requested. The rules are: 1. if no write/poll queues are requested, we assign the available queues to the default queue map. The default and read queue maps share the existing queues. 2. if write queues are requested: - first make sure that read queue map gets the requested nr_io_queues count - then grant the default queue map the minimum between the requested nr_write_queues and the remaining queues. If there are no available queues to dedicate to the default queue map, fallback to (1) and share all the queues in the existing queue map. 3. if poll queues are requested: - map the remaining queues to the poll queue map. Also, provide a log indication on how we constructed the different queue maps. Reported-by:
Harris, James R <james.r.harris@intel.com> Reviewed-by:
Max Gurtovoy <maxg@mellanox.com> Tested-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Gerald Schaefer authored
commit 962f0af8 upstream. Commit 0aaba41b ("s390: remove all code using the access register mode") removed access register mode from the kernel, and also from the address space detection logic. However, user space could still switch to access register mode (trans_exc_code == 1), and exceptions in that mode would not be correctly assigned. Fix this by adding a check for trans_exc_code == 1 to get_fault_type(), and remove the wrong comment line before that function. Fixes: 0aaba41b ("s390: remove all code using the access register mode") Reviewed-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Cc: <stable@vger.kernel.org> # v4.15+ Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Robert Hancock authored
commit 49b80958 upstream. This driver does not support reading more than 255 bytes at once because the register for storing the number of bytes to read is only 8 bits. Add a max_read_len quirk to enforce this. This was found when using this driver with the SFP driver, which was previously reading all 256 bytes in the SFP EEPROM in one transaction. This caused a bunch of hard-to-debug errors in the xiic driver since the driver/logic was treating the number of bytes to read as zero. Rejecting transactions that aren't supported at least allows the problem to be diagnosed more easily. Signed-off-by:
Robert Hancock <hancock@sedsystems.ca> Reviewed-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org Signed-off-by:
-
