1. 15 Jun, 2019 31 commits
  2. 11 Jun, 2019 9 commits
    • Greg Kroah-Hartman's avatar
      Linux 5.1.9 · 2df16141
      Greg Kroah-Hartman authored
      2df16141
    • David Ahern's avatar
      ipv4: Define __ipv4_neigh_lookup_noref when CONFIG_INET is disabled · 24741972
      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: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24741972
    • Jiri Slaby's avatar
      TTY: serial_core, add ->install · b6dc42e5
      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: default avatarJiri 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: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6dc42e5
    • Helen Koike's avatar
      drm/amd: fix fb references in async update · fda8c1c5
      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: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: default avatarHelen Koike <helen.koike@collabora.com>
      Reviewed-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-3-helen.koike@collabora.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fda8c1c5
    • Tina Zhang's avatar
      drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack · 9f8bf917
      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: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarTina Zhang <tina.zhang@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f8bf917
    • Helen Koike's avatar
      drm: don't block fb changes for async plane updates · 27e8c560
      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: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: default avatarHelen Koike <helen.koike@collabora.com>
      Reviewed-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Reviewed-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-6-helen.koike@collabora.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27e8c560
    • Jonathan Corbet's avatar
      drm/i915: Maintain consistent documentation subsection ordering · 151fbcb9
      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: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      151fbcb9
    • Weinan's avatar
      drm/i915/gvt: emit init breadcrumb for gvt request · 67150514
      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: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarWeinan <weinan.z.li@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67150514
    • Daniel Drake's avatar
      drm/i915/fbc: disable framebuffer compression on GeminiLake · 4ab4dde3
      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: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190423092810.28359-1-jian-hong@endlessm.com
      (cherry picked from commit 1d25724b)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4ab4dde3