1. 15 12月, 2017 2 次提交
    • C
      lib/rbtree,drm/mm: add rbtree_replace_node_cached() · 338f1d9d
      Chris Wilson 提交于
      Add a variant of rbtree_replace_node() that maintains the leftmost cache
      of struct rbtree_root_cached when replacing nodes within the rbtree.
      
      As drm_mm is the only rb_replace_node() being used on an interval tree,
      the mistake looks fairly self-contained.  Furthermore the only user of
      drm_mm_replace_node() is its testsuite...
      
      Testcase: igt/drm_mm/replace
      
      Link: http://lkml.kernel.org/r/20171122100729.3742-1-chris@chris-wilson.co.uk
      Link: https://patchwork.freedesktop.org/patch/msgid/20171109212435.9265-1-chris@chris-wilson.co.uk
      Fixes: f808c13f ("lib/interval_tree: fast overlap detection")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Acked-by: NDavidlohr Bueso <dbueso@suse.de>
      Cc: Jérôme Glisse <jglisse@redhat.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      338f1d9d
    • M
      virtio_mmio: fix devm cleanup · c2e90800
      Mark Rutland 提交于
      Recent rework of the virtio_mmio probe/remove paths balanced a
      devm_ioremap() with an iounmap() rather than its devm variant. This ends
      up corrupting the devm datastructures, and results in the following
      boot-time splat on arm64 under QEMU 2.9.0:
      
      [    3.450397] ------------[ cut here ]------------
      [    3.453822] Trying to vfree() nonexistent vm area (00000000c05b4844)
      [    3.460534] WARNING: CPU: 1 PID: 1 at mm/vmalloc.c:1525 __vunmap+0x1b8/0x220
      [    3.475898] Kernel panic - not syncing: panic_on_warn set ...
      [    3.475898]
      [    3.493933] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc3 #1
      [    3.513109] Hardware name: linux,dummy-virt (DT)
      [    3.525382] Call trace:
      [    3.531683]  dump_backtrace+0x0/0x368
      [    3.543921]  show_stack+0x20/0x30
      [    3.547767]  dump_stack+0x108/0x164
      [    3.559584]  panic+0x25c/0x51c
      [    3.569184]  __warn+0x29c/0x31c
      [    3.576023]  report_bug+0x1d4/0x290
      [    3.586069]  bug_handler.part.2+0x40/0x100
      [    3.597820]  bug_handler+0x4c/0x88
      [    3.608400]  brk_handler+0x11c/0x218
      [    3.613430]  do_debug_exception+0xe8/0x318
      [    3.627370]  el1_dbg+0x18/0x78
      [    3.634037]  __vunmap+0x1b8/0x220
      [    3.648747]  vunmap+0x6c/0xc0
      [    3.653864]  __iounmap+0x44/0x58
      [    3.659771]  devm_ioremap_release+0x34/0x68
      [    3.672983]  release_nodes+0x404/0x880
      [    3.683543]  devres_release_all+0x6c/0xe8
      [    3.695692]  driver_probe_device+0x250/0x828
      [    3.706187]  __driver_attach+0x190/0x210
      [    3.717645]  bus_for_each_dev+0x14c/0x1f0
      [    3.728633]  driver_attach+0x48/0x78
      [    3.740249]  bus_add_driver+0x26c/0x5b8
      [    3.752248]  driver_register+0x16c/0x398
      [    3.757211]  __platform_driver_register+0xd8/0x128
      [    3.770860]  virtio_mmio_init+0x1c/0x24
      [    3.782671]  do_one_initcall+0xe0/0x398
      [    3.791890]  kernel_init_freeable+0x594/0x660
      [    3.798514]  kernel_init+0x18/0x190
      [    3.810220]  ret_from_fork+0x10/0x18
      
      To fix this, we can simply rip out the explicit cleanup that the devm
      infrastructure will do for us when our probe function returns an error
      code, or when our remove function returns.
      
      We only need to ensure that we call put_device() if a call to
      register_virtio_device() fails in the probe path.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Fixes: 7eb781b1 ("virtio_mmio: add cleanup for virtio_mmio_probe")
      Fixes: 25f32223 ("virtio_mmio: add cleanup for virtio_mmio_remove")
      Cc: Cornelia Huck <cohuck@redhat.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: weiping zhang <zhangweiping@didichuxing.com>
      Cc: virtualization@lists.linux-foundation.org
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NCornelia Huck <cohuck@redhat.com>
      c2e90800
  2. 14 12月, 2017 2 次提交
    • 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
    • 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 4 次提交
    • 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
    • A
      USB: core: prevent malicious bNumInterfaces overflow · 48a4ff1c
      Alan Stern 提交于
      A malicious USB device with crafted descriptors can cause the kernel
      to access unallocated memory by setting the bNumInterfaces value too
      high in a configuration descriptor.  Although the value is adjusted
      during parsing, this adjustment is skipped in one of the error return
      paths.
      
      This patch prevents the problem by setting bNumInterfaces to 0
      initially.  The existing code already sets it to the proper value
      after parsing is complete.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48a4ff1c
    • G
      Revert "USB: core: only clean up what we allocated" · cf4df407
      Greg Kroah-Hartman 提交于
      This reverts commit 32fd87b3.
      
      Alan wrote a better fix for this...
      
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf4df407
    • 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 9 次提交
  5. 11 12月, 2017 9 次提交
    • M
      ipmi_si: fix crash on parisc · 51614b26
      Mikulas Patocka 提交于
      This patch fixes ipmi crash on parisc introduced in the kernel 4.15-rc.
      The pointer io.io_setup is not initialized and thus it causes crash in
      try_smi_init when attempting to call new_smi->io.io_setup.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      51614b26
    • C
      ipmi_si: Fix oops with PCI devices · 1ac8aa8d
      Corey Minyard 提交于
      When the IPMI PCI code was split out, some code was consolidated for
      setting the io_setup field in the io structure.  The PCI code needed
      this set before registration to probe register spacing, though, so
      restore the old code for that function.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197999Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Tested-by: NMeelis Roos <mroos@linux.ee>
      1ac8aa8d
    • R
      PM / sleep: Avoid excess pm_runtime_enable() calls in device_resume() · 3487972d
      Rafael J. Wysocki 提交于
      Middle-layer code doing suspend-time optimizations for devices with
      the DPM_FLAG_SMART_SUSPEND flag set (currently, the PCI bus type and
      the ACPI PM domain) needs to make the core skip ->thaw_early and
      ->thaw callbacks for those devices in some cases and it sets the
      power.direct_complete flag for them for this purpose.
      
      However, it turns out that setting power.direct_complete outside of
      the PM core is a bad idea as it triggers an excess invocation of
      pm_runtime_enable() in device_resume().
      
      For this reason, provide a helper to clear power.is_late_suspended
      and power.is_suspended to be invoked by the middle-layer code in
      question instead of setting power.direct_complete and make that code
      call the new helper.
      
      Fixes: c4b65157 (PCI / PM: Take SMART_SUSPEND driver flag into account)
      Fixes: 05087360 (ACPI / PM: Take SMART_SUSPEND driver flag into account)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      3487972d
    • C
      mmc: core: apply NO_CMD23 quirk to some specific cards · 91516a2a
      Christoph Fritz 提交于
      To get an usdhc Apacer and some ATP SD cards work reliable, CMD23 needs
      to be disabled.  This has been tested on i.MX6 (sdhci-esdhc) and rk3288
      (dw_mmc-rockchip).
      
      Without this patch on i.MX6 (sdhci-esdhc):
      
       $ dd if=/dev/urandom of=/mnt/test bs=1M count=10 conv=fsync
      
          | <mmc0: starting CMD23 arg 00000400 flags 00000015>
          | mmc0: starting CMD25 arg 00a71f00 flags 000000b5
          | mmc0:     blksz 512 blocks 1024 flags 00000100 tsac 3000 ms nsac 0
          | mmc0:     CMD12 arg 00000000 flags 0000049d
          | sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
          | mmc0: Timeout waiting for hardware interrupt.
      
      Without this patch on rk3288 (dw_mmc-rockchip):
      
          | mmc1: Card stuck in programming state! mmcblk1 card_busy_detect
          | dwmmc_rockchip ff0c0000.dwmmc: Busy; trying anyway
          | mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz,
          | actual 400000HZ div = 0)
          | mmc1: card never left busy state
          | mmc1: tried to reset card, got error -110
          | blk_update_request: I/O error, dev mmcblk1, sector 139778
          | Buffer I/O error on dev mmcblk1p1, logical block 131586, lost async
          | page write
      Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
      Cc: <stable@vger.kernel.org> # v4.14+
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      91516a2a
    • M
      usb: dwc2: Fix TxFIFOn sizes and total TxFIFO size issues · 9273083a
      Minas Harutyunyan 提交于
      In host mode reading from DPTXSIZn returning invalid value in
      dwc2_check_param_tx_fifo_sizes function.
      
      In total TxFIFO size calculations unnecessarily reducing by ep_info.
      hw->total_fifo_size can be fully allocated for FIFO's.
      
      Added num_dev_in_eps member in dwc2_hw_params structure to save number
      of IN EPs.
      
      Added g_tx_fifo_size array in dwc2_hw_params structure to store power
      on reset values of DPTXSIZn registers in forced device mode.
      
      Updated dwc2_hsotg_tx_fifo_count() function to get TxFIFO count from
      num_dev_in_eps.
      
      Updated dwc2_get_dev_hwparams() function to store DPTXFSIZn in
      g_tx_fifo_size array.
      
      dwc2_get_host/dev_hwparams() functions call moved after num_dev_in_eps
      set from hwcfg4.
      
      Modified dwc2_check_param_tx_fifo_sizes() function to check TxFIFOn
      sizes based on g_tx_fifo_size array.
      
      Removed ep_info subtraction during calculation of tx_addr_max in
      dwc2_hsotg_tx_fifo_total_depth() function. Also removed
      dwc2_hsotg_ep_info_size() function as no more need.
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NGevorg Sahakyan <sahakyan@synopsys.com>
      Signed-off-by: NMinas Harutyunyan <hminas@synopsys.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      9273083a
    • M
      usb: dwc3: gadget: Fix PCM1 for ISOC EP with ep->mult less than 3 · ec5bb87e
      Manu Gautam 提交于
      For isochronous endpoints with ep->mult less than 3, PCM1 value of
      trb->size in set incorrectly.
      For ep->mult = 2, this is set to 0/-1 and for ep->mult = 1, this is
      set to -2. This is because the initial mult is set to ep->mult - 1
      instead of 2.
      Signed-off-by: NManu Gautam <mgautam@codeaurora.org>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      ec5bb87e
    • M
      usb: dwc3: of-simple: set dev_pm_ops · a0d8c4cf
      Masahiro Yamada 提交于
      dwc3_of_simple_dev_pm_ops has never been used since the initial support
      by commit 16adc674 ("usb: dwc3: add generic OF glue layer").
      
      I guess it just missed to set .pm struct member.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      a0d8c4cf
    • A
      usb: dwc3: of-simple: fix missing clk_disable_unprepare · ded600ea
      Andreas Platschek 提交于
      If of_clk_get() fails, the clean-up of already initialized clocks should be
      the same as when clk_prepare_enable() fails. Thus a clk_disable_unprepare()
      for each clock should be called before the clk_put().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      
      Fixes: 16adc674 ("usb: dwc3: ep0: fix setup_packet_pending initialization")
      Signed-off-by: NAndreas Platschek <andreas.platschek@opentech.at>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      ded600ea
    • V
      usb: dwc3: gadget: Wait longer for controller to end command processing · 8722e095
      Vincent Pelletier 提交于
      DWC3_DEPCMD_ENDTRANSFER has been witnessed to require around 600 iterations
      before controller would become idle again after unplugging the USB cable
      with AIO reads submitted.
      Bump timeout from 500 iterations to 1000 so dwc3_stop_active_transfer does
      not receive -ETIMEDOUT and does not WARN:
      
      [   81.326273] ------------[ cut here ]------------
      [   81.335341] WARNING: CPU: 0 PID: 1874 at drivers/usb/dwc3/gadget.c:2627 dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3]
      [   81.347094] Modules linked in: usb_f_fs libcomposite configfs bnep btsdio bluetooth ecdh_generic brcmfmac brcmutil dwc3 intel_powerclamp coretemp ulpi kvm_intel udc_core kvm irqbypass crc32_pclmul crc32c_intel pcbc dwc3_pci aesni_intel aes_i586 crypto_simd cryptd ehci_pci ehci_hcd basincove_gpadc industrialio gpio_keys usbcore usb_common
      [   81.378142] CPU: 0 PID: 1874 Comm: irq/34-dwc3 Not tainted 4.14.0-edison+ #119
      [   81.385545] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
      [   81.394548] task: f5b1be00 task.stack: f420a000
      [   81.399219] EIP: dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3]
      [   81.406086] EFLAGS: 00010086 CPU: 0
      [   81.409672] EAX: 0000001f EBX: f5729800 ECX: c132a2a2 EDX: 00000000
      [   81.416096] ESI: f4054014 EDI: f41cf400 EBP: f420be10 ESP: f420bdf4
      [   81.422521]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [   81.428061] CR0: 80050033 CR2: b7a3f000 CR3: 01d94000 CR4: 001006d0
      [   81.434483] Call Trace:
      [   81.437063]  __dwc3_gadget_ep_disable+0xa3/0x2b0 [dwc3]
      [   81.442438]  ? _raw_spin_lock_irqsave+0x32/0x40
      [   81.447135]  dwc3_gadget_ep_disable+0xbf/0xe0 [dwc3]
      [   81.452269]  usb_ep_disable+0x1c/0xd0 [udc_core]
      [   81.457048]  ffs_func_eps_disable.isra.15+0x3b/0x90 [usb_f_fs]
      [   81.463070]  ffs_func_set_alt+0x7d/0x310 [usb_f_fs]
      [   81.468132]  ffs_func_disable+0x14/0x20 [usb_f_fs]
      [   81.473075]  reset_config+0x5b/0x90 [libcomposite]
      [   81.478023]  composite_disconnect+0x2b/0x50 [libcomposite]
      [   81.483685]  dwc3_disconnect_gadget+0x39/0x50 [dwc3]
      [   81.488808]  dwc3_gadget_disconnect_interrupt+0x21b/0x250 [dwc3]
      [   81.495014]  dwc3_thread_interrupt+0x2a8/0xf70 [dwc3]
      [   81.500219]  ? __schedule+0x78c/0x7e0
      [   81.504027]  irq_thread_fn+0x18/0x30
      [   81.507715]  ? irq_thread+0xb7/0x180
      [   81.511400]  irq_thread+0x111/0x180
      [   81.515000]  ? irq_finalize_oneshot+0xe0/0xe0
      [   81.519490]  ? wake_threads_waitq+0x30/0x30
      [   81.523806]  kthread+0x107/0x110
      [   81.527131]  ? disable_percpu_irq+0x50/0x50
      [   81.531439]  ? kthread_stop+0x150/0x150
      [   81.535397]  ret_from_fork+0x19/0x24
      [   81.539136] Code: 89 d8 c7 45 ec 00 00 00 00 c7 45 f0 00 00 00 00 c7 45 f4 00 00 00 00 e8 56 ef ff ff 85 c0 74 12 50 68 b9 1c 14 f8 e8 64 0f f7 c8 <0f> ff 58 5a 8d 76 00 8b 83 98 00 00 00 c6 83 a0 00 00 00 00 83
      [   81.559295] ---[ end trace f3133eec81a473b8 ]---
      
      Number of iterations measured on 4 consecutive unplugs:
      [ 1088.799777] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 605 times
      [ 1222.024986] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 580 times
      [ 1317.590452] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 598 times
      [ 1453.218314] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 594 times
      Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      8722e095
  6. 09 12月, 2017 13 次提交
  7. 08 12月, 2017 1 次提交
    • S
      dm bufio: fix shrinker scans when (nr_to_scan < retain_target) · fbc7c07e
      Suren Baghdasaryan 提交于
      When system is under memory pressure it is observed that dm bufio
      shrinker often reclaims only one buffer per scan. This change fixes
      the following two issues in dm bufio shrinker that cause this behavior:
      
      1. ((nr_to_scan - freed) <= retain_target) condition is used to
      terminate slab scan process. This assumes that nr_to_scan is equal
      to the LRU size, which might not be correct because do_shrink_slab()
      in vmscan.c calculates nr_to_scan using multiple inputs.
      As a result when nr_to_scan is less than retain_target (64) the scan
      will terminate after the first iteration, effectively reclaiming one
      buffer per scan and making scans very inefficient. This hurts vmscan
      performance especially because mutex is acquired/released every time
      dm_bufio_shrink_scan() is called.
      New implementation uses ((LRU size - freed) <= retain_target)
      condition for scan termination. LRU size can be safely determined
      inside __scan() because this function is called after dm_bufio_lock().
      
      2. do_shrink_slab() uses value returned by dm_bufio_shrink_count() to
      determine number of freeable objects in the slab. However dm_bufio
      always retains retain_target buffers in its LRU and will terminate
      a scan when this mark is reached. Therefore returning the entire LRU size
      from dm_bufio_shrink_count() is misleading because that does not
      represent the number of freeable objects that slab will reclaim during
      a scan. Returning (LRU size - retain_target) better represents the
      number of freeable objects in the slab. This way do_shrink_slab()
      returns 0 when (LRU size < retain_target) and vmscan will not try to
      scan this shrinker avoiding scans that will not reclaim any memory.
      
      Test: tested using Android device running
      <AOSP>/system/extras/alloc-stress that generates memory pressure
      and causes intensive shrinker scans
      Signed-off-by: NSuren Baghdasaryan <surenb@google.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      fbc7c07e