1. 08 5月, 2019 40 次提交
    • A
      net: stmmac: fix dropping of multi-descriptor RX frames · f86c1d3f
      Aaro Koskinen 提交于
      [ Upstream commit 8ac0c24fe1c256af6644caf3d311029440ec2fbd ]
      
      Packets without the last descriptor set should be dropped early. If we
      receive a frame larger than the DMA buffer, the HW will continue using the
      next descriptor. Driver mistakes these as individual frames, and sometimes
      a truncated frame (without the LD set) may look like a valid packet.
      
      This fixes a strange issue where the system replies to 4098-byte ping
      although the MTU/DMA buffer size is set to 4096, and yet at the same
      time it's logging an oversized packet.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f86c1d3f
    • A
      net: stmmac: don't overwrite discard_frame status · 0ab012e3
      Aaro Koskinen 提交于
      [ Upstream commit 1b746ce8b397e58f9e40ce5c63b7198de6930482 ]
      
      If we have error bits set, the discard_frame status will get overwritten
      by checksum bit checks, which might set the status back to good one.
      Fix by checking the COE status only if the frame is good.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0ab012e3
    • A
      net: stmmac: don't stop NAPI processing when dropping a packet · 2170bbf1
      Aaro Koskinen 提交于
      [ Upstream commit 07b3975352374c3f5ebb4a42ef0b253fe370542d ]
      
      Currently, if we drop a packet, we exit from NAPI loop before the budget
      is consumed. In some situations this will make the RX processing stall
      e.g. when flood pinging the system with oversized packets, as the
      errorneous packets are not dropped efficiently.
      
      If we drop a packet, we should just continue to the next one as long as
      the budget allows.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2170bbf1
    • A
      net: stmmac: ratelimit RX error logs · cd50daab
      Aaro Koskinen 提交于
      [ Upstream commit 972c9be784e077bc56472c78243e0326e525b689 ]
      
      Ratelimit RX error logs.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cd50daab
    • A
      net: stmmac: use correct DMA buffer size in the RX descriptor · c13a936f
      Aaro Koskinen 提交于
      [ Upstream commit 583e6361414903c5206258a30e5bd88cb03c0254 ]
      
      We always program the maximum DMA buffer size into the receive descriptor,
      although the allocated size may be less. E.g. with the default MTU size
      we allocate only 1536 bytes. If somebody sends us a bigger frame, then
      memory may get corrupted.
      
      Fix by using exact buffer sizes.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c13a936f
    • K
      bonding: show full hw address in sysfs for slave entries · 824451fd
      Konstantin Khorenko 提交于
      [ Upstream commit 18bebc6dd3281955240062655a4df35eef2c46b3 ]
      
      Bond expects ethernet hwaddr for its slave, but it can be longer than 6
      bytes - infiniband interface for example.
      
       # cat /sys/devices/<skipped>/net/ib0/address
       80:00:02:08:fe:80:00:00:00:00:00:00:7c:fe:90:03:00:be:5d:e1
      
       # cat /sys/devices/<skipped>/net/ib0/bonding_slave/perm_hwaddr
       80:00:02:08:fe:80
      
      So print full hwaddr in sysfs "bonding_slave/perm_hwaddr" as well.
      Signed-off-by: NKonstantin Khorenko <khorenko@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      824451fd
    • O
      net/mlx5: E-Switch, Fix esw manager vport indication for more vport commands · f91bb70a
      Omri Kahalon 提交于
      [ Upstream commit eca4a928585ac08147e5cc8e2111ecbc6279ee31 ]
      
      Traditionally, the PF (Physical Function) which resides on vport 0 was
      the E-switch manager. Since the ECPF (Embedded CPU Physical Function),
      which resides on vport 0xfffe, was introduced as the E-Switch manager,
      the assumption that the E-switch manager is on vport 0 is incorrect.
      
      Since the eswitch code already uses the actual vport value, all we
      need is to always set other_vport=1.
      Signed-off-by: NOmri Kahalon <omrik@mellanox.com>
      Reviewed-by: NMax Gurtovoy <maxg@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f91bb70a
    • X
      net: hns3: fix compile error · 7e0548e1
      Xi Wang 提交于
      [ Upstream commit 669efc76b317b3aa550ffbf0b79d064cb00a5f96 ]
      
      Currently, the rules for configuring search paths in Kbuild have
      changed, this will lead some erros when compiling hns3 with the
      following command:
      
      make O=DIR M=drivers/net/ethernet/hisilicon/hns3
      
      drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c:11:10:
      fatal error: hnae3.h: No such file or directory
      
      This patch fix it by adding $(srctree)/ prefix to the serach paths.
      Signed-off-by: NXi Wang <wangxi11@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7e0548e1
    • J
      HID: quirks: Fix keyboard + touchpad on Lenovo Miix 630 · 6869dd57
      Jeffrey Hugo 提交于
      [ Upstream commit 2bafa1e9625400bec4c840a168d70ba52607a58d ]
      
      Similar to commit edfc3722 ("HID: quirks: Fix keyboard + touchpad on
      Toshiba Click Mini not working"), the Lenovo Miix 630 has a combo
      keyboard/touchpad device with vid:pid of 04F3:0400, which is shared with
      Elan touchpads.  The combo on the Miix 630 has an ACPI id of QTEC0001,
      which is not claimed by the elan_i2c driver, so key on that similar to
      what was done for the Toshiba Click Mini.
      Signed-off-by: NJeffrey Hugo <jeffrey.l.hugo@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6869dd57
    • A
      riscv: fix accessing 8-byte variable from RV32 · bc031095
      Alan Kao 提交于
      [ Upstream commit dbee9c9c45846f003ec2f819710c2f4835630a6a ]
      
      A memory save operation to 8-byte variable in RV32 is divided into
      two sw instructions in the put_user macro.  The current fixup returns
      execution flow to the second sw instead of the one after it.
      
      This patch fixes this fixup code according to the load access part.
      
      Signed-off-by: Alan Kao<alankao@andestech.com>
      Cc: Greentime Hu <greentime@andestech.com>
      Cc: Vincent Chen <deanbo422@gmail.com>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bc031095
    • A
      igb: Fix WARN_ONCE on runtime suspend · 0424b0b3
      Arvind Sankar 提交于
      [ Upstream commit dabb8338be533c18f50255cf39ff4f66d4dabdbe ]
      
      The runtime_suspend device callbacks are not supposed to save
      configuration state or change the power state. Commit fb29f76cc566
      ("igb: Fix an issue that PME is not enabled during runtime suspend")
      changed the driver to not save configuration state during runtime
      suspend, however the driver callback still put the device into a
      low-power state. This causes a warning in the pci pm core and results in
      pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend.
      
      Fix this by not changing the power state either, leaving that to pci pm
      core, and make the same change for suspend callback as well.
      
      Also move a couple of defines into the appropriate header file instead
      of inline in the .c file.
      
      Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend")
      Signed-off-by: NArvind Sankar <niveditas98@gmail.com>
      Reviewed-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0424b0b3
    • A
      reset: meson-audio-arb: Fix missing .owner setting of reset_controller_dev · cc04b5b3
      Axel Lin 提交于
      [ Upstream commit 13e8a05b922457761ddef39cfff6231bd4ed9eef ]
      
      Set .owner to prevent module unloading while being used.
      Signed-off-by: NAxel Lin <axel.lin@ingics.com>
      Fixes: d903779b ("reset: meson: add meson audio arb driver")
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cc04b5b3
    • D
      ARM: dts: rockchip: Fix gpu opp node names for rk3288 · ef953348
      Douglas Anderson 提交于
      [ Upstream commit d040e4e8deeaa8257d6aa260e29ad69832b5d630 ]
      
      The device tree compiler yells like this:
        Warning (unit_address_vs_reg):
        /gpu-opp-table/opp@100000000:
        node has a unit name, but no reg property
      
      Let's match the cpu opp node names and use a dash.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ef953348
    • A
      batman-adv: fix warning in function batadv_v_elp_get_throughput · 894b4fc0
      Anders Roxell 提交于
      [ Upstream commit ca8c3b922e7032aff6cc3fd05548f4df1f3df90e ]
      
      When CONFIG_CFG80211 isn't enabled the compiler correcly warns about
      'sinfo.pertid' may be unused. It can also happen for other error
      conditions that it not warn about.
      
      net/batman-adv/bat_v_elp.c: In function ‘batadv_v_elp_get_throughput.isra.0’:
      include/net/cfg80211.h:6370:13: warning: ‘sinfo.pertid’ may be used
       uninitialized in this function [-Wmaybe-uninitialized]
        kfree(sinfo->pertid);
              ~~~~~^~~~~~~~
      
      Rework so that we only release '&sinfo' if cfg80211_get_station returns
      zero.
      
      Fixes: 7d652669b61d ("batman-adv: release station info tidstats")
      Signed-off-by: NAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      894b4fc0
    • S
      batman-adv: Reduce tt_global hash refcnt only for removed entry · 7afe374c
      Sven Eckelmann 提交于
      [ Upstream commit f131a56880d10932931e74773fb8702894a94a75 ]
      
      The batadv_hash_remove is a function which searches the hashtable for an
      entry using a needle, a hashtable bucket selection function and a compare
      function. It will lock the bucket list and delete an entry when the compare
      function matches it with the needle. It returns the pointer to the
      hlist_node which matches or NULL when no entry matches the needle.
      
      The batadv_tt_global_free is not itself protected in anyway to avoid that
      any other function is modifying the hashtable between the search for the
      entry and the call to batadv_hash_remove. It can therefore happen that the
      entry either doesn't exist anymore or an entry was deleted which is not the
      same object as the needle. In such an situation, the reference counter (for
      the reference stored in the hashtable) must not be reduced for the needle.
      Instead the reference counter of the actually removed entry has to be
      reduced.
      
      Otherwise the reference counter will underflow and the object might be
      freed before all its references were dropped. The kref helpers reported
      this problem as:
      
        refcount_t: underflow; use-after-free.
      
      Fixes: 7683fdc1 ("batman-adv: protect the local and the global trans-tables with rcu")
      Reported-by: NMartin Weinelt <martin@linuxlounge.net>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Acked-by: NAntonio Quartulli <a@unstable.cc>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7afe374c
    • S
      batman-adv: Reduce tt_local hash refcnt only for removed entry · 6957021d
      Sven Eckelmann 提交于
      [ Upstream commit 3d65b9accab4a7ed5038f6df403fbd5e298398c7 ]
      
      The batadv_hash_remove is a function which searches the hashtable for an
      entry using a needle, a hashtable bucket selection function and a compare
      function. It will lock the bucket list and delete an entry when the compare
      function matches it with the needle. It returns the pointer to the
      hlist_node which matches or NULL when no entry matches the needle.
      
      The batadv_tt_local_remove is not itself protected in anyway to avoid that
      any other function is modifying the hashtable between the search for the
      entry and the call to batadv_hash_remove. It can therefore happen that the
      entry either doesn't exist anymore or an entry was deleted which is not the
      same object as the needle. In such an situation, the reference counter (for
      the reference stored in the hashtable) must not be reduced for the needle.
      Instead the reference counter of the actually removed entry has to be
      reduced.
      
      Otherwise the reference counter will underflow and the object might be
      freed before all its references were dropped. The kref helpers reported
      this problem as:
      
        refcount_t: underflow; use-after-free.
      
      Fixes: ef72706a ("batman-adv: protect tt_local_entry from concurrent delete events")
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6957021d
    • S
      batman-adv: Reduce claim hash refcnt only for removed entry · be807f9b
      Sven Eckelmann 提交于
      [ Upstream commit 4ba104f468bbfc27362c393815d03aa18fb7a20f ]
      
      The batadv_hash_remove is a function which searches the hashtable for an
      entry using a needle, a hashtable bucket selection function and a compare
      function. It will lock the bucket list and delete an entry when the compare
      function matches it with the needle. It returns the pointer to the
      hlist_node which matches or NULL when no entry matches the needle.
      
      The batadv_bla_del_claim is not itself protected in anyway to avoid that
      any other function is modifying the hashtable between the search for the
      entry and the call to batadv_hash_remove. It can therefore happen that the
      entry either doesn't exist anymore or an entry was deleted which is not the
      same object as the needle. In such an situation, the reference counter (for
      the reference stored in the hashtable) must not be reduced for the needle.
      Instead the reference counter of the actually removed entry has to be
      reduced.
      
      Otherwise the reference counter will underflow and the object might be
      freed before all its references were dropped. The kref helpers reported
      this problem as:
      
        refcount_t: underflow; use-after-free.
      
      Fixes: 23721387 ("batman-adv: add basic bridge loop avoidance code")
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      be807f9b
    • G
      rtc: sh: Fix invalid alarm warning for non-enabled alarm · 8a734e25
      Geert Uytterhoeven 提交于
      [ Upstream commit 15d82d22498784966df8e4696174a16b02cc1052 ]
      
      When no alarm has been programmed on RSK-RZA1, an error message is
      printed during boot:
      
          rtc rtc0: invalid alarm value: 2019-03-14T255:255:255
      
      sh_rtc_read_alarm_value() returns 0xff when querying a hardware alarm
      field that is not enabled.  __rtc_read_alarm() validates the received
      alarm values, and fills in missing fields when needed.
      While 0xff is handled fine for the year, month, and day fields, and
      corrected as considered being out-of-range, this is not the case for the
      hour, minute, and second fields, where -1 is expected for missing
      fields.
      
      Fix this by returning -1 instead, as this value is handled fine for all
      fields.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8a734e25
    • S
      rtc: cros-ec: Fail suspend/resume if wake IRQ can't be configured · 5b5c653d
      Stephen Boyd 提交于
      [ Upstream commit d6752e185c3168771787a02dc6a55f32260943cc ]
      
      If we encounter a failure during suspend where this RTC was programmed
      to wakeup the system from suspend, but that wakeup couldn't be
      configured because the system didn't support wakeup interrupts, we'll
      run into the following warning:
      
      	Unbalanced IRQ 166 wake disable
      	WARNING: CPU: 7 PID: 3071 at kernel/irq/manage.c:669 irq_set_irq_wake+0x108/0x278
      
      This happens because the suspend process isn't aborted when the RTC
      fails to configure the wakeup IRQ. Instead, we continue suspending the
      system and then another suspend callback fails the suspend process and
      "unwinds" the previously suspended drivers by calling their resume
      callbacks. When we get back to resuming this RTC driver, we'll call
      disable_irq_wake() on an IRQ that hasn't been configured for wake.
      
      Let's just fail suspend/resume here if we can't configure the system to
      wake and the user has chosen to wakeup with this device. This fixes this
      warning and makes the code more robust in case there are systems out
      there that can't wakeup from suspend on this line but the user has
      chosen to do so.
      
      Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
      Cc: Evan Green <evgreen@chromium.org>
      Cc: Benson Leung <bleung@chromium.org>
      Cc: Guenter Roeck <groeck@chromium.org>
      Signed-off-by: NStephen Boyd <swboyd@chromium.org>
      Acked-By: NBenson Leung <bleung@chromium.org>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5b5c653d
    • H
      HID: debug: fix race condition with between rdesc_show() and device removal · 2f4052ff
      He, Bo 提交于
      [ Upstream commit cef0d4948cb0a02db37ebfdc320e127c77ab1637 ]
      
      There is a race condition that could happen if hid_debug_rdesc_show()
      is running while hdev is in the process of going away (device removal,
      system suspend, etc) which could result in NULL pointer dereference:
      
      	 BUG: unable to handle kernel paging request at 0000000783316040
      	 CPU: 1 PID: 1512 Comm: getevent Tainted: G     U     O 4.19.20-quilt-2e5dc0ac-00029-gc455a447dd55 #1
      	 RIP: 0010:hid_dump_device+0x9b/0x160
      	 Call Trace:
      	  hid_debug_rdesc_show+0x72/0x1d0
      	  seq_read+0xe0/0x410
      	  full_proxy_read+0x5f/0x90
      	  __vfs_read+0x3a/0x170
      	  vfs_read+0xa0/0x150
      	  ksys_read+0x58/0xc0
      	  __x64_sys_read+0x1a/0x20
      	  do_syscall_64+0x55/0x110
      	  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Grab driver_input_lock to make sure the input device exists throughout the
      whole process of dumping the rdesc.
      
      [jkosina@suse.cz: update changelog a bit]
      Signed-off-by: Nhe, bo <bo.he@intel.com>
      Signed-off-by: N"Zhang, Jun" <jun.zhang@intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2f4052ff
    • K
      HID: logitech: check the return value of create_singlethread_workqueue · 61effc64
      Kangjie Lu 提交于
      [ Upstream commit 6c44b15e1c9076d925d5236ddadf1318b0a25ce2 ]
      
      create_singlethread_workqueue may fail and return NULL. The fix checks if it is
      NULL to avoid NULL pointer dereference.  Also, the fix moves the call of
      create_singlethread_workqueue earlier to avoid resource-release issues.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      61effc64
    • L
      arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay · dbfef4bd
      Leonidas P. Papadakos 提交于
      [ Upstream commit 924726888f660b2a86382a5dd051ec9ca1b18190 ]
      
      The rk3328-roc-cc board exhibits tx stability issues with large packets,
      as does the rock64 board, which was fixed with this patch
      https://patchwork.kernel.org/patch/10178969/
      
      A similar patch was merged for the rk3328-roc-cc here
      https://patchwork.kernel.org/patch/10804863/
      but it doesn't include the tx/rx_delay tweaks, and I find that they
      help with an issue where large transfers would bring the ethernet
      link down, causing a link reset regularly.
      Signed-off-by: NLeonidas P. Papadakos <papadakospan@gmail.com>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dbfef4bd
    • W
      efi: Fix debugobjects warning on 'efi_rts_work' · 3e6b472f
      Waiman Long 提交于
      [ Upstream commit ef1491e791308317bb9851a0ad380c4a68b58d54 ]
      
      The following commit:
      
        9dbbedaa6171 ("efi: Make efi_rts_work accessible to efi page fault handler")
      
      converted 'efi_rts_work' from an auto variable to a global variable.
      However, when submitting the work, INIT_WORK_ONSTACK() was still used,
      causing the following complaint from debugobjects:
      
        ODEBUG: object 00000000ed27b500 is NOT on stack 00000000c7d38760, but annotated.
      
      Change the macro to just INIT_WORK() to eliminate the warning.
      Signed-off-by: NWaiman Long <longman@redhat.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 9dbbedaa6171 ("efi: Make efi_rts_work accessible to efi page fault handler")
      Link: http://lkml.kernel.org/r/20181114175544.12860-2-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3e6b472f
    • Y
      nvme-loop: init nvmet_ctrl fatal_err_work when allocate · 30673786
      Yufen Yu 提交于
      [ Upstream commit d11de63f2b519f0a162b834013b6d3a46dbf3886 ]
      
      After commit 4d43d395fe (workqueue: Try to catch flush_work() without
      INIT_WORK()), it can cause warning when delete nvme-loop device, trace
      like:
      
      [   76.601272] Call Trace:
      [   76.601646]  ? del_timer+0x72/0xa0
      [   76.602156]  __cancel_work_timer+0x1ae/0x270
      [   76.602791]  cancel_work_sync+0x14/0x20
      [   76.603407]  nvmet_ctrl_free+0x1b7/0x2f0 [nvmet]
      [   76.604091]  ? free_percpu+0x168/0x300
      [   76.604652]  nvmet_sq_destroy+0x106/0x240 [nvmet]
      [   76.605346]  nvme_loop_destroy_admin_queue+0x30/0x60 [nvme_loop]
      [   76.606220]  nvme_loop_shutdown_ctrl+0xc3/0xf0 [nvme_loop]
      [   76.607026]  nvme_loop_delete_ctrl_host+0x19/0x30 [nvme_loop]
      [   76.607871]  nvme_do_delete_ctrl+0x75/0xb0
      [   76.608477]  nvme_sysfs_delete+0x7d/0xc0
      [   76.609057]  dev_attr_store+0x24/0x40
      [   76.609603]  sysfs_kf_write+0x4c/0x60
      [   76.610144]  kernfs_fop_write+0x19a/0x260
      [   76.610742]  __vfs_write+0x1c/0x60
      [   76.611246]  vfs_write+0xfa/0x280
      [   76.611739]  ksys_write+0x6e/0x120
      [   76.612238]  __x64_sys_write+0x1e/0x30
      [   76.612787]  do_syscall_64+0xbf/0x3a0
      [   76.613329]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      We fix it by moving fatal_err_work init to nvmet_alloc_ctrl(), which may
      more reasonable.
      Signed-off-by: NYufen Yu <yuyufen@huawei.com>
      Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      30673786
    • A
      USB: core: Fix bug caused by duplicate interface PM usage counter · 83c6688d
      Alan Stern 提交于
      commit c2b71462d294cf517a0bc6e4fd6424d7cee5596f upstream.
      
      The syzkaller fuzzer reported a bug in the USB hub driver which turned
      out to be caused by a negative runtime-PM usage counter.  This allowed
      a hub to be runtime suspended at a time when the driver did not expect
      it.  The symptom is a WARNING issued because the hub's status URB is
      submitted while it is already active:
      
      	URB 0000000031fb463e submitted while active
      	WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363
      
      The negative runtime-PM usage count was caused by an unfortunate
      design decision made when runtime PM was first implemented for USB.
      At that time, USB class drivers were allowed to unbind from their
      interfaces without balancing the usage counter (i.e., leaving it with
      a positive count).  The core code would take care of setting the
      counter back to 0 before allowing another driver to bind to the
      interface.
      
      Later on when runtime PM was implemented for the entire kernel, the
      opposite decision was made: Drivers were required to balance their
      runtime-PM get and put calls.  In order to maintain backward
      compatibility, however, the USB subsystem adapted to the new
      implementation by keeping an independent usage counter for each
      interface and using it to automatically adjust the normal usage
      counter back to 0 whenever a driver was unbound.
      
      This approach involves duplicating information, but what is worse, it
      doesn't work properly in cases where a USB class driver delays
      decrementing the usage counter until after the driver's disconnect()
      routine has returned and the counter has been adjusted back to 0.
      Doing so would cause the usage counter to become negative.  There's
      even a warning about this in the USB power management documentation!
      
      As it happens, this is exactly what the hub driver does.  The
      kick_hub_wq() routine increments the runtime-PM usage counter, and the
      corresponding decrement is carried out by hub_event() in the context
      of the hub_wq work-queue thread.  This work routine may sometimes run
      after the driver has been unbound from its interface, and when it does
      it causes the usage counter to go negative.
      
      It is not possible for hub_disconnect() to wait for a pending
      hub_event() call to finish, because hub_disconnect() is called with
      the device lock held and hub_event() acquires that lock.  The only
      feasible fix is to reverse the original design decision: remove the
      duplicate interface-specific usage counter and require USB drivers to
      balance their runtime PM gets and puts.  As far as I know, all
      existing drivers currently do this.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83c6688d
    • A
      USB: core: Fix unterminated string returned by usb_string() · 7b73c2a0
      Alan Stern 提交于
      commit c01c348ecdc66085e44912c97368809612231520 upstream.
      
      Some drivers (such as the vub300 MMC driver) expect usb_string() to
      return a properly NUL-terminated string, even when an error occurs.
      (In fact, vub300's probe routine doesn't bother to check the return
      code from usb_string().)  When the driver goes on to use an
      unterminated string, it leads to kernel errors such as
      stack-out-of-bounds, as found by the syzkaller USB fuzzer.
      
      An out-of-range string index argument is not at all unlikely, given
      that some devices don't provide string descriptors and therefore list
      0 as the value for their string indexes.  This patch makes
      usb_string() return a properly terminated empty string along with the
      -EINVAL error code when an out-of-range index is encountered.
      
      And since a USB string index is a single-byte value, indexes >= 256
      are just as invalid as values of 0 or below.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: syzbot+b75b85111c10b8d680f1@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b73c2a0
    • M
      usb: usbip: fix isoc packet num validation in get_pipe · 7df0d2c7
      Malte Leip 提交于
      commit c409ca3be3c6ff3a1eeb303b191184e80d412862 upstream.
      
      Change the validation of number_of_packets in get_pipe to compare the
      number of packets to a fixed maximum number of packets allowed, set to
      be 1024. This number was chosen due to it being used by other drivers as
      well, for example drivers/usb/host/uhci-q.c
      
      Background/reason:
      The get_pipe function in stub_rx.c validates the number of packets in
      isochronous mode and aborts with an error if that number is too large,
      in order to prevent malicious input from possibly triggering large
      memory allocations. This was previously done by checking whether
      pdu->u.cmd_submit.number_of_packets is bigger than the number of packets
      that would be needed for pdu->u.cmd_submit.transfer_buffer_length bytes
      if all except possibly the last packet had maximum length, given by
      usb_endpoint_maxp(epd) *  usb_endpoint_maxp_mult(epd). This leads to an
      error if URBs with packets shorter than the maximum possible length are
      submitted, which is allowed according to
      Documentation/driver-api/usb/URB.rst and occurs for example with the
      snd-usb-audio driver.
      
      Fixes: c6688ef9 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input")
      Signed-off-by: NMalte Leip <malte@leip.net>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7df0d2c7
    • A
      USB: dummy-hcd: Fix failure to give back unlinked URBs · 512ce150
      Alan Stern 提交于
      commit fc834e607ae3d18e1a20bca3f9a2d7f52ea7a2be upstream.
      
      The syzkaller USB fuzzer identified a failure mode in which dummy-hcd
      would never give back an unlinked URB.  This causes usb_kill_urb() to
      hang, leading to WARNINGs and unkillable threads.
      
      In dummy-hcd, all URBs are given back by the dummy_timer() routine as
      it scans through the list of pending URBS.  Failure to give back URBs
      can be caused by failure to start or early exit from the scanning
      loop.  The code currently has two such pathways: One is triggered when
      an unsupported bus transfer speed is encountered, and the other by
      exhausting the simulated bandwidth for USB transfers during a frame.
      
      This patch removes those two paths, thereby allowing all unlinked URBs
      to be given back in a timely manner.  It adds a check for the bus
      speed when the gadget first starts running, so that dummy_timer() will
      never thereafter encounter an unsupported speed.  And it prevents the
      loop from exiting as soon as the total bandwidth has been used up (the
      scanning loop continues, giving back unlinked URBs as they are found,
      but not transferring any more data).
      
      Thanks to Andrey Konovalov for manually running the syzkaller fuzzer
      to help track down the source of the bug.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+d919b0f29d7b5a4994b9@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      512ce150
    • A
      USB: w1 ds2490: Fix bug caused by improper use of altsetting array · 50895488
      Alan Stern 提交于
      commit c114944d7d67f24e71562fcfc18d550ab787e4d4 upstream.
      
      The syzkaller USB fuzzer spotted a slab-out-of-bounds bug in the
      ds2490 driver.  This bug is caused by improper use of the altsetting
      array in the usb_interface structure (the array's entries are not
      always stored in numerical order), combined with a naive assumption
      that all interfaces probed by the driver will have the expected number
      of altsettings.
      
      The bug can be fixed by replacing references to the possibly
      non-existent intf->altsetting[alt] entry with the guaranteed-to-exist
      intf->cur_altsetting entry.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+d65f673b847a1a96cdba@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50895488
    • A
      USB: yurex: Fix protection fault after device removal · 9f632afe
      Alan Stern 提交于
      commit ef61eb43ada6c1d6b94668f0f514e4c268093ff3 upstream.
      
      The syzkaller USB fuzzer found a general-protection-fault bug in the
      yurex driver.  The fault occurs when a device has been unplugged; the
      driver's interrupt-URB handler logs an error message referring to the
      device by name, after the device has been unregistered and its name
      deallocated.
      
      This problem is caused by the fact that the interrupt URB isn't
      cancelled until the driver's private data structure is released, which
      can happen long after the device is gone.  The cure is to make sure
      that the interrupt URB is killed before yurex_disconnect() returns;
      this is exactly the sort of thing that usb_poison_urb() was meant for.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+2eb9121678bdb36e6d57@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f632afe
    • T
      ALSA: hda/realtek - Apply the fixup for ASUS Q325UAR · f02c6460
      Takashi Iwai 提交于
      commit 3887c26c0e24d50a4d0ce20cf4726737cee1a2fd upstream.
      
      Some ASUS models like Q325UAR with ALC295 codec requires the same
      fixup that has been applied to ALC294 codec.  Just copy the entry with
      the pin matching to cover ALC295 too.
      
      BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784485
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f02c6460
    • K
      ALSA: hda/realtek - Fixed Dell AIO speaker noise · 347411f9
      Kailang Yang 提交于
      commit 0700d3d117a7f110ddddbd83873e13652f69c54b upstream.
      
      Fixed Dell AIO speaker noise.
      spec->gen.auto_mute_via_amp = 1, this option was solved speaker white
      noise at boot.
      codec->power_save_node = 0, this option was solved speaker noise at
      resume back.
      
      Fixes: 92266651 ("ALSA: hda/realtek - Fix Dell AIO LineOut issue")
      Signed-off-by: NKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      347411f9
    • K
      ALSA: hda/realtek - Add new Dell platform for headset mode · f937634b
      Kailang Yang 提交于
      commit 0a29c57b76624723b6b00c027e0e992d130ace49 upstream.
      
      Add two Dell platform for headset mode.
      
      [ Note: this is a further correction / addition of the previous
        pin-based quirks for Dell machines; another entry for ALC236 with
        the d-mic pin 0x12 and an entry for ALC295 -- tiwai ]
      
      Fixes: b26e36b7ef36 ("ALSA: hda/realtek - add two more pin configuration sets to quirk table")
      Signed-off-by: NKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f937634b
    • J
      i2c: Prevent runtime suspend of adapter when Host Notify is required · b19c2306
      Jarkko Nikula 提交于
      commit 72bfcee11cf89509795c56b0e40a3785ab00bbdd upstream.
      
      Multiple users have reported their Synaptics touchpad has stopped
      working between v4.20.1 and v4.20.2 when using SMBus interface.
      
      The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow
      runtime PM without callback functions") that fixed the runtime PM for
      i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801
      for SMBus communication and testing showed they are able to get back
      working by preventing the runtime suspend of adapter.
      
      Normally when i2c-i801 SMBus adapter transmits with the client it resumes
      before operation and autosuspends after.
      
      However, if client requires SMBus Host Notify protocol, what those
      Synaptics touchpads do, then the host adapter must not go to runtime
      suspend since then it cannot process incoming SMBus Host Notify commands
      the client may send.
      
      Fix this by keeping I2C/SMBus adapter active in case client requires
      Host Notify.
      Reported-by: NKeijo Vaara <ferdasyn@rocketmail.com>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297
      Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
      Cc: stable@vger.kernel.org # v4.20+
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NKeijo Vaara <ferdasyn@rocketmail.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b19c2306
    • J
      i2c: Allow recovery of the initial IRQ by an I2C client device. · 04e07919
      Jim Broadus 提交于
      commit 93b6604c5a669d84e45fe5129294875bf82eb1ff upstream.
      
      A previous change allowed I2C client devices to discover new IRQs upon
      reprobe by clearing the IRQ in i2c_device_remove. However, if an IRQ was
      assigned in i2c_new_device, that information is lost.
      
      For example, the touchscreen and trackpad devices on a Dell Inspiron laptop
      are I2C devices whose IRQs are defined by ACPI extended IRQ types. The
      client device structures are initialized during an ACPI walk. After
      removing the i2c_hid device, modprobe fails.
      
      This change caches the initial IRQ value in i2c_new_device and then resets
      the client device IRQ to the initial value in i2c_device_remove.
      
      Fixes: 6f108dd70d30 ("i2c: Clear client->irq in i2c_device_remove")
      Signed-off-by: NJim Broadus <jbroadus@gmail.com>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Reviewed-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      [wsa: this is an easy to backport fix for the regression. We will
      refactor the code to handle irq assignments better in general.]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04e07919
    • C
      i2c: Clear client->irq in i2c_device_remove · 1e031ab3
      Charles Keepax 提交于
      commit 6f108dd70d3010c391c1e9f56f3f20d1f9e75450 upstream.
      
      The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
      i2c_device_remove does not clear this. When rebinding an I2C device,
      whos IRQ provider has also been rebound this means that an IRQ mapping
      will never be created, causing the I2C device to fail to acquire its
      IRQ. Fix this issue by clearing client->irq in i2c_device_remove,
      forcing i2c_device_probe to lookup the mapping again.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e031ab3
    • C
      i2c: Remove unnecessary call to irq_find_mapping · 63eab25e
      Charles Keepax 提交于
      commit b9bb3fdf4e870fb655064f5c3c81c1fee7fd89ce upstream.
      
      irq_create_mapping calls irq_find_mapping internally and will use the
      found mapping if one exists, so there is no need to manually call this
      from i2c_smbus_host_notify_to_irq.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63eab25e
    • A
      i2c: imx: correct the method of getting private data in notifier_call · e89ba70e
      Anson Huang 提交于
      commit d386bb9042f4629bf62cdc5952ea8aab225f24a7 upstream.
      
      The way of getting private imx_i2c_struct in i2c_imx_clk_notifier_call()
      is incorrect, should use clk_change_nb element to get correct address
      and avoid below kernel dump during POST_RATE_CHANGE notify by clk
      framework:
      
      Unable to handle kernel paging request at virtual address 03ef1488
      pgd = (ptrval)
      [03ef1488] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: events reduce_bus_freq_handler
      PC is at i2c_imx_set_clk+0x10/0xb8
      LR is at i2c_imx_clk_notifier_call+0x20/0x28
      pc : [<806a893c>]    lr : [<806a8a04>]    psr: a0080013
      sp : bf399dd8  ip : bf3432ac  fp : bf7c1dc0
      r10: 00000002  r9 : 00000000  r8 : 00000000
      r7 : 03ef1480  r6 : bf399e50  r5 : ffffffff  r4 : 00000000
      r3 : bf025300  r2 : bf399e50  r1 : 00b71b00  r0 : bf399be8
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 4e03004a  DAC: 00000051
      Process kworker/2:1 (pid: 38, stack limit = 0x(ptrval))
      Stack: (0xbf399dd8 to 0xbf39a000)
      9dc0:                                                       806a89e4 00000000
      9de0: ffffffff bf399e50 00000002 806a8a04 806a89e4 80142900 ffffffff 00000000
      9e00: bf34ef18 bf34ef04 00000000 ffffffff bf399e50 80142d84 00000000 bf399e6c
      9e20: bf34ef00 80f214c4 bf025300 00000002 80f08d08 bf017480 00000000 80142df0
      9e40: 00000000 80166ed8 80c27638 8045de58 bf352340 03ef1480 00b71b00 0f82e242
      9e60: bf025300 00000002 03ef1480 80f60e5c 00000001 8045edf0 00000002 8045eb08
      9e80: bf025300 00000002 03ef1480 8045ee10 03ef1480 8045eb08 bf01be40 00000002
      9ea0: 03ef1480 8045ee10 07de2900 8045eb08 bf01b780 00000002 07de2900 8045ee10
      9ec0: 80c27898 bf399ee4 bf020a80 00000002 1f78a400 8045ee10 80f60e5c 80460514
      9ee0: 80f60e5c bf01b600 bf01b480 80460460 0f82e242 bf383a80 bf383a00 80f60e5c
      9f00: 00000000 bf7c1dc0 80f60e70 80460564 80f60df0 80f60d24 80f60df0 8011e72c
      9f20: 00000000 80f60df0 80f60e6c bf7c4f00 00000000 8011e7ac bf274000 8013bd84
      9f40: bf7c1dd8 80f03d00 bf274000 bf7c1dc0 bf274014 bf7c1dd8 80f03d00 bf398000
      9f60: 00000008 8013bfb4 00000000 bf25d100 bf25d0c0 00000000 bf274000 8013bf88
      9f80: bf25d11c bf0cfebc 00000000 8014140c bf25d0c0 801412ec 00000000 00000000
      9fa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000
      9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
      [<806a893c>] (i2c_imx_set_clk) from [<806a8a04>] (i2c_imx_clk_notifier_call+0x20/0x28)
      [<806a8a04>] (i2c_imx_clk_notifier_call) from [<80142900>] (notifier_call_chain+0x44/0x84)
      [<80142900>] (notifier_call_chain) from [<80142d84>] (__srcu_notifier_call_chain+0x44/0x98)
      [<80142d84>] (__srcu_notifier_call_chain) from [<80142df0>] (srcu_notifier_call_chain+0x18/0x20)
      [<80142df0>] (srcu_notifier_call_chain) from [<8045de58>] (__clk_notify+0x78/0xa4)
      [<8045de58>] (__clk_notify) from [<8045edf0>] (__clk_recalc_rates+0x60/0xb4)
      [<8045edf0>] (__clk_recalc_rates) from [<8045ee10>] (__clk_recalc_rates+0x80/0xb4)
      Code: e92d40f8 e5903298 e59072a0 e1530001 (e5975008)
      ---[ end trace fc7f5514b97b6cbb ]---
      
      Fixes: 90ad2cbe ("i2c: imx: use clk notifier for rate changes")
      Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
      Reviewed-by: NDong Aisheng <aisheng.dong@nxp.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e89ba70e
    • A
      i2c: synquacer: fix enumeration of slave devices · d1493c5c
      Ard Biesheuvel 提交于
      commit 95e0cf3caeb11e1b0398c747b5cfa12828263824 upstream.
      
      The I2C host driver for SynQuacer fails to populate the of_node and
      ACPI companion fields of the struct i2c_adapter it instantiates,
      resulting in enumeration of the subordinate I2C bus to fail.
      
      Fixes: 0d676a6c ("i2c: add support for Socionext SynQuacer I2C controller")
      Cc: <stable@vger.kernel.org> # v4.19+
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1493c5c
    • J
      mac80211: don't attempt to rename ERR_PTR() debugfs dirs · ec308112
      Johannes Berg 提交于
      commit 517879147493a5e1df6b89a50f708f1133fcaddb upstream.
      
      We need to dereference the directory to get its parent to
      be able to rename it, so it's clearly not safe to try to
      do this with ERR_PTR() pointers. Skip in this case.
      
      It seems that this is most likely what was causing the
      report by syzbot, but I'm not entirely sure as it didn't
      come with a reproducer this time.
      
      Cc: stable@vger.kernel.org
      Reported-by: syzbot+4ece1a28b8f4730547c9@syzkaller.appspotmail.com
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec308112