1. 15 12月, 2017 25 次提交
  2. 14 12月, 2017 4 次提交
    • M
      drm/drm_lease: Prevent deadlock in case drm_lease_create() fails · bd36d3ba
      Marius Vlad 提交于
      This case can been seen when creating the lease with the same objects passed.
      
      [  605.515097] 2 locks held by testapp/3337:
      [  605.519027]  #0:  (&dev->mode_config.idr_mutex){......}, at: [<ffff0000085f1664>] drm_mode_create_lease_ioctl+0x384/0x858
      [  605.530045]  #1:  (&dev->mode_config.idr_mutex){......}, at: [<ffff0000085f11bc>] drm_lease_destroy+0x2c/0x110
      
      Which was causing the process to hang:
      
      [  605.398827] [<ffff0000080856cc>] __switch_to+0x94/0xa8
      [  605.404030] [<ffff000008c05d00>] __schedule+0x1b0/0x698
      [  605.409322] [<ffff000008c06224>] schedule+0x3c/0xa8
      [  605.414260] [<ffff000008c06628>] schedule_preempt_disabled+0x20/0x38
      [  605.420677] [<ffff000008c07370>] mutex_lock_nested+0x158/0x340
      [  605.426572] [<ffff0000085f11bc>] drm_lease_destroy+0x2c/0x110
      [  605.432389] [<ffff0000085cecf0>] drm_master_put+0xc0/0xc8
      [  605.437845] [<ffff0000085f175c>] drm_mode_create_lease_ioctl+0x47c/0x858
      [  605.444612] [<ffff0000085d4460>] drm_ioctl+0x198/0x448
      [  605.449811] [<ffff000008201134>] do_vfs_ioctl+0xa4/0x748
      [  605.455192] [<ffff000008201864>] SyS_ioctl+0x8c/0xa0
      [  605.460216] [<ffff000008082f4c>] __sys_trace_return+0x0/0x4
      
      drm_mode_create_lease_ioctl() calls drm_lease_create() which acquires a lock
      on dev->mode_config.idr_mutex. In case of failure, drm_lease_create() calls
      drm_master_put() which in turn tries to acquire the same lock when calling
      drm_lease_destroy().
      
      v2: - Reverse the order at exit in case of fail, so that unlocking takes place
      before dropping the reference.
          - Include detail information about deadlock (Daniel Vetter)
      Signed-off-by: NMarius Vlad <marius-cristian.vlad@nxp.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171213181048.32719-1-marius-cristian.vlad@nxp.com
      bd36d3ba
    • L
      Merge tag 'xfs-4.15-fixes-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 7c5cac1b
      Linus Torvalds 提交于
      Pull xfs fixes from Darrick Wong:
       "Here are a few more bug fixes & cleanups for 4.15-rc4:
      
         - clean up duplicate includes
      
         - remove ancient 'no-alloc' crap code that occasionally caused hard
           fs shutdowns due to lack of proper space reservations
      
         - fix regression in FIEMAP behavior when reporting xattr extents"
      
      * tag 'xfs-4.15-fixes-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: make iomap_begin functions trim iomaps consistently
        xfs: remove "no-allocation" reservations for file creations
        fs: xfs: remove duplicate includes
      7c5cac1b
    • L
      Merge tag 'riscv-for-linus-4.15-rc4-riscv_fixes' of... · 4e746cf4
      Linus Torvalds 提交于
      Merge tag 'riscv-for-linus-4.15-rc4-riscv_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux
      
      Pull RISC-V fixes from Palmer Dabbelt:
       "This contains three small fixes:
      
         - A fix to a typo in sys_riscv_flush_icache. This only effects error
           handling, but I think it's a small and obvious enough change that
           it's sane outside the merge window.
      
         - The addition of smp_mb__after_spinlock(), which was recently
           removed due to an incorrect comment. This is largly a comment
           change (as there's a big one now), and while it's necessary for
           complience with the RISC-V memory model the lack of this fence
           shouldn't manifest as a bug on current implementations.
           Nonetheless, it still seems saner to have the fence in 4.15.
      
         - The removal of some of the HVC_RISCV_SBI driver that snuck into the
           arch port. This is compile-time dead code in 4.15 (as the driver
           isn't in yet), and during the review process we found a better way
           to implement early printk on RISC-V. While this change doesn't do
           anything, it will make staging our HVC driver easier: without this
           change the HVC driver we hope to upstream won't build on 4.15
           (because the 4.15 arch code would reference a function that no
           longer exists).
      
        I don't think this is the last patch set we'll want for 4.15: I think
        I'll want to remove some of the first-level irqchip driver that snuck
        in as well, which will look a lot like the HVC patch here. This is
        pending some asm-generic cleanup I'm doing that I haven't quite gotten
        clean enough to send out yet, though, but hopefully it'll be ready by
        next week (and still OK for that late)"
      
       * tag 'riscv-for-linus-4.15-rc4-riscv_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux:
        RISC-V: Remove unused CONFIG_HVC_RISCV_SBI code
        RISC-V: Resurrect smp_mb__after_spinlock()
        RISC-V: Logical vs Bitwise typo
      4e746cf4
    • D
      drm: rework delayed connector cleanup in connector_iter · ea497bb9
      Daniel Vetter 提交于
      PROBE_DEFER also uses system_wq to reprobe drivers, which means when
      that again fails, and we try to flush the overall system_wq (to get
      all the delayed connectore cleanup work_struct completed), we
      deadlock.
      
      Fix this by using just a single cleanup work, so that we can only
      flush that one and don't block on anything else. That means a free
      list plus locking, a standard pattern.
      
      v2:
      - Correctly free connectors only on last ref. Oops (Chris).
      - use llist_head/node (Chris).
      
      v3
      - Add init_llist_head (Chris).
      
      Fixes: a703c550 ("drm: safely free connectors from connector_iter")
      Fixes: 613051da ("drm: locking&new iterators for connector_list")
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: <stable@vger.kernel.org> # v4.11+: 613051da ("drm: locking&new iterators for connector_list"
      Cc: <stable@vger.kernel.org> # v4.11+
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Javier Martinez Canillas <javier@dowhile0.org>
      Cc: Shuah Khan <shuahkh@osg.samsung.com>
      Cc: Guillaume Tucker <guillaume.tucker@collabora.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Matt Hart <matthew.hart@linaro.org>
      Cc: Thierry Escande <thierry.escande@collabora.co.uk>
      Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
      Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171213124936.17914-1-daniel.vetter@ffwll.ch
      ea497bb9
  3. 13 12月, 2017 3 次提交
    • K
      drm: Update edid-derived drm_display_info fields at edid property set [v2] · 4b4df570
      Keith Packard 提交于
      There are a set of values in the drm_display_info structure for each
      connector which hold information derived from EDID. These are computed
      in drm_add_display_info. Before this patch, that was only called in
      drm_add_edid_modes. This meant that they were only set when EDID was
      present and never reset when EDID was not, as happened when the
      display was disconnected.
      
      One of these fields, non_desktop, is used from
      drm_mode_connector_update_edid_property, the function responsible for
      assigning the new edid value to the application-visible property.
      
      Various drivers call these two functions (drm_add_edid_modes and
      drm_mode_connector_update_edid_property) in different orders. This
      means that even when EDID is present, the drm_display_info fields may
      not have been computed at the time that
      drm_mode_connector_update_edid_property used the non_desktop value to
      set the non_desktop property.
      
      I've added a public function (drm_reset_display_info) that resets the
      drm_display_info field values to default values and then made the
      drm_add_display_info function public. These two functions are now
      called directly from drm_mode_connector_update_edid_property so that
      the drm_display_info fields are always computed from the current EDID
      information before being used in that function.
      
      This means that the drm_display_info values are often computed twice,
      once when the EDID property it set and a second time when EDID is used
      to compute modes for the device. The alternative would be to uniformly
      ensure that the values were computed once before being used, which
      would require that all drivers reliably invoke the two paths in the
      same order. The computation is inexpensive enough that it seems more
      maintainable in the long term to simply compute them in both paths.
      
      The API to drm_add_display_info has been changed so that it no longer
      takes the set of edid-based quirks as a parameter. Rather, it now
      computes those quirks itself and returns them for further use by
      drm_add_edid_modes.
      
      This patch also includes a number of 'const' additions caused by
      drm_mode_connector_update_edid_property taking a 'const struct edid *'
      parameter and wanting to pass that along to drm_add_display_info.
      
      v2: after review by Daniel Vetter <daniel.vetter@ffwll.ch>
      
      	Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and
      	drm_add_display_info.
      
      	Added FIXME in drm_mode_connector_update_edid_property about
      	potentially merging that with drm_add_edid_modes to avoid
      	the need for two driver calls.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171213084427.31199-1-keithp@keithp.com
      (danvet: cherry picked from commit 12a889bf4bca ("drm: rework delayed
      connector cleanup in connector_iter") from drm-misc-next since
      functional conflict with changes in -next and we need to make sure
      both have the right version and nothing gets lost.)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4b4df570
    • L
      Merge tag 'platform-drivers-x86-v4.15-3' of git://git.infradead.org/linux-platform-drivers-x86 · d39a01ef
      Linus Torvalds 提交于
      Pull x86 platform driver fixes from Darren Hart:
      
       - Correct an error in the evdev protocol in asus-wireless which results
         in dropped key events in recent versions of libinput
      
       - Add a quirk for keyboard lighting for a specific Dell laptop
      
       - Silence a static analysis warning regarding unchecked return values
         of small kmalloc() allocations in dell-wmi
      
      * tag 'platform-drivers-x86-v4.15-3' of git://git.infradead.org/linux-platform-drivers-x86:
        platform/x86: dell-wmi: check for kmalloc() errors
        platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state changes
        platform/x86: dell-laptop: Fix keyboard max lighting for Dell Latitude E6410
      d39a01ef
    • G
      PCI: rcar: Fix use-after-free in probe error path · 0c31f1d7
      Geert Uytterhoeven 提交于
      If CONFIG_DEBUG_SLAB=y, and no PCIe card is inserted, the kernel crashes
      during probe on r8a7791/koelsch:
      
        rcar-pcie fe000000.pcie: PCIe link down
        Unable to handle kernel paging request at virtual address 6b6b6b6b
      
      (seeing this message requires earlycon and keep_bootcon).
      
      Indeed, pci_free_host_bridge() frees the PCI host bridge, including the
      embedded rcar_pcie object, so pci_free_resource_list() must not be called
      afterwards.
      
      To fix this, move the call to pci_free_resource_list() up, and update the
      label name accordingly.
      
      Fixes: ddd535f1 ("PCI: rcar: Fix memory leak when no PCIe card is inserted")
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NSimon Horman <horms+renesas@verge.net.au>
      Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      0c31f1d7
  4. 12 12月, 2017 8 次提交