1. 16 8月, 2019 40 次提交
    • L
      iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT support · ac295111
      Luca Coelho 提交于
      commit f5a47fae6aa3eb06f100e701d2342ee56b857bee upstream.
      
      We erroneously added a check for FW API version 41 before sending
      GEO_TX_POWER_LIMIT, but this was already implemented in version 38.
      Additionally, it was cherry-picked to older versions, namely 17, 26
      and 29, so check for those as well.
      
      Cc: stable@vger.kernel.org
      Fixes: eca1e56ceedd ("iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT to old firmwares")
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac295111
    • L
      iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version < 41 · 6a81677a
      Luca Coelho 提交于
      commit 39bd984c203e86f3109b49c2a2e20677c4d3ab65 upstream.
      
      Firmware versions before 41 don't support the GEO_TX_POWER_LIMIT
      command, and sending it to the firmware will cause a firmware crash.
      We allow this via debugfs, so we need to return an error value in case
      it's not supported.
      
      This had already been fixed during init, when we send the command if
      the ACPI WGDS table is present.  Fix it also for the other,
      userspace-triggered case.
      
      Cc: stable@vger.kernel.org
      Fixes: 7fe90e0e ("iwlwifi: mvm: refactor geo init")
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a81677a
    • E
      iwlwifi: mvm: fix an out-of-bound access · 80bac45e
      Emmanuel Grumbach 提交于
      commit ba3224db78034435e9ff0247277cce7c7bb1756c upstream.
      
      The index for the elements of the ACPI object we dereference
      was static. This means that if we called the function twice
      we wouldn't start from 3 again, but rather from the latest
      index we reached in the previous call.
      This was dutifully reported by KASAN.
      
      Fix this.
      
      Cc: stable@vger.kernel.org
      Fixes: 69964905 ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80bac45e
    • E
      iwlwifi: don't unmap as page memory that was mapped as single · 7626b510
      Emmanuel Grumbach 提交于
      commit 87e7e25aee6b59fef740856f4e86d4b60496c9e1 upstream.
      
      In order to remember how to unmap a memory (as single or
      as page), we maintain a bit per Transmit Buffer (TBs) in
      the meta data (structure iwl_cmd_meta).
      We maintain a bitmap: 1 bit per TB.
      If the TB is set, we will free the memory as a page.
      This bitmap was never cleared. Fix this.
      
      Cc: stable@vger.kernel.org
      Fixes: 3cd1980b ("iwlwifi: pcie: introduce new tfd and tb formats")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7626b510
    • B
      mwifiex: fix 802.11n/WPA detection · b38c56b7
      Brian Norris 提交于
      commit df612421fe2566654047769c6852ffae1a31df16 upstream.
      
      Commit 63d7ef36103d ("mwifiex: Don't abort on small, spec-compliant
      vendor IEs") adjusted the ieee_types_vendor_header struct, which
      inadvertently messed up the offsets used in
      mwifiex_is_wpa_oui_present(). Add that offset back in, mirroring
      mwifiex_is_rsn_oui_present().
      
      As it stands, commit 63d7ef36103d breaks compatibility with WPA (not
      WPA2) 802.11n networks, since we hit the "info: Disable 11n if AES is
      not supported by AP" case in mwifiex_is_network_compatible().
      
      Fixes: 63d7ef36103d ("mwifiex: Don't abort on small, spec-compliant vendor IEs")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b38c56b7
    • S
      drm/i915: Fix wrong escape clock divisor init for GLK · edc38856
      Stanislav Lisovskiy 提交于
      commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
      
      According to Bspec clock divisor registers in GeminiLake
      should be initialized by shifting 1(<<) to amount of correspondent
      divisor. While i915 was writing all this time that value as is.
      
      Surprisingly that it by accident worked, until we met some issues
      with Microtech Etab.
      
      v2: Added Fixes tag and cc
      v3: Added stable to cc as well.
      Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Reviewed-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
      Fixes: bcc65700 ("drm/i915/glk: Program txesc clock divider for GLK")
      Cc: Deepak M <m.deepak@intel.com>
      Cc: Madhav Chauhan <madhav.chauhan@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovskiy@intel.com
      (cherry picked from commit ce52ad5dd52cfaf3398058384e0ff94134bbd89c)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edc38856
    • G
      hwmon: (nct7802) Fix wrong detection of in4 presence · a7302720
      Guenter Roeck 提交于
      commit 38ada2f406a9b81fb1249c5c9227fa657e7d5671 upstream.
      
      The code to detect if in4 is present is wrong; if in4 is not present,
      the in4_input sysfs attribute is still present.
      
      In detail:
      
      - Ihen RTD3_MD=11 (VSEN3 present), everything is as expected (no bug).
      - If we have RTD3_MD!=11 (no VSEN3), we unexpectedly have a in4_input
        file under /sys and the "sensors" command displays in4_input.
        But as expected, we have no in4_min, in4_max, in4_alarm, in4_beep.
      
      Fix is_visible function to detect and report in4_input visibility
      as expected.
      Reported-by: NGilles Buloz <Gilles.Buloz@kontron.com>
      Cc: Gilles Buloz <Gilles.Buloz@kontron.com>
      Cc: stable@vger.kernel.org
      Fixes: 3434f378 ("hwmon: Driver for Nuvoton NCT7802Y")
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7302720
    • T
      can: peak_usb: pcan_usb_fd: Fix info-leaks to USB devices · 9ce1b3eb
      Tomas Bortoli 提交于
      commit 30a8beeb3042f49d0537b7050fd21b490166a3d9 upstream.
      
      Uninitialized Kernel memory can leak to USB devices.
      
      Fix by using kzalloc() instead of kmalloc() on the affected buffers.
      Signed-off-by: NTomas Bortoli <tomasbortoli@gmail.com>
      Reported-by: syzbot+513e4d0985298538bf9b@syzkaller.appspotmail.com
      Fixes: 0a25e1f4 ("can: peak_usb: add support for PEAK new CANFD USB adapters")
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ce1b3eb
    • T
      can: peak_usb: pcan_usb_pro: Fix info-leaks to USB devices · cab569a4
      Tomas Bortoli 提交于
      commit ead16e53c2f0ed946d82d4037c630e2f60f4ab69 upstream.
      
      Uninitialized Kernel memory can leak to USB devices.
      
      Fix by using kzalloc() instead of kmalloc() on the affected buffers.
      Signed-off-by: NTomas Bortoli <tomasbortoli@gmail.com>
      Reported-by: syzbot+d6a5a1a3657b596ef132@syzkaller.appspotmail.com
      Fixes: f14e2243 ("net: can: peak_usb: Do not do dma on the stack")
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cab569a4
    • R
      HID: sony: Fix race condition between rumble and device remove. · 11829307
      Roderick Colenbrander 提交于
      commit e0f6974a54d3f7f1b5fdf5a593bd43ce9206ec04 upstream.
      
      Valve reported a kernel crash on Ubuntu 18.04 when disconnecting a DS4
      gamepad while rumble is enabled. This issue is reproducible with a
      frequency of 1 in 3 times in the game Borderlands 2 when using an
      automatic weapon, which triggers many rumble operations.
      
      We found the issue to be a race condition between sony_remove and the
      final device destruction by the HID / input system. The problem was
      that sony_remove didn't clean some of its work_item state in
      "struct sony_sc". After sony_remove work, the corresponding evdev
      node was around for sufficient time for applications to still queue
      rumble work after "sony_remove".
      
      On pre-4.19 kernels the race condition caused a kernel crash due to a
      NULL-pointer dereference as "sc->output_report_dmabuf" got freed during
      sony_remove. On newer kernels this crash doesn't happen due the buffer
      now being allocated using devm_kzalloc. However we can still queue work,
      while the driver is an undefined state.
      
      This patch fixes the described problem, by guarding the work_item
      "state_worker" with an initialized variable, which we are setting back
      to 0 on cleanup.
      Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
      CC: stable@vger.kernel.org
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11829307
    • P
      tty/ldsem, locking/rwsem: Add missing ACQUIRE to read_failed sleep loop · 06dc9214
      Peter Zijlstra 提交于
      [ Upstream commit 952041a8639a7a3a73a2b6573cb8aa8518bc39f8 ]
      
      While reviewing rwsem down_slowpath, Will noticed ldsem had a copy of
      a bug we just found for rwsem.
      
        X = 0;
      
        CPU0			CPU1
      
        rwsem_down_read()
          for (;;) {
            set_current_state(TASK_UNINTERRUPTIBLE);
      
                              X = 1;
                              rwsem_up_write();
                                rwsem_mark_wake()
                                  atomic_long_add(adjustment, &sem->count);
                                  smp_store_release(&waiter->task, NULL);
      
            if (!waiter.task)
              break;
      
            ...
          }
      
        r = X;
      
      Allows 'r == 0'.
      Reported-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NWill Deacon <will@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 4898e640 ("tty: Add timed, writer-prioritized rw semaphore")
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      06dc9214
    • H
      scsi: scsi_dh_alua: always use a 2 second delay before retrying RTPG · cdd92ebe
      Hannes Reinecke 提交于
      [ Upstream commit 20122994e38aef0ae50555884d287adde6641c94 ]
      
      Retrying immediately after we've received a 'transitioning' sense code is
      pretty much pointless, we should always use a delay before retrying.  So
      ensure the default delay is applied before retrying.
      Signed-off-by: NHannes Reinecke <hare@suse.com>
      Tested-by: NZhangguanghui <zhang.guanghui@h3c.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cdd92ebe
    • T
      scsi: ibmvfc: fix WARN_ON during event pool release · b620c6d5
      Tyrel Datwyler 提交于
      [ Upstream commit 5578257ca0e21056821e6481bd534ba267b84e58 ]
      
      While removing an ibmvfc client adapter a WARN_ON like the following
      WARN_ON is seen in the kernel log:
      
      WARNING: CPU: 6 PID: 5421 at ./include/linux/dma-mapping.h:541
      ibmvfc_free_event_pool+0x12c/0x1f0 [ibmvfc]
      CPU: 6 PID: 5421 Comm: rmmod Tainted: G            E     4.17.0-rc1-next-20180419-autotest #1
      NIP:  d00000000290328c LR: d00000000290325c CTR: c00000000036ee20
      REGS: c000000288d1b7e0 TRAP: 0700   Tainted: G            E      (4.17.0-rc1-next-20180419-autotest)
      MSR:  800000010282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 44008828  XER: 20000000
      CFAR: c00000000036e408 SOFTE: 1
      GPR00: d00000000290325c c000000288d1ba60 d000000002917900 c000000289d75448
      GPR04: 0000000000000071 c0000000ff870000 0000000018040000 0000000000000001
      GPR08: 0000000000000000 c00000000156e838 0000000000000001 d00000000290c640
      GPR12: c00000000036ee20 c00000001ec4dc00 0000000000000000 0000000000000000
      GPR16: 0000000000000000 0000000000000000 00000100276901e0 0000000010020598
      GPR20: 0000000010020550 0000000010020538 0000000010020578 00000000100205b0
      GPR24: 0000000000000000 0000000000000000 0000000010020590 5deadbeef0000100
      GPR28: 5deadbeef0000200 d000000002910b00 0000000000000071 c0000002822f87d8
      NIP [d00000000290328c] ibmvfc_free_event_pool+0x12c/0x1f0 [ibmvfc]
      LR [d00000000290325c] ibmvfc_free_event_pool+0xfc/0x1f0 [ibmvfc]
      Call Trace:
      [c000000288d1ba60] [d00000000290325c] ibmvfc_free_event_pool+0xfc/0x1f0 [ibmvfc] (unreliable)
      [c000000288d1baf0] [d000000002909390] ibmvfc_abort_task_set+0x7b0/0x8b0 [ibmvfc]
      [c000000288d1bb70] [c0000000000d8c68] vio_bus_remove+0x68/0x100
      [c000000288d1bbb0] [c0000000007da7c4] device_release_driver_internal+0x1f4/0x2d0
      [c000000288d1bc00] [c0000000007da95c] driver_detach+0x7c/0x100
      [c000000288d1bc40] [c0000000007d8af4] bus_remove_driver+0x84/0x140
      [c000000288d1bcb0] [c0000000007db6ac] driver_unregister+0x4c/0xa0
      [c000000288d1bd20] [c0000000000d6e7c] vio_unregister_driver+0x2c/0x50
      [c000000288d1bd50] [d00000000290ba0c] cleanup_module+0x24/0x15e0 [ibmvfc]
      [c000000288d1bd70] [c0000000001dadb0] sys_delete_module+0x220/0x2d0
      [c000000288d1be30] [c00000000000b284] system_call+0x58/0x6c
      Instruction dump:
      e8410018 e87f0068 809f0078 e8bf0080 e8df0088 2fa30000 419e008c e9230200
      2fa90000 419e0080 894d098a 794a07e0 <0b0a0000> e9290008 2fa90000 419e0028
      
      This is tripped as a result of irqs being disabled during the call to
      dma_free_coherent() by ibmvfc_free_event_pool(). At this point in the code path
      we have quiesced the adapter and its overly paranoid anyways to be holding the
      host lock.
      Reported-by: NAbdul Haleem <abdhalee@linux.vnet.ibm.com>
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b620c6d5
    • J
      scsi: megaraid_sas: fix panic on loading firmware crashdump · f254faed
      Junxiao Bi 提交于
      [ Upstream commit 3b5f307ef3cb5022bfe3c8ca5b8f2114d5bf6c29 ]
      
      While loading fw crashdump in function fw_crash_buffer_show(), left bytes
      in one dma chunk was not checked, if copying size over it, overflow access
      will cause kernel panic.
      Signed-off-by: NJunxiao Bi <junxiao.bi@oracle.com>
      Acked-by: NSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f254faed
    • M
      nvme: fix multipath crash when ANA is deactivated · bdce5621
      Marta Rybczynska 提交于
      [ Upstream commit 66b20ac0a1a10769d059d6903202f53494e3d902 ]
      
      Fix a crash with multipath activated. It happends when ANA log
      page is larger than MDTS and because of that ANA is disabled.
      The driver then tries to access unallocated buffer when connecting
      to a nvme target. The signature is as follows:
      
      [  300.433586] nvme nvme0: ANA log page size (8208) larger than MDTS (8192).
      [  300.435387] nvme nvme0: disabling ANA support.
      [  300.437835] nvme nvme0: creating 4 I/O queues.
      [  300.459132] nvme nvme0: new ctrl: NQN "nqn.0.0.0", addr 10.91.0.1:8009
      [  300.464609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      [  300.466342] #PF error: [normal kernel read fault]
      [  300.467385] PGD 0 P4D 0
      [  300.467987] Oops: 0000 [#1] SMP PTI
      [  300.468787] CPU: 3 PID: 50 Comm: kworker/u8:1 Not tainted 5.0.20kalray+ #4
      [  300.470264] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      [  300.471532] Workqueue: nvme-wq nvme_scan_work [nvme_core]
      [  300.472724] RIP: 0010:nvme_parse_ana_log+0x21/0x140 [nvme_core]
      [  300.474038] Code: 45 01 d2 d8 48 98 c3 66 90 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 08 48 8b af 20 0a 00 00 48 89 34 24 <66> 83 7d 08 00 0f 84 c6 00 00 00 44 8b 7d 14 49 89 d5 8b 55 10 48
      [  300.477374] RSP: 0018:ffffa50e80fd7cb8 EFLAGS: 00010296
      [  300.478334] RAX: 0000000000000001 RBX: ffff9130f1872258 RCX: 0000000000000000
      [  300.479784] RDX: ffffffffc06c4c30 RSI: ffff9130edad4280 RDI: ffff9130f1872258
      [  300.481488] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044
      [  300.483203] R10: 0000000000000220 R11: 0000000000000040 R12: ffff9130f18722c0
      [  300.484928] R13: ffff9130f18722d0 R14: ffff9130edad4280 R15: ffff9130f18722c0
      [  300.486626] FS:  0000000000000000(0000) GS:ffff9130f7b80000(0000) knlGS:0000000000000000
      [  300.488538] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  300.489907] CR2: 0000000000000008 CR3: 00000002365e6000 CR4: 00000000000006e0
      [  300.491612] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  300.493303] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  300.494991] Call Trace:
      [  300.495645]  nvme_mpath_add_disk+0x5c/0xb0 [nvme_core]
      [  300.496880]  nvme_validate_ns+0x2ef/0x550 [nvme_core]
      [  300.498105]  ? nvme_identify_ctrl.isra.45+0x6a/0xb0 [nvme_core]
      [  300.499539]  nvme_scan_work+0x2b4/0x370 [nvme_core]
      [  300.500717]  ? __switch_to_asm+0x35/0x70
      [  300.501663]  process_one_work+0x171/0x380
      [  300.502340]  worker_thread+0x49/0x3f0
      [  300.503079]  kthread+0xf8/0x130
      [  300.503795]  ? max_active_store+0x80/0x80
      [  300.504690]  ? kthread_bind+0x10/0x10
      [  300.505502]  ret_from_fork+0x35/0x40
      [  300.506280] Modules linked in: nvme_tcp nvme_rdma rdma_cm iw_cm ib_cm ib_core nvme_fabrics nvme_core xt_physdev ip6table_raw ip6table_mangle ip6table_filter ip6_tables xt_comment iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_CHECKSUM iptable_mangle iptable_filter veth ebtable_filter ebtable_nat ebtables iptable_raw vxlan ip6_udp_tunnel udp_tunnel sunrpc joydev pcspkr virtio_balloon br_netfilter bridge stp llc ip_tables xfs libcrc32c ata_generic pata_acpi virtio_net virtio_console net_failover virtio_blk failover ata_piix serio_raw libata virtio_pci virtio_ring virtio
      [  300.514984] CR2: 0000000000000008
      [  300.515569] ---[ end trace faa2eefad7e7f218 ]---
      [  300.516354] RIP: 0010:nvme_parse_ana_log+0x21/0x140 [nvme_core]
      [  300.517330] Code: 45 01 d2 d8 48 98 c3 66 90 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 08 48 8b af 20 0a 00 00 48 89 34 24 <66> 83 7d 08 00 0f 84 c6 00 00 00 44 8b 7d 14 49 89 d5 8b 55 10 48
      [  300.520353] RSP: 0018:ffffa50e80fd7cb8 EFLAGS: 00010296
      [  300.521229] RAX: 0000000000000001 RBX: ffff9130f1872258 RCX: 0000000000000000
      [  300.522399] RDX: ffffffffc06c4c30 RSI: ffff9130edad4280 RDI: ffff9130f1872258
      [  300.523560] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044
      [  300.524734] R10: 0000000000000220 R11: 0000000000000040 R12: ffff9130f18722c0
      [  300.525915] R13: ffff9130f18722d0 R14: ffff9130edad4280 R15: ffff9130f18722c0
      [  300.527084] FS:  0000000000000000(0000) GS:ffff9130f7b80000(0000) knlGS:0000000000000000
      [  300.528396] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  300.529440] CR2: 0000000000000008 CR3: 00000002365e6000 CR4: 00000000000006e0
      [  300.530739] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  300.531989] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  300.533264] Kernel panic - not syncing: Fatal exception
      [  300.534338] Kernel Offset: 0x17c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      [  300.536227] ---[ end Kernel panic - not syncing: Fatal exception ]---
      
      Condition check refactoring from Christoph Hellwig.
      Signed-off-by: NMarta Rybczynska <marta.rybczynska@kalray.eu>
      Tested-by: NJean-Baptiste Riaux <jbriaux@kalray.eu>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bdce5621
    • L
      ACPI/IORT: Fix off-by-one check in iort_dev_find_its_id() · b1689742
      Lorenzo Pieralisi 提交于
      [ Upstream commit 5a46d3f71d5e5a9f82eabc682f996f1281705ac7 ]
      
      Static analysis identified that index comparison against ITS entries in
      iort_dev_find_its_id() is off by one.
      
      Update the comparison condition and clarify the resulting error
      message.
      
      Fixes: 4bf2efd2 ("ACPI: Add new IORT functions to support MSI domain handling")
      Link: https://lore.kernel.org/linux-arm-kernel/20190613065410.GB16334@mwanda/Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b1689742
    • A
      drbd: dynamically allocate shash descriptor · 38c919ec
      Arnd Bergmann 提交于
      [ Upstream commit 77ce56e2bfaa64127ae5e23ef136c0168b818777 ]
      
      Building with clang and KASAN, we get a warning about an overly large
      stack frame on 32-bit architectures:
      
      drivers/block/drbd/drbd_receiver.c:921:31: error: stack frame size of 1280 bytes in function 'conn_connect'
            [-Werror,-Wframe-larger-than=]
      
      We already allocate other data dynamically in this function, so
      just do the same for the shash descriptor, which makes up most of
      this memory.
      
      Link: https://lore.kernel.org/lkml/20190617132440.2721536-1-arnd@arndb.de/Reviewed-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NRoland Kammerer <roland.kammerer@linbit.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      38c919ec
    • J
      s390/qdio: add sanity checks to the fast-requeue path · 77868c00
      Julian Wiedmann 提交于
      [ Upstream commit a6ec414a4dd529eeac5c3ea51c661daba3397108 ]
      
      If the device driver were to send out a full queue's worth of SBALs,
      current code would end up discovering the last of those SBALs as PRIMED
      and erroneously skip the SIGA-w. This immediately stalls the queue.
      
      Add a check to not attempt fast-requeue in this case. While at it also
      make sure that the state of the previous SBAL was successfully extracted
      before inspecting it.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: NJens Remus <jremus@linux.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      77868c00
    • W
      cpufreq/pasemi: fix use-after-free in pas_cpufreq_cpu_init() · 8729fe83
      Wen Yang 提交于
      [ Upstream commit e0a12445d1cb186d875410d093a00d215bec6a89 ]
      
      The cpu variable is still being used in the of_get_property() call
      after the of_node_put() call, which may result in use-after-free.
      
      Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
      Signed-off-by: NWen Yang <wen.yang99@zte.com.cn>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8729fe83
    • Q
      drm: silence variable 'conn' set but not used · 991c4756
      Qian Cai 提交于
      [ Upstream commit bbb6fc43f131f77fcb7ae8081f6d7c51396a2120 ]
      
      The "struct drm_connector" iteration cursor from
      "for_each_new_connector_in_state" is never used in atomic_remove_fb()
      which generates a compilation warning,
      
      drivers/gpu/drm/drm_framebuffer.c: In function 'atomic_remove_fb':
      drivers/gpu/drm/drm_framebuffer.c:838:24: warning: variable 'conn' set
      but not used [-Wunused-but-set-variable]
      
      Silence it by marking "conn" __maybe_unused.
      Signed-off-by: NQian Cai <cai@lca.pw>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/1563822886-13570-1-git-send-email-cai@lca.pwSigned-off-by: NSasha Levin <sashal@kernel.org>
      991c4756
    • B
      hwmon: (nct6775) Fix register address and added missed tolerance for nct6106 · ca1b1940
      Björn Gerhart 提交于
      [ Upstream commit f3d43e2e45fd9d44ba52d20debd12cd4ee9c89bf ]
      
      Fixed address of third NCT6106_REG_WEIGHT_DUTY_STEP, and
      added missed NCT6106_REG_TOLERANCE_H.
      
      Fixes: 6c009501 ("hwmon: (nct6775) Add support for NCT6102D/6106D")
      Signed-off-by: NBjoern Gerhart <gerhart@posteo.de>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ca1b1940
    • N
      allocate_flower_entry: should check for null deref · 56dc57c7
      Navid Emamdoost 提交于
      [ Upstream commit bb1320834b8a80c6ac2697ab418d066981ea08ba ]
      
      allocate_flower_entry does not check for allocation success, but tries
      to deref the result. I only moved the spin_lock under null check, because
       the caller is checking allocation's status at line 652.
      Signed-off-by: NNavid Emamdoost <navid.emamdoost@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      56dc57c7
    • T
      iscsi_ibft: make ISCSI_IBFT dependson ACPI instead of ISCSI_IBFT_FIND · 492c158a
      Thomas Tai 提交于
      [ Upstream commit 94bccc34071094c165c79b515d21b63c78f7e968 ]
      
      iscsi_ibft can use ACPI to find the iBFT entry during bootup,
      currently, ISCSI_IBFT depends on ISCSI_IBFT_FIND which is
      a X86 legacy way to find the iBFT by searching through the
      low memory. This patch changes the dependency so that other
      arch like ARM64 can use ISCSI_IBFT as long as the arch supports
      ACPI.
      
      ibft_init() needs to use the global variable ibft_addr declared
      in iscsi_ibft_find.c. A #ifndef CONFIG_ISCSI_IBFT_FIND is needed
      to declare the variable if CONFIG_ISCSI_IBFT_FIND is not selected.
      Moving ibft_addr into the iscsi_ibft.c does not work because if
      ISCSI_IBFT is selected as a module, the arch/x86/kernel/setup.c won't
      be able to find the variable at compile time.
      Signed-off-by: NThomas Tai <thomas.tai@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      492c158a
    • T
      drm/amd/display: Increase size of audios array · 8d641499
      Tai Man 提交于
      [ Upstream commit 7352193a33dfc9b69ba3bf6a8caea925b96243b1 ]
      
      [Why]
      The audios array defined in "struct resource_pool" is only 6 (MAX_PIPES)
      but the max number of audio devices (num_audio) is 7. In some projects,
      it will run out of audios array.
      
      [How]
      Incraese the audios array size to 7.
      Signed-off-by: NTai Man <taiman.wong@amd.com>
      Reviewed-by: NJoshua Aberback <Joshua.Aberback@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8d641499
    • A
      drm/amd/display: Only enable audio if speaker allocation exists · f9420bfa
      Alvin Lee 提交于
      [ Upstream commit 6ac25e6d5b2fbf251e9fa2f4131d42c815b43867 ]
      
      [Why]
      
      In dm_helpers_parse_edid_caps, there is a corner case where no speakers
      can be allocated even though the audio mode count is greater than 0.
      Enabling audio when no speaker allocations exists can cause issues in
      the video stream.
      
      [How]
      
      Add a check to not enable audio unless one or more speaker allocations
      exist (since doing this can cause issues in the video stream).
      Signed-off-by: NAlvin Lee <alvin.lee2@amd.com>
      Reviewed-by: NJun Lei <Jun.Lei@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f9420bfa
    • J
      drm/amd/display: Fix dc_create failure handling and 666 color depths · 3998e684
      Julian Parkin 提交于
      [ Upstream commit 0905f32977268149f06e3ce6ea4bd6d374dd891f ]
      
      [Why]
      It is possible (but very unlikely) that constructing dc fails
      before current_state is created.
      
      We support 666 color depth in some scenarios, but this
      isn't handled in get_norm_pix_clk. It uses exactly the
      same pixel clock as the 888 case.
      
      [How]
      Check for non null current_state before destructing.
      
      Add case for 666 color depth to get_norm_pix_clk to
      avoid assertion.
      Signed-off-by: NJulian Parkin <julian.parkin@amd.com>
      Reviewed-by: NCharlene Liu <Charlene.Liu@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3998e684
    • T
      drm/amd/display: use encoder's engine id to find matched free audio device · e7a8a794
      Tai Man 提交于
      [ Upstream commit 74eda776d7a4e69ec7aa1ce30a87636f14220fbb ]
      
      [Why]
      On some platforms, the encoder id 3 is not populated. So the encoders
      are not stored in right order as index (id: 0, 1, 2, 4, 5) at pool. This
      would cause encoders id 4 & id 5 to fail when finding corresponding
      audio device, defaulting to the first available audio device. As result,
      we cannot stream audio into two DP ports with encoders id 4 & id 5.
      
      [How]
      It need to create enough audio device objects (0 - 5) to perform matching.
      Then use encoder engine id to find matched audio device.
      Signed-off-by: NTai Man <taiman.wong@amd.com>
      Reviewed-by: NCharlene Liu <Charlene.Liu@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e7a8a794
    • S
      drm/amd/display: Wait for backlight programming completion in set backlight level · 2a5e21ad
      SivapiriyanKumarasamy 提交于
      [ Upstream commit c7990daebe71d11a9e360b5c3b0ecd1846a3a4bb ]
      
      [WHY]
      Currently we don't wait for blacklight programming completion in DMCU
      when setting backlight level. Some sequences such as PSR static screen
      event trigger reprogramming requires it to be complete.
      
      [How]
      Add generic wait for dmcu command completion in set backlight level.
      Signed-off-by: NSivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com>
      Reviewed-by: NAnthony Koo <Anthony.Koo@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2a5e21ad
    • F
      vfio-ccw: Set pa_nr to 0 if memory allocation fails for pa_iova_pfn · 6f9dff8d
      Farhan Ali 提交于
      [ Upstream commit c1ab69268d124ebdbb3864580808188ccd3ea355 ]
      
      So we don't call try to call vfio_unpin_pages() incorrectly.
      
      Fixes: 0a19e61e ("vfio: ccw: introduce channel program interfaces")
      Signed-off-by: NFarhan Ali <alifm@linux.ibm.com>
      Reviewed-by: NEric Farman <farman@linux.ibm.com>
      Reviewed-by: NCornelia Huck <cohuck@redhat.com>
      Message-Id: <33a89467ad6369196ae6edf820cbcb1e2d8d050c.1562854091.git.alifm@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6f9dff8d
    • S
      can: peak_usb: fix potential double kfree_skb() · f61c4d3a
      Stephane Grosjean 提交于
      commit fee6a8923ae0d318a7f7950c6c6c28a96cea099b upstream.
      
      When closing the CAN device while tx skbs are inflight, echo skb could
      be released twice. By calling close_candev() before unlinking all
      pending tx urbs, then the internal echo_skb[] array is fully and
      correctly cleared before the USB write callback and, therefore,
      can_get_echo_skb() are called, for each aborted URB.
      
      Fixes: bb478555 ("can: usb: PEAK-System Technik USB adapters driver core")
      Signed-off-by: NStephane Grosjean <s.grosjean@peak-system.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f61c4d3a
    • N
      can: rcar_canfd: fix possible IRQ storm on high load · 0e9038a2
      Nikita Yushchenko 提交于
      commit d4b890aec4bea7334ca2ca56fd3b12fb48a00cd1 upstream.
      
      We have observed rcar_canfd driver entering IRQ storm under high load,
      with following scenario:
      - rcar_canfd_global_interrupt() in entered due to Rx available,
      - napi_schedule_prep() is called, and sets NAPIF_STATE_SCHED in state
      - Rx fifo interrupts are masked,
      - rcar_canfd_global_interrupt() is entered again, this time due to
        error interrupt (e.g. due to overflow),
      - since scheduled napi poller has not yet executed, condition for calling
        napi_schedule_prep() from rcar_canfd_global_interrupt() remains true,
        thus napi_schedule_prep() gets called and sets NAPIF_STATE_MISSED flag
        in state,
      - later, napi poller function rcar_canfd_rx_poll() gets executed, and
        calls napi_complete_done(),
      - due to NAPIF_STATE_MISSED flag in state, this call does not clear
        NAPIF_STATE_SCHED flag from state,
      - on return from napi_complete_done(), rcar_canfd_rx_poll() unmasks Rx
        interrutps,
      - Rx interrupt happens, rcar_canfd_global_interrupt() gets called
        and calls napi_schedule_prep(),
      - since NAPIF_STATE_SCHED is set in state at this time, this call
        returns false,
      - due to that false return, rcar_canfd_global_interrupt() returns
        without masking Rx interrupt
      - and this results into IRQ storm: unmasked Rx interrupt happens again
        and again is misprocessed in the same way.
      
      This patch fixes that scenario by unmasking Rx interrupts only when
      napi_complete_done() returns true, which means it has cleared
      NAPIF_STATE_SCHED in state.
      
      Fixes: dd3bd23e ("can: rcar_canfd: Add Renesas R-Car CAN FD driver")
      Signed-off-by: NNikita Yushchenko <nikita.yoush@cogentembedded.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e9038a2
    • G
      usb: typec: tcpm: Ignore unsupported/unknown alternate mode requests · 9479a058
      Guenter Roeck 提交于
      commit 88d02c9ba2e83fc22d37ccb1f11c62ea6fc9ae50 upstream.
      
      TCPM may receive PD messages associated with unknown or unsupported
      alternate modes. If that happens, calls to typec_match_altmode()
      will return NULL. The tcpm code does not currently take this into
      account. This results in crashes.
      
      Unable to handle kernel NULL pointer dereference at virtual address 000001f0
      pgd = 41dad9a1
      [000001f0] *pgd=00000000
      Internal error: Oops: 5 [#1] THUMB2
      Modules linked in: tcpci tcpm
      CPU: 0 PID: 2338 Comm: kworker/u2:0 Not tainted 5.1.18-sama5-armv7-r2 #6
      Hardware name: Atmel SAMA5
      Workqueue: 2-0050 tcpm_pd_rx_handler [tcpm]
      PC is at typec_altmode_attention+0x0/0x14
      LR is at tcpm_pd_rx_handler+0xa3b/0xda0 [tcpm]
      ...
      [<c03fbee8>] (typec_altmode_attention) from [<bf8030fb>]
      				(tcpm_pd_rx_handler+0xa3b/0xda0 [tcpm])
      [<bf8030fb>] (tcpm_pd_rx_handler [tcpm]) from [<c012082b>]
      				(process_one_work+0x123/0x2a8)
      [<c012082b>] (process_one_work) from [<c0120a6d>]
      				(worker_thread+0xbd/0x3b0)
      [<c0120a6d>] (worker_thread) from [<c012431f>] (kthread+0xcf/0xf4)
      [<c012431f>] (kthread) from [<c01010f9>] (ret_from_fork+0x11/0x38)
      
      Ignore PD messages if the associated alternate mode is not supported.
      
      Fixes: e9576fe8 ("usb: typec: tcpm: Support for Alternate Modes")
      Cc: stable <stable@vger.kernel.org>
      Reported-by: NDouglas Gilbert <dgilbert@interlog.com>
      Cc: Douglas Gilbert <dgilbert@interlog.com>
      Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Tested-by: NDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/1564761822-13984-1-git-send-email-linux@roeck-us.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9479a058
    • G
      usb: typec: tcpm: Add NULL check before dereferencing config · 3f524b63
      Guenter Roeck 提交于
      commit 1957de95d425d1c06560069dc7277a73a8b28683 upstream.
      
      When instantiating tcpm on an NXP OM 13588 board with NXP PTN5110,
      the following crash is seen when writing into the 'preferred_role'
      sysfs attribute.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000028
      pgd = f69149ad
      [00000028] *pgd=00000000
      Internal error: Oops: 5 [#1] THUMB2
      Modules linked in: tcpci tcpm
      CPU: 0 PID: 1882 Comm: bash Not tainted 5.1.18-sama5-armv7-r2 #4
      Hardware name: Atmel SAMA5
      PC is at tcpm_try_role+0x3a/0x4c [tcpm]
      LR is at tcpm_try_role+0x15/0x4c [tcpm]
      pc : [<bf8000e2>]    lr : [<bf8000bd>]    psr: 60030033
      sp : dc1a1e88  ip : c03fb47d  fp : 00000000
      r10: dc216190  r9 : dc1a1f78  r8 : 00000001
      r7 : df4ae044  r6 : dd032e90  r5 : dd1ce340  r4 : df4ae054
      r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : df4ae044
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment none
      Control: 50c53c7d  Table: 3efec059  DAC: 00000051
      Process bash (pid: 1882, stack limit = 0x6a6d4aa5)
      Stack: (0xdc1a1e88 to 0xdc1a2000)
      1e80:                   dd05d808 dd1ce340 00000001 00000007 dd1ce340 c03fb4a7
      1ea0: 00000007 00000007 dc216180 00000000 00000000 c01e1e03 00000000 00000000
      1ec0: c0907008 dee98b40 c01e1d5d c06106c4 00000000 00000000 00000007 c0194e8b
      1ee0: 0000000a 00000400 00000000 c01a97db dc22bf00 ffffe000 df4b6a00 df745900
      1f00: 00000001 00000001 000000dd c01a9c2f 7aeab3be c0907008 00000000 dc22bf00
      1f20: c0907008 00000000 00000000 00000000 00000000 7aeab3be 00000007 dee98b40
      1f40: 005dc318 dc1a1f78 00000000 00000000 00000007 c01969f7 0000000a c01a20cb
      1f60: dee98b40 c0907008 dee98b40 005dc318 00000000 c0196b9b 00000000 00000000
      1f80: dee98b40 7aeab3be 00000074 005dc318 b6f3bdb0 00000004 c0101224 dc1a0000
      1fa0: 00000004 c0101001 00000074 005dc318 00000001 005dc318 00000007 00000000
      1fc0: 00000074 005dc318 b6f3bdb0 00000004 00000007 00000007 00000000 00000000
      1fe0: 00000004 be800880 b6ed35b3 b6e5c746 60030030 00000001 00000000 00000000
      [<bf8000e2>] (tcpm_try_role [tcpm]) from [<c03fb4a7>] (preferred_role_store+0x2b/0x5c)
      [<c03fb4a7>] (preferred_role_store) from [<c01e1e03>] (kernfs_fop_write+0xa7/0x150)
      [<c01e1e03>] (kernfs_fop_write) from [<c0194e8b>] (__vfs_write+0x1f/0x104)
      [<c0194e8b>] (__vfs_write) from [<c01969f7>] (vfs_write+0x6b/0x104)
      [<c01969f7>] (vfs_write) from [<c0196b9b>] (ksys_write+0x43/0x94)
      [<c0196b9b>] (ksys_write) from [<c0101001>] (ret_fast_syscall+0x1/0x62)
      
      Since commit 96232cbc ("usb: typec: tcpm: support get typec and pd
      config from device properties"), the 'config' pointer in struct tcpc_dev
      is optional when registering a Type-C port. Since it is optional, we have
      to check if it is NULL before dereferencing it.
      Reported-by: NDouglas Gilbert <dgilbert@interlog.com>
      Cc: Douglas Gilbert <dgilbert@interlog.com>
      Fixes: 96232cbc ("usb: typec: tcpm: support get typec and pd config from device properties")
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: NJun Li <jun.li@nxp.com>
      Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Link: https://lore.kernel.org/r/1563979112-22483-1-git-send-email-linux@roeck-us.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f524b63
    • L
      usb: typec: tcpm: remove tcpm dir if no children · bbc2e820
      Li Jun 提交于
      commit 12ca7297b8855c0af1848503d37196159b24e6b9 upstream.
      
      If config tcpm as module, module unload will not remove tcpm dir,
      then the next module load will have problem: the rootdir is NULL
      but tcpm dir is still there, so tcpm_debugfs_init() will create
      tcpm dir again with failure, fix it by remove the tcpm dir if no
      children.
      
      Cc: stable@vger.kernel.org # v4.15+
      Fixes: 4b4e02c8 ("typec: tcpm: Move out of staging")
      Signed-off-by: NLi Jun <jun.li@nxp.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20190717080646.30421-2-jun.li@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bbc2e820
    • L
      usb: typec: tcpm: free log buf memory when remove debug file · 2ec5c9b7
      Li Jun 提交于
      commit fd5da3e2cc61b4a7c877172fdc9348c82cf6ccfc upstream.
      
      The logbuffer memory should be freed when remove debug file.
      
      Cc: stable@vger.kernel.org # v4.15+
      Fixes: 4b4e02c8 ("typec: tcpm: Move out of staging")
      Signed-off-by: NLi Jun <jun.li@nxp.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20190717080646.30421-1-jun.li@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ec5c9b7
    • S
      usb: yurex: Fix use-after-free in yurex_delete · 33f2240a
      Suzuki K Poulose 提交于
      commit fc05481b2fcabaaeccf63e32ac1baab54e5b6963 upstream.
      
      syzbot reported the following crash [0]:
      
      BUG: KASAN: use-after-free in usb_free_coherent+0x79/0x80
      drivers/usb/core/usb.c:928
      Read of size 8 at addr ffff8881b18599c8 by task syz-executor.4/16007
      
      CPU: 0 PID: 16007 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #23
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:77 [inline]
        dump_stack+0xca/0x13e lib/dump_stack.c:113
        print_address_description+0x6a/0x32c mm/kasan/report.c:351
        __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
        kasan_report+0xe/0x12 mm/kasan/common.c:612
        usb_free_coherent+0x79/0x80 drivers/usb/core/usb.c:928
        yurex_delete+0x138/0x330 drivers/usb/misc/yurex.c:100
        kref_put include/linux/kref.h:65 [inline]
        yurex_release+0x66/0x90 drivers/usb/misc/yurex.c:392
        __fput+0x2d7/0x840 fs/file_table.c:280
        task_work_run+0x13f/0x1c0 kernel/task_work.c:113
        tracehook_notify_resume include/linux/tracehook.h:188 [inline]
        exit_to_usermode_loop+0x1d2/0x200 arch/x86/entry/common.c:163
        prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
        syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
        do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x413511
      Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48
      83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48
      89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
      RSP: 002b:00007ffc424ea2e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
      RAX: 0000000000000000 RBX: 0000000000000007 RCX: 0000000000413511
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000006
      RBP: 0000000000000001 R08: 0000000029a2fc22 R09: 0000000029a2fc26
      R10: 00007ffc424ea3c0 R11: 0000000000000293 R12: 000000000075c9a0
      R13: 000000000075c9a0 R14: 0000000000761938 R15: ffffffffffffffff
      
      Allocated by task 2776:
        save_stack+0x1b/0x80 mm/kasan/common.c:69
        set_track mm/kasan/common.c:77 [inline]
        __kasan_kmalloc mm/kasan/common.c:487 [inline]
        __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
        kmalloc include/linux/slab.h:552 [inline]
        kzalloc include/linux/slab.h:748 [inline]
        usb_alloc_dev+0x51/0xf95 drivers/usb/core/usb.c:583
        hub_port_connect drivers/usb/core/hub.c:5004 [inline]
        hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
        port_event drivers/usb/core/hub.c:5359 [inline]
        hub_event+0x15c0/0x3640 drivers/usb/core/hub.c:5441
        process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
        worker_thread+0x96/0xe20 kernel/workqueue.c:2415
        kthread+0x318/0x420 kernel/kthread.c:255
        ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      Freed by task 16007:
        save_stack+0x1b/0x80 mm/kasan/common.c:69
        set_track mm/kasan/common.c:77 [inline]
        __kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
        slab_free_hook mm/slub.c:1423 [inline]
        slab_free_freelist_hook mm/slub.c:1470 [inline]
        slab_free mm/slub.c:3012 [inline]
        kfree+0xe4/0x2f0 mm/slub.c:3953
        device_release+0x71/0x200 drivers/base/core.c:1064
        kobject_cleanup lib/kobject.c:693 [inline]
        kobject_release lib/kobject.c:722 [inline]
        kref_put include/linux/kref.h:65 [inline]
        kobject_put+0x171/0x280 lib/kobject.c:739
        put_device+0x1b/0x30 drivers/base/core.c:2213
        usb_put_dev+0x1f/0x30 drivers/usb/core/usb.c:725
        yurex_delete+0x40/0x330 drivers/usb/misc/yurex.c:95
        kref_put include/linux/kref.h:65 [inline]
        yurex_release+0x66/0x90 drivers/usb/misc/yurex.c:392
        __fput+0x2d7/0x840 fs/file_table.c:280
        task_work_run+0x13f/0x1c0 kernel/task_work.c:113
        tracehook_notify_resume include/linux/tracehook.h:188 [inline]
        exit_to_usermode_loop+0x1d2/0x200 arch/x86/entry/common.c:163
        prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
        syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
        do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8881b1859980
        which belongs to the cache kmalloc-2k of size 2048
      The buggy address is located 72 bytes inside of
        2048-byte region [ffff8881b1859980, ffff8881b185a180)
      The buggy address belongs to the page:
      page:ffffea0006c61600 refcount:1 mapcount:0 mapping:ffff8881da00c000
      index:0x0 compound_mapcount: 0
      flags: 0x200000000010200(slab|head)
      raw: 0200000000010200 0000000000000000 0000000100000001 ffff8881da00c000
      raw: 0000000000000000 00000000000f000f 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
        ffff8881b1859880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff8881b1859900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      > ffff8881b1859980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                     ^
        ffff8881b1859a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff8881b1859a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      A quick look at the yurex_delete() shows that we drop the reference
      to the usb_device before releasing any buffers associated with the
      device. Delay the reference drop until we have finished the cleanup.
      
      [0] https://lore.kernel.org/lkml/0000000000003f86d8058f0bd671@google.com/
      
      Fixes: 6bc235a2 ("USB: add driver for Meywa-Denki & Kayac YUREX")
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com>
      Cc: Oliver Neukum <oneukum@suse.com>
      Cc: andreyknvl@google.com
      Cc: gregkh@linuxfoundation.org
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: syzkaller-bugs@googlegroups.com
      Cc: dtor@chromium.org
      Reported-by: syzbot+d1fedb1c1fdb07fca507@syzkaller.appspotmail.com
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20190805111528.6758-1-suzuki.poulose@arm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33f2240a
    • Y
      usb: host: xhci-rcar: Fix timeout in xhci_suspend() · 49888a4f
      Yoshihiro Shimoda 提交于
      commit 783bda5e41acc71f98336e1a402c180f9748e5dc upstream.
      
      When a USB device is connected to the host controller and
      the system enters suspend, the following error happens
      in xhci_suspend():
      
      	xhci-hcd ee000000.usb: WARN: xHC CMD_RUN timeout
      
      Since the firmware/internal CPU control the USBSTS.STS_HALT
      and the process speed is down when the roothub port enters U3,
      long delay for the handshake of STS_HALT is neeed in xhci_suspend().
      So, this patch adds to set the XHCI_SLOW_SUSPEND.
      
      Fixes: 435cc113 ("usb: host: xhci-plat: set resume_quirk() for R-Car controllers")
      Cc: <stable@vger.kernel.org> # v4.12+
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Link: https://lore.kernel.org/r/1564734815-17964-1-git-send-email-yoshihiro.shimoda.uh@renesas.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49888a4f
    • D
      Input: synaptics - enable RMI mode for HP Spectre X360 · b8a2169b
      Dmitry Torokhov 提交于
      commit 25f8c834e2a6871920cc1ca113f02fb301d007c3 upstream.
      
      The 2016 kabylake HP Spectre X360 (model number 13-w013dx) works much better
      with psmouse.synaptics_intertouch=1 kernel parameter, so let's enable RMI4
      mode automatically.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204115Reported-by: NNate Graham <pointedstick@zoho.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8a2169b
    • K
      Input: elantech - enable SMBus on new (2018+) systems · 3d180fe5
      Kai-Heng Feng 提交于
      commit 883a2a80f79ca5c0c105605fafabd1f3df99b34c upstream.
      
      There are some new HP laptops with Elantech touchpad that don't support
      multitouch.
      
      Currently we use ETP_NEW_IC_SMBUS_HOST_NOTIFY() to check if SMBus is supported,
      but in addition to firmware version, the bus type also informs us whether the IC
      can support SMBus. To avoid breaking old ICs, we will only enable SMbus support
      based the bus type on systems manufactured after 2018.
      
      Lastly, let's consolidate all checks into elantech_use_host_notify() and use it
      to determine whether to use PS/2 or SMBus.
      Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d180fe5
    • O
      Input: usbtouchscreen - initialize PM mutex before using it · ce7d4fe4
      Oliver Neukum 提交于
      commit b55d996f057bf2e7ba9422a80b5e17e99860cb0b upstream.
      
      Mutexes shall be initialized before they are used.
      
      Fixes: 12e510db ("Input: usbtouchscreen - fix deadlock in autosuspend")
      Reported-by: syzbot+199ea16c7f26418b4365@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce7d4fe4