1. 20 4月, 2019 40 次提交
    • K
      drm/amdkfd: use init_mqd function to allocate object for hid_mqd (CI) · 539282e9
      Kevin Wang 提交于
      [ Upstream commit cac734c2dbd2514f14c8c6a17caba1990d83bf1d ]
      
      if use the legacy method to allocate object, when mqd_hiq need to run
      uninit code, it will be cause WARNING call trace.
      
      eg: (s3 suspend test)
      [   34.918944] Call Trace:
      [   34.918948]  [<ffffffff92961dc1>] dump_stack+0x19/0x1b
      [   34.918950]  [<ffffffff92297648>] __warn+0xd8/0x100
      [   34.918951]  [<ffffffff9229778d>] warn_slowpath_null+0x1d/0x20
      [   34.918991]  [<ffffffffc03ce1fe>] uninit_mqd_hiq_sdma+0x4e/0x50 [amdgpu]
      [   34.919028]  [<ffffffffc03d0ef7>] uninitialize+0x37/0xe0 [amdgpu]
      [   34.919064]  [<ffffffffc03d15a6>] kernel_queue_uninit+0x16/0x30 [amdgpu]
      [   34.919086]  [<ffffffffc03d26c2>] pm_uninit+0x12/0x20 [amdgpu]
      [   34.919107]  [<ffffffffc03d4915>] stop_nocpsch+0x15/0x20 [amdgpu]
      [   34.919129]  [<ffffffffc03c1dce>] kgd2kfd_suspend.part.4+0x2e/0x50 [amdgpu]
      [   34.919150]  [<ffffffffc03c2667>] kgd2kfd_suspend+0x17/0x20 [amdgpu]
      [   34.919171]  [<ffffffffc03c103a>] amdgpu_amdkfd_suspend+0x1a/0x20 [amdgpu]
      [   34.919187]  [<ffffffffc02ec428>] amdgpu_device_suspend+0x88/0x3a0 [amdgpu]
      [   34.919189]  [<ffffffff922e22cf>] ? enqueue_entity+0x2ef/0xbe0
      [   34.919205]  [<ffffffffc02e8220>] amdgpu_pmops_suspend+0x20/0x30 [amdgpu]
      [   34.919207]  [<ffffffff925c56ff>] pci_pm_suspend+0x6f/0x150
      [   34.919208]  [<ffffffff925c5690>] ? pci_pm_freeze+0xf0/0xf0
      [   34.919210]  [<ffffffff926b45c6>] dpm_run_callback+0x46/0x90
      [   34.919212]  [<ffffffff926b49db>] __device_suspend+0xfb/0x2a0
      [   34.919213]  [<ffffffff926b4b9f>] async_suspend+0x1f/0xa0
      [   34.919214]  [<ffffffff922c918f>] async_run_entry_fn+0x3f/0x130
      [   34.919216]  [<ffffffff922b9d4f>] process_one_work+0x17f/0x440
      [   34.919217]  [<ffffffff922bade6>] worker_thread+0x126/0x3c0
      [   34.919218]  [<ffffffff922bacc0>] ? manage_workers.isra.25+0x2a0/0x2a0
      [   34.919220]  [<ffffffff922c1c31>] kthread+0xd1/0xe0
      [   34.919221]  [<ffffffff922c1b60>] ? insert_kthread_work+0x40/0x40
      [   34.919222]  [<ffffffff92974c1d>] ret_from_fork_nospec_begin+0x7/0x21
      [   34.919224]  [<ffffffff922c1b60>] ? insert_kthread_work+0x40/0x40
      [   34.919224] ---[ end trace 38cd9f65c963adad ]---
      Signed-off-by: NKevin Wang <kevin1.wang@amd.com>
      Reviewed-by: NOak Zeng <Oak.Zeng@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      539282e9
    • Y
      ARM: 8839/1: kprobe: make patch_lock a raw_spinlock_t · 91583411
      Yang Shi 提交于
      [ Upstream commit 143c2a89e0e5fda6c6fd08d7bc1126438c19ae90 ]
      
      When running kprobe on -rt kernel, the below bug is caught:
      
      |BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
      |in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
      |Preemption disabled at:[<802f2b98>] cpu_stopper_thread+0xc0/0x140
      |CPU: 0 PID: 14 Comm: migration/0 Tainted: G O 4.8.3-rt2 #1
      |Hardware name: Freescale LS1021A
      |[<8025a43c>] (___might_sleep)
      |[<80b5b324>] (rt_spin_lock)
      |[<80b5c31c>] (__patch_text_real)
      |[<80b5c3ac>] (patch_text_stop_machine)
      |[<802f2920>] (multi_cpu_stop)
      
      Since patch_text_stop_machine() is called in stop_machine() which
      disables IRQ, sleepable lock should be not used in this atomic context,
       so replace patch_lock to raw lock.
      Signed-off-by: NYang Shi <yang.shi@linaro.org>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      91583411
    • I
      drm/nouveau/volt/gf117: fix speedo readout register · 1b871f39
      Ilia Mirkin 提交于
      [ Upstream commit fc782242749fa4235592854fafe1a1297583c1fb ]
      
      GF117 appears to use the same register as GK104 (but still with the
      general Fermi readout mechanism).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1b871f39
    • M
      PCI: Blacklist power management of Gigabyte X299 DESIGNARE EX PCIe ports · ad854fa3
      Mika Westerberg 提交于
      [ Upstream commit 85b0cae89d5266e6a7abb2e83c6f716326fc494c ]
      
      Gigabyte X299 DESIGNARE EX motherboard has one PCIe root port that is
      connected to an Alpine Ridge Thunderbolt controller.  This port has slot
      implemented bit set in the config space but other than that it is not
      hotplug capable in the sense we are expecting in Linux (it has
      dev->is_hotplug_bridge set to 0):
      
        00:1c.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5
          Bus: primary=00, secondary=05, subordinate=46, sec-latency=0
          Memory behind bridge: 78000000-8fffffff [size=384M]
          Prefetchable memory behind bridge: 00003800f8000000-00003800ffffffff [size=128M]
          ...
          Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
          ...
            SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
      	      Slot #8, PowerLimit 25.000W; Interlock- NoCompl+
            SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
      	      Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
            SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
      	      Changed: MRL- PresDet+ LinkState+
      
      This system is using ACPI based hotplug to notify the OS that it needs to
      rescan the PCI bus (ACPI hotplug).
      
      If there is nothing connected in any of the Thunderbolt ports the root port
      will not have any runtime PM active children and is thus automatically
      runtime suspended pretty soon after boot by PCI PM core.  Now, when a
      device is connected the BIOS SMI handler responsible for enumerating newly
      added devices is not able to find anything because the port is in D3.
      
      Prevent this from happening by blacklisting PCI power management of this
      particular Gigabyte system.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=202031Reported-by: NKedar A Dongre <kedar.a.dongre@intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ad854fa3
    • L
      coresight: cpu-debug: Support for CA73 CPUs · 4984d918
      Leo Yan 提交于
      [ Upstream commit a0f890aba2be33377f4eb24e13633c4a76a68f38 ]
      
      This patch is to add the AMBA device ID for CA73 CPU, so that CPU debug
      module can be initialized successfully when a SoC contain CA73 CPUs.
      
      This patch has been verified on 96boards Hikey960.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4984d918
    • Z
      Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk" · 2a3c322d
      Zhang Rui 提交于
      [ Upstream commit b6a3e1475b0220378ad32bdf4d8692f058b1fc03 ]
      
      On some Samsung hardware, it is necessary to clear events accumulated by
      the EC during sleep. These ECs stop reporting GPEs until they are manually
      polled, if too many events are accumulated.
      Thus the CLEAR_ON_RESUME quirk is introduced to send EC query commands
      unconditionally after resume to clear all the EC query events on those
      platforms.
      
      Later, commit 4c237371 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk")
      removes the CLEAR_ON_RESUME quirk because we thought the new EC IRQ
      polling logic should handle this case.
      
      Now it has been proved that the EC IRQ Polling logic does not fix the
      issue actually because we got regression report on these Samsung
      platforms after removing the quirk.
      
      Thus revert commit 4c237371 ("ACPI / EC: Remove old CLEAR_ON_RESUME
      quirk") to introduce back the Samsung quirk in this patch.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161Tested-by: NOrtwin Glück <odi@odi.ch>
      Tested-by: NFrancisco Cribari <cribari@gmail.com>
      Tested-by: NBalazs Varga <balazs4web@gmail.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2a3c322d
    • L
      crypto: axis - fix for recursive locking from bottom half · 5f516d0b
      Lars Persson 提交于
      [ Upstream commit c34a83820f59bb275e5f2d55cd5ea99c64f6ef23 ]
      
      Clients may submit a new requests from the completion callback
      context. The driver was not prepared to receive a request in this
      state because it already held the request queue lock and a recursive
      lock error is triggered.
      
      Now all completions are queued up until we are ready to drop the queue
      lock and then delivered.
      
      The fault was triggered by TCP over an IPsec connection in the LTP
      test suite:
        LTP: starting tcp4_ipsec02 (tcp_ipsec.sh -p ah -m transport -s "100 1000 65535")
        BUG: spinlock recursion on CPU#1, genload/943
         lock: 0xbf3c3094, .magic: dead4ead, .owner: genload/943, .owner_cpu: 1
        CPU: 1 PID: 943 Comm: genload Tainted: G           O    4.9.62-axis5-devel #6
        Hardware name: Axis ARTPEC-6 Platform
         (unwind_backtrace) from [<8010d134>] (show_stack+0x18/0x1c)
         (show_stack) from [<803a289c>] (dump_stack+0x84/0x98)
         (dump_stack) from [<8016e164>] (do_raw_spin_lock+0x124/0x128)
         (do_raw_spin_lock) from [<804de1a4>] (artpec6_crypto_submit+0x2c/0xa0)
         (artpec6_crypto_submit) from [<804def38>] (artpec6_crypto_prepare_submit_hash+0xd0/0x54c)
         (artpec6_crypto_prepare_submit_hash) from [<7f3165f0>] (ah_output+0x2a4/0x3dc [ah4])
         (ah_output [ah4]) from [<805df9bc>] (xfrm_output_resume+0x178/0x4a4)
         (xfrm_output_resume) from [<805d283c>] (xfrm4_output+0xac/0xbc)
         (xfrm4_output) from [<80587928>] (ip_queue_xmit+0x140/0x3b4)
         (ip_queue_xmit) from [<805a13b4>] (tcp_transmit_skb+0x4c4/0x95c)
         (tcp_transmit_skb) from [<8059f218>] (tcp_rcv_state_process+0xdf4/0xdfc)
         (tcp_rcv_state_process) from [<805a7530>] (tcp_v4_do_rcv+0x64/0x1ac)
         (tcp_v4_do_rcv) from [<805a9724>] (tcp_v4_rcv+0xa34/0xb74)
         (tcp_v4_rcv) from [<80581d34>] (ip_local_deliver_finish+0x78/0x2b0)
         (ip_local_deliver_finish) from [<8058259c>] (ip_local_deliver+0xe4/0x104)
         (ip_local_deliver) from [<805d23ec>] (xfrm4_transport_finish+0xf4/0x144)
         (xfrm4_transport_finish) from [<805df564>] (xfrm_input+0x4f4/0x74c)
         (xfrm_input) from [<804de420>] (artpec6_crypto_task+0x208/0x38c)
         (artpec6_crypto_task) from [<801271b0>] (tasklet_action+0x60/0xec)
         (tasklet_action) from [<801266d4>] (__do_softirq+0xcc/0x3a4)
         (__do_softirq) from [<80126d20>] (irq_exit+0xf4/0x15c)
         (irq_exit) from [<801741e8>] (__handle_domain_irq+0x68/0xbc)
         (__handle_domain_irq) from [<801014f0>] (gic_handle_irq+0x50/0x94)
         (gic_handle_irq) from [<80657370>] (__irq_usr+0x50/0x80)
      Signed-off-by: NLars Persson <larper@axis.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5f516d0b
    • H
      drm/panel: panel-innolux: set display off in innolux_panel_unprepare · 862adb5b
      Hsin-Yi, Wang 提交于
      [ Upstream commit 46f3ceaffa81e846677bca8668e0ad40e643cffd ]
      
      Move mipi_dsi_dcs_set_display_off() from innolux_panel_disable()
      to innolux_panel_unprepare(), so they are consistent with
      innolux_panel_enable() and innolux_panel_prepare().
      
      This also fixes some mode check and irq timeout issue in MTK dsi code.
      
      Since some dsi code (e.g. mtk_dsi) have following call trace:
      1. drm_panel_disable(), which calls innolux_panel_disable()
      2. switch to cmd mode
      3. drm_panel_unprepare(), which calls innolux_panel_unprepare()
      
      However, mtk_dsi needs to be in cmd mode to be able to send commands
      (e.g. mipi_dsi_dcs_set_display_off() and mipi_dsi_dcs_enter_sleep_mode()),
      so we need these functions to be called after the switch to cmd mode happens,
      i.e. in innolux_panel_unprepare.
      Signed-off-by: NHsin-Yi, Wang <hsinyi@chromium.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190109065922.231753-1-hsinyi@chromium.orgSigned-off-by: NSasha Levin <sashal@kernel.org>
      862adb5b
    • C
      lkdtm: Add tests for NULL pointer dereference · 2be8987a
      Christophe Leroy 提交于
      [ Upstream commit 59a12205d3c32aee4c13ca36889fdf7cfed31126 ]
      
      Introduce lkdtm tests for NULL pointer dereference: check access or exec
      at NULL address, since these errors tend to be reported differently from
      the general fault error text. For example from x86:
      
          pr_alert("BUG: unable to handle kernel %s at %px\n",
              address < PAGE_SIZE ? "NULL pointer dereference" : "paging request",
              (void *)address);
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2be8987a
    • C
      lkdtm: Print real addresses · 55588aeb
      Christophe Leroy 提交于
      [ Upstream commit 4c411157a42f122051ae3469bee0b5cabe89e139 ]
      
      Today, when doing a lkdtm test before the readiness of the
      random generator, (ptrval) is printed instead of the address
      at which it perform the fault:
      
      [ 1597.337030] lkdtm: Performing direct entry EXEC_USERSPACE
      [ 1597.337142] lkdtm: attempting ok execution at (ptrval)
      [ 1597.337398] lkdtm: attempting bad execution at (ptrval)
      [ 1597.337460] kernel tried to execute user page (77858000) -exploit attempt? (uid: 0)
      [ 1597.344769] Unable to handle kernel paging request for instruction fetch
      [ 1597.351392] Faulting instruction address: 0x77858000
      [ 1597.356312] Oops: Kernel access of bad area, sig: 11 [#1]
      
      If the lkdtm test is done later on, it prints an hashed address.
      
      In both cases this is pointless. The purpose of the test is to
      ensure the kernel generates an Oops at the expected address,
      so real addresses needs to be printed. This patch fixes that.
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      55588aeb
    • D
      soc/tegra: pmc: Drop locking from tegra_powergate_is_powered() · 8387c145
      Dmitry Osipenko 提交于
      [ Upstream commit b6e1fd17a38bd1d97c11d69fd3207b3ef9bfa4b3 ]
      
      This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
      and machine (Tegra30) booted with SMP=n or all secondary CPU's are put
      offline. Locking isn't needed because it protects atomic operation.
      
      BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254
      in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G         C        4.18.0-next-20180821-00180-gc3ebb6544e44-dirty #823
      Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
      [<c01134f4>] (unwind_backtrace) from [<c010db2c>] (show_stack+0x20/0x24)
      [<c010db2c>] (show_stack) from [<c0bd0f3c>] (dump_stack+0x94/0xa8)
      [<c0bd0f3c>] (dump_stack) from [<c0151df8>] (___might_sleep+0x13c/0x174)
      [<c0151df8>] (___might_sleep) from [<c0151ea0>] (__might_sleep+0x70/0xa8)
      [<c0151ea0>] (__might_sleep) from [<c0bec2b8>] (mutex_lock+0x2c/0x70)
      [<c0bec2b8>] (mutex_lock) from [<c0589844>] (tegra_powergate_is_powered+0x44/0xa8)
      [<c0589844>] (tegra_powergate_is_powered) from [<c0581a60>] (tegra30_cpu_rail_off_ready+0x30/0x74)
      [<c0581a60>] (tegra30_cpu_rail_off_ready) from [<c0122244>] (tegra30_idle_lp2+0xa0/0x108)
      [<c0122244>] (tegra30_idle_lp2) from [<c0853438>] (cpuidle_enter_state+0x140/0x540)
      [<c0853438>] (cpuidle_enter_state) from [<c08538a4>] (cpuidle_enter+0x40/0x4c)
      [<c08538a4>] (cpuidle_enter) from [<c01595e0>] (call_cpuidle+0x30/0x48)
      [<c01595e0>] (call_cpuidle) from [<c01599f8>] (do_idle+0x238/0x28c)
      [<c01599f8>] (do_idle) from [<c0159d28>] (cpu_startup_entry+0x28/0x2c)
      [<c0159d28>] (cpu_startup_entry) from [<c0be76c8>] (rest_init+0xd8/0xdc)
      [<c0be76c8>] (rest_init) from [<c1200f50>] (start_kernel+0x41c/0x430)
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Acked-by: NJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8387c145
    • B
      scsi: core: Avoid that system resume triggers a kernel warning · 29b934dd
      Bart Van Assche 提交于
      [ Upstream commit 388b4e6a00bb3097278ed1648ac5a1cb48c894e6 ]
      
      scsi_device_quiesce() and scsi_device_resume() are called during
      system-wide suspend and resume. scsi_device_quiesce() only succeeds for
      SCSI devices that are in one of the RUNNING, OFFLINE or TRANSPORT_OFFLINE
      states (see also scsi_set_device_state()).  This patch avoids that the
      following warning is triggered when resuming a system for which quiescing a
      SCSI device failed:
      
      WARNING: CPU: 2 PID: 11303 at drivers/scsi/scsi_lib.c:2600 scsi_device_resume+0x4f/0x58
      CPU: 2 PID: 11303 Comm: kworker/u8:70 Not tainted 5.0.0-rc1+ #50
      Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13) 08/04/2016
      Workqueue: events_unbound async_run_entry_fn
      Call Trace:
       scsi_dev_type_resume+0x2e/0x60
       async_run_entry_fn+0x32/0xd8
       process_one_work+0x1f4/0x420
       worker_thread+0x28/0x3c0
       kthread+0x118/0x130
       ret_from_fork+0x22/0x40
      
      Cc: Przemek Socha <soprwa@gmail.com>
      Reported-by: NPrzemek Socha <soprwa@gmail.com>
      Fixes: 3a0a5299 ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      29b934dd
    • J
      iommu/dmar: Fix buffer overflow during PCI bus notification · 38855a84
      Julia Cartwright 提交于
      [ Upstream commit cffaaf0c816238c45cd2d06913476c83eb50f682 ]
      
      Commit 57384592 ("iommu/vt-d: Store bus information in RMRR PCI
      device path") changed the type of the path data, however, the change in
      path type was not reflected in size calculations.  Update to use the
      correct type and prevent a buffer overflow.
      
      This bug manifests in systems with deep PCI hierarchies, and can lead to
      an overflow of the static allocated buffer (dmar_pci_notify_info_buf),
      or can lead to overflow of slab-allocated data.
      
         BUG: KASAN: global-out-of-bounds in dmar_alloc_pci_notify_info+0x1d5/0x2e0
         Write of size 1 at addr ffffffff90445d80 by task swapper/0/1
         CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.14.87-rt49-02406-gd0a0e96 #1
         Call Trace:
          ? dump_stack+0x46/0x59
          ? print_address_description+0x1df/0x290
          ? dmar_alloc_pci_notify_info+0x1d5/0x2e0
          ? kasan_report+0x256/0x340
          ? dmar_alloc_pci_notify_info+0x1d5/0x2e0
          ? e820__memblock_setup+0xb0/0xb0
          ? dmar_dev_scope_init+0x424/0x48f
          ? __down_write_common+0x1ec/0x230
          ? dmar_dev_scope_init+0x48f/0x48f
          ? dmar_free_unused_resources+0x109/0x109
          ? cpumask_next+0x16/0x20
          ? __kmem_cache_create+0x392/0x430
          ? kmem_cache_create+0x135/0x2f0
          ? e820__memblock_setup+0xb0/0xb0
          ? intel_iommu_init+0x170/0x1848
          ? _raw_spin_unlock_irqrestore+0x32/0x60
          ? migrate_enable+0x27a/0x5b0
          ? sched_setattr+0x20/0x20
          ? migrate_disable+0x1fc/0x380
          ? task_rq_lock+0x170/0x170
          ? try_to_run_init_process+0x40/0x40
          ? locks_remove_file+0x85/0x2f0
          ? dev_prepare_static_identity_mapping+0x78/0x78
          ? rt_spin_unlock+0x39/0x50
          ? lockref_put_or_lock+0x2a/0x40
          ? dput+0x128/0x2f0
          ? __rcu_read_unlock+0x66/0x80
          ? __fput+0x250/0x300
          ? __rcu_read_lock+0x1b/0x30
          ? mntput_no_expire+0x38/0x290
          ? e820__memblock_setup+0xb0/0xb0
          ? pci_iommu_init+0x25/0x63
          ? pci_iommu_init+0x25/0x63
          ? do_one_initcall+0x7e/0x1c0
          ? initcall_blacklisted+0x120/0x120
          ? kernel_init_freeable+0x27b/0x307
          ? rest_init+0xd0/0xd0
          ? kernel_init+0xf/0x120
          ? rest_init+0xd0/0xd0
          ? ret_from_fork+0x1f/0x40
         The buggy address belongs to the variable:
          dmar_pci_notify_info_buf+0x40/0x60
      
      Fixes: 57384592 ("iommu/vt-d: Store bus information in RMRR PCI device path")
      Signed-off-by: NJulia Cartwright <julia@ni.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      38855a84
    • L
      net: ip6_gre: fix possible NULL pointer dereference in ip6erspan_set_version · 8c5e9ea1
      Lorenzo Bianconi 提交于
      [ Upstream commit efcc9bcaf77c07df01371a7c34e50424c291f3ac ]
      
      Fix a possible NULL pointer dereference in ip6erspan_set_version checking
      nlattr data pointer
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 7549 Comm: syz-executor432 Not tainted 5.0.0-rc6-next-20190218
      #37
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:ip6erspan_set_version+0x5c/0x350 net/ipv6/ip6_gre.c:1726
      Code: 07 38 d0 7f 08 84 c0 0f 85 9f 02 00 00 49 8d bc 24 b0 00 00 00 c6 43
      54 01 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
      85 9a 02 00 00 4d 8b ac 24 b0 00 00 00 4d 85 ed 0f
      RSP: 0018:ffff888089ed7168 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff8880869d6e58 RCX: 0000000000000000
      RDX: 0000000000000016 RSI: ffffffff862736b4 RDI: 00000000000000b0
      RBP: ffff888089ed7180 R08: 1ffff11010d3adcb R09: ffff8880869d6e58
      R10: ffffed1010d3add5 R11: ffff8880869d6eaf R12: 0000000000000000
      R13: ffffffff8931f8c0 R14: ffffffff862825d0 R15: ffff8880869d6e58
      FS:  0000000000b3d880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020000184 CR3: 0000000092cc5000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        ip6erspan_newlink+0x66/0x7b0 net/ipv6/ip6_gre.c:2210
        __rtnl_newlink+0x107b/0x16c0 net/core/rtnetlink.c:3176
        rtnl_newlink+0x69/0xa0 net/core/rtnetlink.c:3234
        rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192
        netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485
        rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210
        netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
        netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
        netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925
        sock_sendmsg_nosec net/socket.c:621 [inline]
        sock_sendmsg+0xdd/0x130 net/socket.c:631
        ___sys_sendmsg+0x806/0x930 net/socket.c:2136
        __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
        __do_sys_sendmsg net/socket.c:2183 [inline]
        __se_sys_sendmsg net/socket.c:2181 [inline]
        __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
        do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x440159
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
      48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
      ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fffa69156e8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440159
      RDX: 0000000000000000 RSI: 0000000020001340 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 0000000000000001 R09: 00000000004002c8
      R10: 0000000000000011 R11: 0000000000000246 R12: 00000000004019e0
      R13: 0000000000401a70 R14: 0000000000000000 R15: 0000000000000000
      Modules linked in:
      ---[ end trace 09f8a7d13b4faaa1 ]---
      RIP: 0010:ip6erspan_set_version+0x5c/0x350 net/ipv6/ip6_gre.c:1726
      Code: 07 38 d0 7f 08 84 c0 0f 85 9f 02 00 00 49 8d bc 24 b0 00 00 00 c6 43
      54 01 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
      85 9a 02 00 00 4d 8b ac 24 b0 00 00 00 4d 85 ed 0f
      RSP: 0018:ffff888089ed7168 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff8880869d6e58 RCX: 0000000000000000
      RDX: 0000000000000016 RSI: ffffffff862736b4 RDI: 00000000000000b0
      RBP: ffff888089ed7180 R08: 1ffff11010d3adcb R09: ffff8880869d6e58
      R10: ffffed1010d3add5 R11: ffff8880869d6eaf R12: 0000000000000000
      R13: ffffffff8931f8c0 R14: ffffffff862825d0 R15: ffff8880869d6e58
      FS:  0000000000b3d880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020000184 CR3: 0000000092cc5000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      
      Fixes: 4974d5f678ab ("net: ip6_gre: initialize erspan_ver just for erspan tunnels")
      Reported-and-tested-by: syzbot+30191cf1057abd3064af@syzkaller.appspotmail.com
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Reviewed-by: NGreg Rose <gvrose8192@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8c5e9ea1
    • A
      crypto: sha512/arm - fix crash bug in Thumb2 build · d7a90ee5
      Ard Biesheuvel 提交于
      [ Upstream commit c64316502008064c158fa40cc250665e461b0f2a ]
      
      The SHA512 code we adopted from the OpenSSL project uses a rather
      peculiar way to take the address of the round constant table: it
      takes the address of the sha256_block_data_order() routine, and
      substracts a constant known quantity to arrive at the base of the
      table, which is emitted by the same assembler code right before
      the routine's entry point.
      
      However, recent versions of binutils have helpfully changed the
      behavior of references emitted via an ADR instruction when running
      in Thumb2 mode: it now takes the Thumb execution mode bit into
      account, which is bit 0 af the address. This means the produced
      table address also has bit 0 set, and so we end up with an address
      value pointing 1 byte past the start of the table, which results
      in crashes such as
      
        Unable to handle kernel paging request at virtual address bf825000
        pgd = 42f44b11
        [bf825000] *pgd=80000040206003, *pmd=5f1bd003, *pte=00000000
        Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
        Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
        CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
        Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
        PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
        LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
        pc : [<bf820bca>]    lr : [<bf824ffd>]    psr: 800b0033
        sp : ebc8bbe8  ip : faaabe1c  fp : 2fdd3433
        r10: 4c5f1692  r9 : e43037df  r8 : b04b0a5a
        r7 : c369d722  r6 : 39c3693e  r5 : 7a013189  r4 : 1580d26b
        r3 : 8762a9b0  r2 : eea9c2cd  r1 : 3e9ab536  r0 : 1dea4ae7
        Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment user
        Control: 70c5383d  Table: 6b8467c0  DAC: dbadc0de
        Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
        Stack: (0xebc8bbe8 to 0xebc8c000)
        ...
        unwind: Unknown symbol address bf820bca
        unwind: Index not found bf820bca
        Code: 441a ea80 40f9 440a (f85e) 3b04
        ---[ end trace e560cce92700ef8a ]---
      
      Given that this affects older kernels as well, in case they are built
      with a recent toolchain, apply a minimal backportable fix, which is
      to emit another non-code label at the start of the routine, and
      reference that instead. (This is similar to the current upstream state
      of this file in OpenSSL)
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d7a90ee5
    • A
      crypto: sha256/arm - fix crash bug in Thumb2 build · 1f52fa12
      Ard Biesheuvel 提交于
      [ Upstream commit 69216a545cf81b2b32d01948f7039315abaf75a0 ]
      
      The SHA256 code we adopted from the OpenSSL project uses a rather
      peculiar way to take the address of the round constant table: it
      takes the address of the sha256_block_data_order() routine, and
      substracts a constant known quantity to arrive at the base of the
      table, which is emitted by the same assembler code right before
      the routine's entry point.
      
      However, recent versions of binutils have helpfully changed the
      behavior of references emitted via an ADR instruction when running
      in Thumb2 mode: it now takes the Thumb execution mode bit into
      account, which is bit 0 af the address. This means the produced
      table address also has bit 0 set, and so we end up with an address
      value pointing 1 byte past the start of the table, which results
      in crashes such as
      
        Unable to handle kernel paging request at virtual address bf825000
        pgd = 42f44b11
        [bf825000] *pgd=80000040206003, *pmd=5f1bd003, *pte=00000000
        Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
        Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
        CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
        Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
        PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
        LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
        pc : [<bf820bca>]    lr : [<bf824ffd>]    psr: 800b0033
        sp : ebc8bbe8  ip : faaabe1c  fp : 2fdd3433
        r10: 4c5f1692  r9 : e43037df  r8 : b04b0a5a
        r7 : c369d722  r6 : 39c3693e  r5 : 7a013189  r4 : 1580d26b
        r3 : 8762a9b0  r2 : eea9c2cd  r1 : 3e9ab536  r0 : 1dea4ae7
        Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment user
        Control: 70c5383d  Table: 6b8467c0  DAC: dbadc0de
        Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
        Stack: (0xebc8bbe8 to 0xebc8c000)
        ...
        unwind: Unknown symbol address bf820bca
        unwind: Index not found bf820bca
        Code: 441a ea80 40f9 440a (f85e) 3b04
        ---[ end trace e560cce92700ef8a ]---
      
      Given that this affects older kernels as well, in case they are built
      with a recent toolchain, apply a minimal backportable fix, which is
      to emit another non-code label at the start of the routine, and
      reference that instead. (This is similar to the current upstream state
      of this file in OpenSSL)
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1f52fa12
    • C
      xfrm: destroy xfrm_state synchronously on net exit path · bbbe4746
      Cong Wang 提交于
      [ Upstream commit f75a2804da391571563c4b6b29e7797787332673 ]
      
      xfrm_state_put() moves struct xfrm_state to the GC list
      and schedules the GC work to clean it up. On net exit call
      path, xfrm_state_flush() is called to clean up and
      xfrm_flush_gc() is called to wait for the GC work to complete
      before exit.
      
      However, this doesn't work because one of the ->destructor(),
      ipcomp_destroy(), schedules the same GC work again inside
      the GC work. It is hard to wait for such a nested async
      callback. This is also why syzbot still reports the following
      warning:
      
       WARNING: CPU: 1 PID: 33 at net/ipv6/xfrm6_tunnel.c:351 xfrm6_tunnel_net_exit+0x2cb/0x500 net/ipv6/xfrm6_tunnel.c:351
       ...
        ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
        cleanup_net+0x51d/0xb10 net/core/net_namespace.c:551
        process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
        worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
        kthread+0x357/0x430 kernel/kthread.c:246
        ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      
      In fact, it is perfectly fine to bypass GC and destroy xfrm_state
      synchronously on net exit call path, because it is in process context
      and doesn't need a work struct to do any blocking work.
      
      This patch introduces xfrm_state_put_sync() which simply bypasses
      GC, and lets its callers to decide whether to use this synchronous
      version. On net exit path, xfrm_state_fini() and
      xfrm6_tunnel_net_exit() use it. And, as ipcomp_destroy() itself is
      blocking, it can use xfrm_state_put_sync() directly too.
      
      Also rename xfrm_state_gc_destroy() to ___xfrm_state_destroy() to
      reflect this change.
      
      Fixes: b48c05ab ("xfrm: Fix warning in xfrm6_tunnel_net_exit.")
      Reported-and-tested-by: syzbot+e9aebef558e3ed673934@syzkaller.appspotmail.com
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bbbe4746
    • S
      net/rds: fix warn in rds_message_alloc_sgs · 5be4bb31
      shamir rabinovitch 提交于
      [ Upstream commit ea010070d0a7497253d5a6f919f6dd107450b31a ]
      
      redundant copy_from_user in rds_sendmsg system call expose rds
      to issue where rds_rdma_extra_size walk the rds iovec and and
      calculate the number pf pages (sgs) it need to add to the tail of
      rds message and later rds_cmsg_rdma_args copy the rds iovec again
      and re calculate the same number and get different result causing
      WARN_ON in rds_message_alloc_sgs.
      
      fix this by doing the copy_from_user only once per rds_sendmsg
      system call.
      
      When issue occur the below dump is seen:
      
      WARNING: CPU: 0 PID: 19789 at net/rds/message.c:316 rds_message_alloc_sgs+0x10c/0x160 net/rds/message.c:316
      Kernel panic - not syncing: panic_on_warn set ...
      CPU: 0 PID: 19789 Comm: syz-executor827 Not tainted 4.19.0-next-20181030+ #101
      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+0x244/0x39d lib/dump_stack.c:113
       panic+0x2ad/0x55c kernel/panic.c:188
       __warn.cold.8+0x20/0x45 kernel/panic.c:540
       report_bug+0x254/0x2d0 lib/bug.c:186
       fixup_bug arch/x86/kernel/traps.c:178 [inline]
       do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
       do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
       invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
      RIP: 0010:rds_message_alloc_sgs+0x10c/0x160 net/rds/message.c:316
      Code: c0 74 04 3c 03 7e 6c 44 01 ab 78 01 00 00 e8 2b 9e 35 fa 4c 89 e0 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 14 9e 35 fa <0f> 0b 31 ff 44 89 ee e8 18 9f 35 fa 45 85 ed 75 1b e8 fe 9d 35 fa
      RSP: 0018:ffff8801c51b7460 EFLAGS: 00010293
      RAX: ffff8801bc412080 RBX: ffff8801d7bf4040 RCX: ffffffff8749c9e6
      RDX: 0000000000000000 RSI: ffffffff8749ca5c RDI: 0000000000000004
      RBP: ffff8801c51b7490 R08: ffff8801bc412080 R09: ffffed003b5c5b67
      R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
      R13: 000000000007165c R14: 000000000007165c R15: 0000000000000005
       rds_cmsg_rdma_args+0x82d/0x1510 net/rds/rdma.c:623
       rds_cmsg_send net/rds/send.c:971 [inline]
       rds_sendmsg+0x19a2/0x3180 net/rds/send.c:1273
       sock_sendmsg_nosec net/socket.c:622 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:632
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2117
       __sys_sendmsg+0x11d/0x280 net/socket.c:2155
       __do_sys_sendmsg net/socket.c:2164 [inline]
       __se_sys_sendmsg net/socket.c:2162 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x44a859
      Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 6b cb fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f1d4710ada8 EFLAGS: 00000297 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00000000006dcc28 RCX: 000000000044a859
      RDX: 0000000000000000 RSI: 0000000020001600 RDI: 0000000000000003
      RBP: 00000000006dcc20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000297 R12: 00000000006dcc2c
      R13: 646e732f7665642f R14: 00007f1d4710b9c0 R15: 00000000006dcd2c
      Kernel Offset: disabled
      Rebooting in 86400 seconds..
      
      Reported-by: syzbot+26de17458aeda9d305d8@syzkaller.appspotmail.com
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: Nshamir rabinovitch <shamir.rabinovitch@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5be4bb31
    • R
      ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idle · d801282d
      Rafael J. Wysocki 提交于
      [ Upstream commit f941d3e41da7f86bdb9dcc1977c2bcc6b89bfe47 ]
      
      There are systems in which non-wakeup GPEs fire during the "noirq"
      suspend stage of suspending devices and that effectively prevents the
      system that tries to suspend to idle from entering any low-power
      state at all.  If the offending GPE fires regularly and often enough,
      the system appears to be suspended, but in fact it is in a tight loop
      over "noirq" suspend and "noirq" resume of devices all the time.
      
      To prevent that from happening, disable all non-wakeup GPEs except
      for the EC GPE for suspend-to-idle (the EC GPE is special, because
      on some systems it has to be enabled for power button wakeup events
      to be generated as expected).
      
      Fixes: 147a7d9d (ACPI / PM: Do not reconfigure GPEs for suspend-to-idle)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201987Reported-by: NZhang Rui <rui.zhang@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d801282d
    • A
      ALSA: hda: fix front speakers on Huawei MBXP · e434fbf4
      Ayman Bagabas 提交于
      [ Upstream commit 8ac51bbc4cfec4ef08b03bef24b31e2d50ef8b37 ]
      
      This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
      It enables the front speakers on Huawei Matebook X Pro laptops.
      These laptops come with Dolby Atmos sound system and these pins
      configuration enables the front speakers.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200501Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NAyman Bagabas <ayman.bagabas@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e434fbf4
    • T
      drm/ttm: Fix bo_global and mem_global kfree error · b10cc083
      Trigger Huang 提交于
      [ Upstream commit 30f33126feca0fe16df9e9302ffc28a953e2eb37 ]
      
      ttm_bo_glob and ttm_mem_glob are defined as structure instance, while
      not allocated by kzalloc, so kfree should not be invoked to release
      them anymore. Otherwise, it will cause the following kernel BUG when
      unloading amdgpu module
      
      [   48.419294] kernel BUG at /build/linux-5s7Xkn/linux-4.15.0/mm/slub.c:3894!
      [   48.419352] invalid opcode: 0000 [#1] SMP PTI
      [   48.419387] Modules linked in: amdgpu(OE-) amdchash(OE) amdttm(OE) amd_sched(OE) amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi pcbc snd_seq snd_seq_device snd_timer aesni_intel snd soundcore joydev aes_x86_64 crypto_simd glue_helper cryptd input_leds mac_hid serio_raw binfmt_misc nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 8139too psmouse i2c_piix4 8139cp mii floppy pata_acpi
      [   48.419782] CPU: 1 PID: 1281 Comm: modprobe Tainted: G           OE    4.15.0-20-generic #21-Ubuntu
      [   48.419838] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [   48.419901] RIP: 0010:kfree+0x137/0x180
      [   48.419934] RSP: 0018:ffffb02101273bf8 EFLAGS: 00010246
      [   48.419974] RAX: ffffeee1418ad7e0 RBX: ffffffffc075f100 RCX: ffff8fed7fca7ed0
      [   48.420025] RDX: 0000000000000000 RSI: 000000000003440e RDI: 0000000022400000
      [   48.420073] RBP: ffffb02101273c10 R08: 0000000000000010 R09: ffff8fed7ffd3680
      [   48.420121] R10: ffffeee1418ad7c0 R11: ffff8fed7ffd3000 R12: ffffffffc075e2c0
      [   48.420169] R13: ffffffffc074ec10 R14: ffff8fed73063900 R15: ffff8fed737428e8
      [   48.420216] FS:  00007fdc912ec540(0000) GS:ffff8fed7fc80000(0000) knlGS:0000000000000000
      [   48.420267] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   48.420308] CR2: 000055fa40c30060 CR3: 000000023470a006 CR4: 00000000003606e0
      [   48.420358] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   48.420405] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   48.420452] Call Trace:
      [   48.420485]  ttm_bo_global_kobj_release+0x20/0x30 [amdttm]
      [   48.420528]  kobject_release+0x6a/0x180
      [   48.420562]  kobject_put+0x28/0x50
      [   48.420595]  ttm_bo_global_release+0x36/0x50 [amdttm]
      [   48.420636]  amdttm_bo_device_release+0x119/0x180 [amdttm]
      [   48.420678]  ? amdttm_bo_clean_mm+0xa6/0xf0 [amdttm]
      [   48.420760]  amdgpu_ttm_fini+0xc9/0x180 [amdgpu]
      [   48.420821]  amdgpu_bo_fini+0x12/0x40 [amdgpu]
      [   48.420889]  gmc_v9_0_sw_fini+0x40/0x50 [amdgpu]
      [   48.420947]  amdgpu_device_fini+0x36f/0x4c0 [amdgpu]
      [   48.421007]  amdgpu_driver_unload_kms+0xb4/0x150 [amdgpu]
      [   48.421058]  drm_dev_unregister+0x46/0xf0 [drm]
      [   48.421102]  drm_dev_unplug+0x12/0x70 [drm]
      Signed-off-by: NTrigger Huang <Trigger.Huang@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b10cc083
    • H
      platform/x86: Add Intel AtomISP2 dummy / power-management driver · cb09e99b
      Hans de Goede 提交于
      [ Upstream commit 49ad712afa88c502831d37f7089d98eac441fb80 ]
      
      The Image Signal Processor found on Cherry Trail devices is brought up in
      D0 state on devices which have camera sensors attached to it. The ISP will
      not enter D3 state again without some massaging of its registers beforehand
      and the ISP not being in D3 state blocks the SoC from entering S0ix modes.
      
      There was a driver for the ISP in drivers/staging but that got removed
      again because it never worked. It does not seem likely that a real
      driver for the ISP will be added to the mainline kernel anytime soon.
      
      This commit adds a dummy driver which contains the necessary magic from
      the staging driver to powerdown the ISP, so that Cherry Trail devices where
      the ISP is used will properly use S0ix modes when suspended.
      
      Together with other recent S0ix related fixes this allows S0ix modes to
      be entered on e.g. a Chuwi Hi8 Pro and a HP x2 210.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196915Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cb09e99b
    • V
      kernel: hung_task.c: disable on suspend · 491dee74
      Vitaly Kuznetsov 提交于
      [ Upstream commit a1c6ca3c6de763459a6e93b644ec6518c890ba1c ]
      
      It is possible to observe hung_task complaints when system goes to
      suspend-to-idle state:
      
       # echo freeze > /sys/power/state
      
       PM: Syncing filesystems ... done.
       Freezing user space processes ... (elapsed 0.001 seconds) done.
       OOM killer disabled.
       Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
       sd 0:0:0:0: [sda] Synchronizing SCSI cache
       INFO: task bash:1569 blocked for more than 120 seconds.
             Not tainted 4.19.0-rc3_+ #687
       "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
       bash            D    0  1569    604 0x00000000
       Call Trace:
        ? __schedule+0x1fe/0x7e0
        schedule+0x28/0x80
        suspend_devices_and_enter+0x4ac/0x750
        pm_suspend+0x2c0/0x310
      
      Register a PM notifier to disable the detector on suspend and re-enable
      back on wakeup.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      491dee74
    • S
      cifs: fallback to older infolevels on findfirst queryinfo retry · e9603cff
      Steve French 提交于
      [ Upstream commit 3b7960caceafdfc2cdfe2850487f8d091eb41144 ]
      
      In cases where queryinfo fails, we have cases in cifs (vers=1.0)
      where with backupuid mounts we retry the query info with findfirst.
      This doesn't work to some NetApp servers which don't support
      WindowsXP (and later) infolevel 261 (SMB_FIND_FILE_ID_FULL_DIR_INFO)
      so in this case use other info levels (in this case it will usually
      be level 257, SMB_FIND_FILE_DIRECTORY_INFO).
      
      (Also fixes some indentation)
      
      See kernel bugzilla 201435
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e9603cff
    • T
      net: stmmac: Set OWN bit for jumbo frames · fc34758d
      Thor Thayer 提交于
      [ Upstream commit 487e2e22ab7968f2c0c82f37b5ca5883efd1a354 ]
      
      Ping with Jumbo packet does not reply and get a watchdog timeout
      
      [   46.059616] ------------[ cut here ]------------
      [   46.064268] NETDEV WATCHDOG: eth0 (socfpga-dwmac): transmit queue 0 timed out
      [   46.071471] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x2cc/0x2d8
      [   46.079708] Modules linked in:
      [   46.082761] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.18.0-00115-gc262be665854-dirty #264
      [   46.091082] Hardware name: SoCFPGA Stratix 10 SoCDK (DT)
      [   46.096377] pstate: 20000005 (nzCv daif -PAN -UAO)
      [   46.101152] pc : dev_watchdog+0x2cc/0x2d8
      [   46.105149] lr : dev_watchdog+0x2cc/0x2d8
      [   46.109144] sp : ffff00000800bd80
      [   46.112447] x29: ffff00000800bd80 x28: ffff80007a9b4940
      [   46.117744] x27: 00000000ffffffff x26: ffff80007aa183b0
      [   46.123040] x25: 0000000000000001 x24: 0000000000000140
      [   46.128336] x23: ffff80007aa1839c x22: ffff80007aa17fb0
      [   46.133632] x21: ffff80007aa18000 x20: ffff0000091a7000
      [   46.138927] x19: 0000000000000000 x18: ffffffffffffffff
      [   46.144223] x17: 0000000000000000 x16: 0000000000000000
      [   46.149519] x15: ffff0000091a96c8 x14: 07740775076f0720
      [   46.154814] x13: 07640765076d0769 x12: 0774072007300720
      [   46.160110] x11: 0765077507650775 x10: 0771072007740769
      [   46.165406] x9 : 076d0773076e0761 x8 : 077207740720073a
      [   46.170702] x7 : 072907630761076d x6 : ffff80007ff9a0c0
      [   46.175997] x5 : ffff80007ff9a0c0 x4 : 0000000000000002
      [   46.181293] x3 : 0000000000000000 x2 : ffff0000091ac180
      [   46.186589] x1 : e6a742ebe628e800 x0 : 0000000000000000
      [   46.191885] Call trace:
      [   46.194326]  dev_watchdog+0x2cc/0x2d8
      [   46.197980]  call_timer_fn+0x20/0x78
      [   46.201544]  expire_timers+0xa4/0xb0
      [   46.205108]  run_timer_softirq+0xe4/0x198
      [   46.209107]  __do_softirq+0x114/0x210
      [   46.212760]  irq_exit+0xd0/0xd8
      [   46.215895]  __handle_domain_irq+0x60/0xb0
      [   46.219977]  gic_handle_irq+0x58/0xa8
      [   46.223628]  el1_irq+0xb0/0x128
      [   46.226761]  arch_cpu_idle+0x10/0x18
      [   46.230326]  do_idle+0x1d4/0x288
      [   46.233544]  cpu_startup_entry+0x24/0x28
      [   46.237457]  secondary_start_kernel+0x17c/0x1c0
      [   46.241971] ---[ end trace 57048cd1372cd828 ]---
      
      Inspection of queue showed Jumbo packets were not sent out.
      The ring Jumbo packet function needs to set the OWN bit so
      the packet is sent.
      Signed-off-by: NThor Thayer <thor.thayer@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fc34758d
    • S
      f2fs: cleanup dirty pages if recover failed · 8722566b
      Sheng Yong 提交于
      [ Upstream commit 26b5a079197c8cb6725565968b7fd3299bd1877b ]
      
      During recover, we will try to create new dentries for inodes with
      dentry_mark. But if the parent is missing (e.g. killed by fsck),
      recover will break. But those recovered dirty pages are not cleanup.
      This will hit f2fs_bug_on:
      
      [   53.519566] F2FS-fs (loop0): Found nat_bits in checkpoint
      [   53.539354] F2FS-fs (loop0): recover_inode: ino = 5, name = file, inline = 3
      [   53.539402] F2FS-fs (loop0): recover_dentry: ino = 5, name = file, dir = 0, err = -2
      [   53.545760] F2FS-fs (loop0): Cannot recover all fsync data errno=-2
      [   53.546105] F2FS-fs (loop0): access invalid blkaddr:4294967295
      [   53.546171] WARNING: CPU: 1 PID: 1798 at fs/f2fs/checkpoint.c:163 f2fs_is_valid_blkaddr+0x26c/0x320
      [   53.546174] Modules linked in:
      [   53.546183] CPU: 1 PID: 1798 Comm: mount Not tainted 4.19.0-rc2+ #1
      [   53.546186] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   53.546191] RIP: 0010:f2fs_is_valid_blkaddr+0x26c/0x320
      [   53.546195] Code: 85 bb 00 00 00 48 89 df 88 44 24 07 e8 ad a8 db ff 48 8b 3b 44 89 e1 48 c7 c2 40 03 72 a9 48 c7 c6 e0 01 72 a9 e8 84 3c ff ff <0f> 0b 0f b6 44 24 07 e9 8a 00 00 00 48 8d bf 38 01 00 00 e8 7c a8
      [   53.546201] RSP: 0018:ffff88006c067768 EFLAGS: 00010282
      [   53.546208] RAX: 0000000000000000 RBX: ffff880068844200 RCX: ffffffffa83e1a33
      [   53.546211] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88006d51e590
      [   53.546215] RBP: 0000000000000005 R08: ffffed000daa3cb3 R09: ffffed000daa3cb3
      [   53.546218] R10: 0000000000000001 R11: ffffed000daa3cb2 R12: 00000000ffffffff
      [   53.546221] R13: ffff88006a1f8000 R14: 0000000000000200 R15: 0000000000000009
      [   53.546226] FS:  00007fb2f3646840(0000) GS:ffff88006d500000(0000) knlGS:0000000000000000
      [   53.546229] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   53.546234] CR2: 00007f0fd77f0008 CR3: 00000000687e6002 CR4: 00000000000206e0
      [   53.546237] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   53.546240] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   53.546242] Call Trace:
      [   53.546248]  f2fs_submit_page_bio+0x95/0x740
      [   53.546253]  read_node_page+0x161/0x1e0
      [   53.546271]  ? truncate_node+0x650/0x650
      [   53.546283]  ? add_to_page_cache_lru+0x12c/0x170
      [   53.546288]  ? pagecache_get_page+0x262/0x2d0
      [   53.546292]  __get_node_page+0x200/0x660
      [   53.546302]  f2fs_update_inode_page+0x4a/0x160
      [   53.546306]  f2fs_write_inode+0x86/0xb0
      [   53.546317]  __writeback_single_inode+0x49c/0x620
      [   53.546322]  writeback_single_inode+0xe4/0x1e0
      [   53.546326]  sync_inode_metadata+0x93/0xd0
      [   53.546330]  ? sync_inode+0x10/0x10
      [   53.546342]  ? do_raw_spin_unlock+0xed/0x100
      [   53.546347]  f2fs_sync_inode_meta+0xe0/0x130
      [   53.546351]  f2fs_fill_super+0x287d/0x2d10
      [   53.546367]  ? vsnprintf+0x742/0x7a0
      [   53.546372]  ? f2fs_commit_super+0x180/0x180
      [   53.546379]  ? up_write+0x20/0x40
      [   53.546385]  ? set_blocksize+0x5f/0x140
      [   53.546391]  ? f2fs_commit_super+0x180/0x180
      [   53.546402]  mount_bdev+0x181/0x200
      [   53.546406]  mount_fs+0x94/0x180
      [   53.546411]  vfs_kern_mount+0x6c/0x1e0
      [   53.546415]  do_mount+0xe5e/0x1510
      [   53.546420]  ? fs_reclaim_release+0x9/0x30
      [   53.546424]  ? copy_mount_string+0x20/0x20
      [   53.546428]  ? fs_reclaim_acquire+0xd/0x30
      [   53.546435]  ? __might_sleep+0x2c/0xc0
      [   53.546440]  ? ___might_sleep+0x53/0x170
      [   53.546453]  ? __might_fault+0x4c/0x60
      [   53.546468]  ? _copy_from_user+0x95/0xa0
      [   53.546474]  ? memdup_user+0x39/0x60
      [   53.546478]  ksys_mount+0x88/0xb0
      [   53.546482]  __x64_sys_mount+0x5d/0x70
      [   53.546495]  do_syscall_64+0x65/0x130
      [   53.546503]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   53.547639] ---[ end trace b804d1ea2fec893e ]---
      
      So if recover fails, we need to drop all recovered data.
      Signed-off-by: NSheng Yong <shengyong1@huawei.com>
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8722566b
    • T
      netfilter: nf_flow_table: remove flowtable hook flush routine in netns exit routine · 263ed7e6
      Taehee Yoo 提交于
      [ Upstream commit b7f1a16d29b2e28d3dcbb070511bd703e306281b ]
      
      When device is unregistered, flowtable flush routine is called
      by notifier_call(nf_tables_flowtable_event). and exit callback of
      nftables pernet_operation(nf_tables_exit_net) also has flowtable flush
      routine. but when network namespace is destroyed, both notifier_call
      and pernet_operation are called. hence flowtable flush routine in
      pernet_operation is unnecessary.
      
      test commands:
         %ip netns add vm1
         %ip netns exec vm1 nft add table ip filter
         %ip netns exec vm1 nft add flowtable ip filter w \
      	{ hook ingress priority 0\; devices = { lo }\; }
         %ip netns del vm1
      
      splat looks like:
      [  265.187019] WARNING: CPU: 0 PID: 87 at net/netfilter/core.c:309 nf_hook_entry_head+0xc7/0xf0
      [  265.187112] Modules linked in: nf_flow_table_ipv4 nf_flow_table nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink ip_tables x_tables
      [  265.187390] CPU: 0 PID: 87 Comm: kworker/u4:2 Not tainted 4.19.0-rc3+ #5
      [  265.187453] Workqueue: netns cleanup_net
      [  265.187514] RIP: 0010:nf_hook_entry_head+0xc7/0xf0
      [  265.187546] Code: 8d 81 68 03 00 00 5b c3 89 d0 83 fa 04 48 8d 84 c7 e8 11 00 00 76 81 0f 0b 31 c0 e9 78 ff ff ff 0f 0b 48 83 c4 08 31 c0 5b c3 <0f> 0b 31 c0 e9 65 ff ff ff 0f 0b 31 c0 e9 5c ff ff ff 48 89 0c 24
      [  265.187573] RSP: 0018:ffff88011546f098 EFLAGS: 00010246
      [  265.187624] RAX: ffffffff8d90e135 RBX: 1ffff10022a8de1c RCX: 0000000000000000
      [  265.187645] RDX: 0000000000000000 RSI: 0000000000000005 RDI: ffff880116298040
      [  265.187645] RBP: ffff88010ea4c1a8 R08: 0000000000000000 R09: 0000000000000000
      [  265.187645] R10: ffff88011546f1d8 R11: ffffed0022c532c1 R12: ffff88010ea4c1d0
      [  265.187645] R13: 0000000000000005 R14: dffffc0000000000 R15: ffff88010ea4c1c4
      [  265.187645] FS:  0000000000000000(0000) GS:ffff88011b200000(0000) knlGS:0000000000000000
      [  265.187645] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  265.187645] CR2: 00007fdfb8d00000 CR3: 0000000057a16000 CR4: 00000000001006f0
      [  265.187645] Call Trace:
      [  265.187645]  __nf_unregister_net_hook+0xca/0x5d0
      [  265.187645]  ? nf_hook_entries_free.part.3+0x80/0x80
      [  265.187645]  ? save_trace+0x300/0x300
      [  265.187645]  nf_unregister_net_hooks+0x2e/0x40
      [  265.187645]  nf_tables_exit_net+0x479/0x1340 [nf_tables]
      [  265.187645]  ? find_held_lock+0x39/0x1c0
      [  265.187645]  ? nf_tables_abort+0x30/0x30 [nf_tables]
      [  265.187645]  ? inet_frag_destroy_rcu+0xd0/0xd0
      [  265.187645]  ? trace_hardirqs_on+0x93/0x210
      [  265.187645]  ? __bpf_trace_preemptirq_template+0x10/0x10
      [  265.187645]  ? inet_frag_destroy_rcu+0xd0/0xd0
      [  265.187645]  ? inet_frag_destroy_rcu+0xd0/0xd0
      [  265.187645]  ? __mutex_unlock_slowpath+0x17f/0x740
      [  265.187645]  ? wait_for_completion+0x710/0x710
      [  265.187645]  ? bucket_table_free+0xb2/0x1f0
      [  265.187645]  ? nested_table_free+0x130/0x130
      [  265.187645]  ? __lock_is_held+0xb4/0x140
      [  265.187645]  ops_exit_list.isra.10+0x94/0x140
      [  265.187645]  cleanup_net+0x45b/0x900
      [ ... ]
      
      This WARNING means that hook unregisteration is failed because
      all flowtables hooks are already unregistered by notifier_call.
      
      Network namespace exit routine guarantees that all devices will be
      unregistered first. then, other exit callbacks of pernet_operations
      are called. so that removing flowtable flush routine in exit callback of
      pernet_operation(nf_tables_exit_net) doesn't make flowtable leak.
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      263ed7e6
    • N
      compiler.h: update definition of unreachable() · 19e6ff01
      ndesaulniers@google.com 提交于
      [ Upstream commit fe0640eb30b7da261ae84d252ed9ed3c7e68dfd8 ]
      
      Fixes the objtool warning seen with Clang:
      arch/x86/mm/fault.o: warning: objtool: no_context()+0x220: unreachable
      instruction
      
      Fixes commit 815f0ddb ("include/linux/compiler*.h: make compiler-*.h
      mutually exclusive")
      
      Josh noted that the fallback definition was meant to work around a
      pre-gcc-4.6 bug. GCC still needs to work around
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365, so compiler-gcc.h
      defines its own version of unreachable().  Clang and ICC can use this
      shared definition.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/204Suggested-by: NAndy Lutomirski <luto@amacapital.net>
      Suggested-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Tested-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      19e6ff01
    • S
      KVM: nVMX: restore host state in nested_vmx_vmexit for VMFail · f35e2a68
      Sean Christopherson 提交于
      [ Upstream commit bd18bffca35397214ae68d85cf7203aca25c3c1d ]
      
      A VMEnter that VMFails (as opposed to VMExits) does not touch host
      state beyond registers that are explicitly noted in the VMFail path,
      e.g. EFLAGS.  Host state does not need to be loaded because VMFail
      is only signaled for consistency checks that occur before the CPU
      starts to load guest state, i.e. there is no need to restore any
      state as nothing has been modified.  But in the case where a VMFail
      is detected by hardware and not by KVM (due to deferring consistency
      checks to hardware), KVM has already loaded some amount of guest
      state.  Luckily, "loaded" only means loaded to KVM's software model,
      i.e. vmcs01 has not been modified.  So, unwind our software model to
      the pre-VMEntry host state.
      
      Not restoring host state in this VMFail path leads to a variety of
      failures because we end up with stale data in vcpu->arch, e.g. CR0,
      CR4, EFER, etc... will all be out of sync relative to vmcs01.  Any
      significant delta in the stale data is all but guaranteed to crash
      L1, e.g. emulation of SMEP, SMAP, UMIP, WP, etc... will be wrong.
      
      An alternative to this "soft" reload would be to load host state from
      vmcs12 as if we triggered a VMExit (as opposed to VMFail), but that is
      wildly inconsistent with respect to the VMX architecture, e.g. an L1
      VMM with separate VMExit and VMFail paths would explode.
      
      Note that this approach does not mean KVM is 100% accurate with
      respect to VMX hardware behavior, even at an architectural level
      (the exact order of consistency checks is microarchitecture specific).
      But 100% emulation accuracy isn't the goal (with this patch), rather
      the goal is to be consistent in the information delivered to L1, e.g.
      a VMExit should not fall-through VMENTER, and a VMFail should not jump
      to HOST_RIP.
      
      This technically reverts commit "5af41573 (KVM: nVMX: Fix mmu
      context after VMLAUNCH/VMRESUME failure)", but retains the core
      aspects of that patch, just in an open coded form due to the need to
      pull state from vmcs01 instead of vmcs12.  Restoring host state
      resolves a variety of issues introduced by commit "4f350c6d
      (kvm: nVMX: Handle deferred early VMLAUNCH/VMRESUME failure properly)",
      which remedied the incorrect behavior of treating VMFail like VMExit
      but in doing so neglected to restore arch state that had been modified
      prior to attempting nested VMEnter.
      
      A sample failure that occurs due to stale vcpu.arch state is a fault
      of some form while emulating an LGDT (due to emulated UMIP) from L1
      after a failed VMEntry to L3, in this case when running the KVM unit
      test test_tpr_threshold_values in L1.  L0 also hits a WARN in this
      case due to a stale arch.cr4.UMIP.
      
      L1:
        BUG: unable to handle kernel paging request at ffffc90000663b9e
        PGD 276512067 P4D 276512067 PUD 276513067 PMD 274efa067 PTE 8000000271de2163
        Oops: 0009 [#1] SMP
        CPU: 5 PID: 12495 Comm: qemu-system-x86 Tainted: G        W         4.18.0-rc2+ #2
        Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
        RIP: 0010:native_load_gdt+0x0/0x10
      
        ...
      
        Call Trace:
         load_fixmap_gdt+0x22/0x30
         __vmx_load_host_state+0x10e/0x1c0 [kvm_intel]
         vmx_switch_vmcs+0x2d/0x50 [kvm_intel]
         nested_vmx_vmexit+0x222/0x9c0 [kvm_intel]
         vmx_handle_exit+0x246/0x15a0 [kvm_intel]
         kvm_arch_vcpu_ioctl_run+0x850/0x1830 [kvm]
         kvm_vcpu_ioctl+0x3a1/0x5c0 [kvm]
         do_vfs_ioctl+0x9f/0x600
         ksys_ioctl+0x66/0x70
         __x64_sys_ioctl+0x16/0x20
         do_syscall_64+0x4f/0x100
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      L0:
        WARNING: CPU: 2 PID: 3529 at arch/x86/kvm/vmx.c:6618 handle_desc+0x28/0x30 [kvm_intel]
        ...
        CPU: 2 PID: 3529 Comm: qemu-system-x86 Not tainted 4.17.2-coffee+ #76
        Hardware name: Intel Corporation Kabylake Client platform/KBL S
        RIP: 0010:handle_desc+0x28/0x30 [kvm_intel]
      
        ...
      
        Call Trace:
         kvm_arch_vcpu_ioctl_run+0x863/0x1840 [kvm]
         kvm_vcpu_ioctl+0x3a1/0x5c0 [kvm]
         do_vfs_ioctl+0x9f/0x5e0
         ksys_ioctl+0x66/0x70
         __x64_sys_ioctl+0x16/0x20
         do_syscall_64+0x49/0xf0
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 5af41573 (KVM: nVMX: Fix mmu context after VMLAUNCH/VMRESUME failure)
      Fixes: 4f350c6d (kvm: nVMX: Handle deferred early VMLAUNCH/VMRESUME failure properly)
      Cc: Jim Mattson <jmattson@google.com>
      Cc: Krish Sadhukhan <krish.sadhukhan@oracle.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim KrÄmář <rkrcmar@redhat.com>
      Cc: Wanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f35e2a68
    • K
      HID: usbhid: Add quirk for Redragon/Dragonrise Seymur 2 · 3d11fc93
      Kai-Heng Feng 提交于
      [ Upstream commit ce9d58d3eafcb2d452a69bdcc1c5f8b8ff640de5 ]
      
      Redragon Seymur 2 stops working since commit 190d7f02 ("HID: input:
      do not increment usages when a duplicate is found").
      
      Use quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE suggested by the commit
      can solve the issue.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
      BugLink: https://bugs.launchpad.net/bugs/1793846Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3d11fc93
    • R
      ACPI / SBS: Fix GPE storm on recent MacBookPro's · 1424b7fe
      Ronald Tschalär 提交于
      [ Upstream commit ca1721c5bee77105829cbd7baab8ee0eab85b06d ]
      
      On Apple machines, plugging-in or unplugging the power triggers a GPE
      for the EC. Since these machines expose an SBS device, this GPE ends
      up triggering the acpi_sbs_callback(). This in turn tries to get the
      status of the SBS charger. However, on MBP13,* and MBP14,* machines,
      performing the smbus-read operation to get the charger's status triggers
      the EC's GPE again. The result is an endless re-triggering and handling
      of that GPE, consuming significant CPU resources (> 50% in irq).
      
      In the end this is quite similar to commit 3031cdde (ACPI / SBS:
      Don't assume the existence of an SBS charger), except that on the above
      machines a status of all 1's is returned. And like there, we just want
      ignore the charger here.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=198169Signed-off-by: NRonald Tschalär <ronald@innovation.ch>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1424b7fe
    • M
      usbip: fix vhci_hcd controller counting · 0d41c7b3
      Maciej Żenczykowski 提交于
      [ Upstream commit e0a2e73e501c77037c8756137e87b12c7c3c9793 ]
      
      Without this usbip fails on a machine with devices
      that lexicographically come after vhci_hcd.
      
      ie.
        $ ls -l /sys/devices/platform
        ...
        drwxr-xr-x. 4 root root    0 Sep 19 16:21 serial8250
        -rw-r--r--. 1 root root 4096 Sep 19 23:50 uevent
        drwxr-xr-x. 6 root root    0 Sep 20 13:15 vhci_hcd.0
        drwxr-xr-x. 4 root root    0 Sep 19 16:22 w83627hf.656
      
      Because it detects 'w83627hf.656' as another vhci_hcd controller,
      and then fails to be able to talk to it.
      
      Note: this doesn't actually fix usbip's support for multiple
      controllers... that's still broken for other reasons
      ("vhci_hcd.0" is hardcoded in a string macro), but is enough to
      actually make it work on the above machine.
      
      See also:
        https://bugzilla.redhat.com/show_bug.cgi?id=1631148
      
      Cc: Jonathan Dieter <jdieter@gmail.com>
      Cc: Valentina Manea <valentina.manea.m@gmail.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: linux-usb@vger.kernel.org
      Signed-off-by: NMaciej Żenczykowski <zenczykowski@gmail.com>
      Acked-by: NShuah Khan (Samsung OSG) <shuah@kernel.org>
      Tested-by: NJonathan Dieter <jdieter@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0d41c7b3
    • B
      ARM: samsung: Limit SAMSUNG_PM_CHECK config option to non-Exynos platforms · 360186d8
      Bartlomiej Zolnierkiewicz 提交于
      [ Upstream commit 6862fdf2201ab67cd962dbf0643d37db909f4860 ]
      
      "S3C2410 PM Suspend Memory CRC" feature (controlled by
      SAMSUNG_PM_CHECK config option) is incompatible with highmem
      (uses phys_to_virt() instead of proper mapping) which is used by
      the majority of Exynos boards. The issue manifests itself in OOPS
      on affected boards, i.e. on Odroid-U3 I got the following one:
      
      Unable to handle kernel paging request at virtual address f0000000
      pgd = 1c0f9bb4
      [f0000000] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      [<c0458034>] (crc32_le) from [<c0121f8c>] (s3c_pm_makecheck+0x34/0x54)
      [<c0121f8c>] (s3c_pm_makecheck) from [<c0121efc>] (s3c_pm_run_res+0x74/0x8c)
      [<c0121efc>] (s3c_pm_run_res) from [<c0121ecc>] (s3c_pm_run_res+0x44/0x8c)
      [<c0121ecc>] (s3c_pm_run_res) from [<c01210b8>] (exynos_suspend_enter+0x64/0x148)
      [<c01210b8>] (exynos_suspend_enter) from [<c018893c>] (suspend_devices_and_enter+0x9ec/0xe74)
      [<c018893c>] (suspend_devices_and_enter) from [<c0189534>] (pm_suspend+0x770/0xc04)
      [<c0189534>] (pm_suspend) from [<c0186ce8>] (state_store+0x6c/0xcc)
      [<c0186ce8>] (state_store) from [<c09db434>] (kobj_attr_store+0x14/0x20)
      [<c09db434>] (kobj_attr_store) from [<c02fa63c>] (sysfs_kf_write+0x4c/0x50)
      [<c02fa63c>] (sysfs_kf_write) from [<c02f97a4>] (kernfs_fop_write+0xfc/0x1e4)
      [<c02f97a4>] (kernfs_fop_write) from [<c027b198>] (__vfs_write+0x2c/0x140)
      [<c027b198>] (__vfs_write) from [<c027b418>] (vfs_write+0xa4/0x160)
      [<c027b418>] (vfs_write) from [<c027b5d8>] (ksys_write+0x40/0x8c)
      [<c027b5d8>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
      
      Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
      SAMSUNG_PM_CHECK config option to hide it on Exynos platforms.
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      360186d8
    • Y
      pinctrl: core: make sure strcmp() doesn't get a null parameter · 1475ce4f
      Yanjiang Jin 提交于
      [ Upstream commit 54a58185bfafb5af5045fb8388c45daa373f90f3 ]
      
      Some drivers, for example, QCOM's qdf2xxx, set groups[gpio].name only
      when gpio is valid, and leave invalid gpio names as null.
      If we want to access the sys node "pinconf-groups",
      pinctrl_get_group_selector() -> get_group_name() may return a null
      pointer if group_selector is invalid, then the below Kernel panic
      would happen since strcmp() uses this null pointer to do comparison.
      
       Unable to handle kernel NULL pointer dereference at ss 00000000
      el:Internal error: Oops: 9600000[ 143.080279]
      SMP
       CPU: 19 PID: 2493 Comm: read_all Tainted: G O
      .aarch64 #1
       Hardware name: HXT Semiconductor HXT REP-2 System
       PC is at strcmp+0x18/0x154
       LR is at pinctrl_get_group_selector+0x6c/0xe8
       Process read_all (pid: 2493, stack limit =
       Call trace:
       Exception stack
        strcmp+0x18/0x154
        pin_config_group_get+0x64/0xd8
        pinconf_generic_dump_one+0xd8/0x1c0
        pinconf_generic_dump_pins+0x94/0xc8
        pinconf_groups_show+0xb4/0x104
        seq_read+0x178/0x464
        full_proxy_read+0x6c/0xac
        __vfs_read+0x58/0x178
        vfs_read+0x94/0x164
        SyS_read+0x60/0xc0
        __sys_trace_return+0x0/0x4
       --[ end trace]--
       Kernel panic - not syncing: Fatal exception
      Signed-off-by: NYanjiang Jin <yanjiang.jin@hxt-semitech.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1475ce4f
    • J
      HID: i2c-hid: override HID descriptors for certain devices · 8e271100
      Julian Sax 提交于
      [ Upstream commit 9ee3e06610fdb8a601cde59c92089fb6c1deb4aa ]
      
      A particular touchpad (SIPODEV SP1064) refuses to supply the HID
      descriptors. This patch provides the framework for overriding these
      descriptors based on DMI data. It also includes the descriptors for
      said touchpad, which were extracted by listening to the traffic of the
      windows filter driver, as well as the DMI data for the laptops known
      to use this device.
      
      Relevant Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1526312
      
      Cc: Hans de Goede <hdegoede@redhat.com>
      Reported-and-tested-by: ahormann@gmx.net
      Reported-and-tested-by: NBruno Jesus <bruno.fl.jesus@gmail.com>
      Reported-and-tested-by: NDietrich <enaut.w@googlemail.com>
      Reported-and-tested-by: kloxdami@yahoo.com
      Signed-off-by: NJulian Sax <jsbc@gmx.de>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8e271100
    • M
      Bluetooth: Fix debugfs NULL pointer dereference · 09b6c080
      Matias Karhumaa 提交于
      [ Upstream commit 30d65e0804d58a03d1a8ea4e12c6fc07ed08218b ]
      
      Fix crash caused by NULL pointer dereference when debugfs functions
      le_max_key_read, le_max_key_size_write, le_min_key_size_read or
      le_min_key_size_write and Bluetooth adapter was powered off.
      
      Fix is to move max_key_size and min_key_size from smp_dev to hci_dev.
      At the same time they were renamed to le_max_key_size and
      le_min_key_size.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000000000002e8
      PGD 0 P4D 0
      Oops: 0000 [#24] SMP PTI
      CPU: 2 PID: 6255 Comm: cat Tainted: G      D    OE     4.18.9-200.fc28.x86_64 #1
      Hardware name: LENOVO 4286CTO/4286CTO, BIOS 8DET76WW (1.46 ) 06/21/2018
      RIP: 0010:le_max_key_size_read+0x45/0xb0 [bluetooth]
      Code: 00 00 00 48 83 ec 10 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 48 8b 87 c8 00 00 00 48 8d 7c 24 04 48 8b 80 48 0a 00 00 <48> 8b 80 e8 02 00 00 0f b6 48 52 e8 fb b6 b3 ed be 04 00 00 00 48
      RSP: 0018:ffffab23c3ff3df0 EFLAGS: 00010246
      RAX: 0000000000000000 RBX: 00007f0b4ca2e000 RCX: ffffab23c3ff3f08
      RDX: ffffffffc0ddb033 RSI: 0000000000000004 RDI: ffffab23c3ff3df4
      RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffab23c3ff3ed8 R11: 0000000000000000 R12: ffffab23c3ff3f08
      R13: 00007f0b4ca2e000 R14: 0000000000020000 R15: ffffab23c3ff3f08
      FS:  00007f0b4ca0f540(0000) GS:ffff91bd5e280000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000002e8 CR3: 00000000629fa006 CR4: 00000000000606e0
      Call Trace:
       full_proxy_read+0x53/0x80
       __vfs_read+0x36/0x180
       vfs_read+0x8a/0x140
       ksys_read+0x4f/0xb0
       do_syscall_64+0x5b/0x160
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Signed-off-by: NMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      09b6c080
    • B
      media: au0828: cannot kfree dev before usb disconnect · 6496b963
      Brad Love 提交于
      [ Upstream commit 4add7104919f9e94e0db03e234caeadbfcc02ea9 ]
      
      If au0828_analog_register fails, the dev is kfree'd and then flow
      jumps to done, which can call au0828_usb_disconnect. Since all USB
      error codes are negative, au0828_usb_disconnect will be called. The
      problem is au0828_usb_disconnect uses dev, if dev is NULL then there
      is immediate oops encountered.
      
      [    7.454307] au0828: au0828_usb_probe() au0282_dev_register failed to register on V4L2
      [    7.454323] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      [    7.454421] PGD 0 P4D 0
      [    7.454457] Oops: 0002 [#1] SMP PTI
      [    7.454500] CPU: 1 PID: 262 Comm: systemd-udevd Tainted: P           O      4.18.3 #1
      [    7.454584] Hardware name: Google Panther/Panther, BIOS MattDevo 04/27/2015
      [    7.454670] RIP: 0010:_raw_spin_lock_irqsave+0x2c/0x50
      [    7.454725] Code: 44 00 00 55 48 89 e5 41 54 53 48 89 fb 9c 58 0f 1f 44 00 00 49 89 c4 fa 66 0f 1f 44 00 00 e8 db 23 1b ff 31 c0 ba 01 00 00 00 <f0> 0f b1 13 85 c0 75 08 4c 89 e0 5b 41 5c 5d c3 89 c6 48 89 df e8
      [    7.455004] RSP: 0018:ffff9130f53ef988 EFLAGS: 00010046
      [    7.455063] RAX: 0000000000000000 RBX: 0000000000000050 RCX: 0000000000000000
      [    7.455139] RDX: 0000000000000001 RSI: 0000000000000003 RDI: 0000000000000050
      [    7.455216] RBP: ffff9130f53ef998 R08: 0000000000000018 R09: 0000000000000090
      [    7.455292] R10: ffffed4cc53cb000 R11: ffffed4cc53cb108 R12: 0000000000000082
      [    7.455369] R13: ffff9130cf2c6188 R14: 0000000000000000 R15: 0000000000000018
      [    7.455447] FS:  00007f2ff8514cc0(0000) GS:ffff9130fcb00000(0000) knlGS:0000000000000000
      [    7.455535] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    7.455597] CR2: 0000000000000050 CR3: 00000001753f0002 CR4: 00000000000606a0
      [    7.455675] Call Trace:
      [    7.455713]  __wake_up_common_lock+0x65/0xc0
      [    7.455764]  __wake_up+0x13/0x20
      [    7.455808]  ir_lirc_unregister+0x57/0xe0 [rc_core]
      [    7.455865]  rc_unregister_device+0xa0/0xc0 [rc_core]
      [    7.455935]  au0828_rc_unregister+0x25/0x40 [au0828]
      [    7.455999]  au0828_usb_disconnect+0x33/0x80 [au0828]
      [    7.456064]  au0828_usb_probe.cold.16+0x8d/0x2aa [au0828]
      [    7.456130]  usb_probe_interface+0xf1/0x300
      [    7.456184]  driver_probe_device+0x2e3/0x460
      [    7.456235]  __driver_attach+0xe4/0x110
      [    7.456282]  ? driver_probe_device+0x460/0x460
      [    7.456335]  bus_for_each_dev+0x74/0xb0
      [    7.456385]  ? kmem_cache_alloc_trace+0x15d/0x1d0
      [    7.456441]  driver_attach+0x1e/0x20
      [    7.456485]  bus_add_driver+0x159/0x230
      [    7.456532]  driver_register+0x70/0xc0
      [    7.456578]  usb_register_driver+0x7f/0x140
      [    7.456626]  ? 0xffffffffc0474000
      [    7.456674]  au0828_init+0xbc/0x1000 [au0828]
      [    7.456725]  do_one_initcall+0x4a/0x1c9
      [    7.456771]  ? _cond_resched+0x19/0x30
      [    7.456817]  ? kmem_cache_alloc_trace+0x15d/0x1d0
      [    7.456873]  do_init_module+0x60/0x210
      [    7.456918]  load_module+0x221b/0x2710
      [    7.456966]  ? vfs_read+0xf5/0x120
      [    7.457010]  __do_sys_finit_module+0xbd/0x120
      [    7.457061]  ? __do_sys_finit_module+0xbd/0x120
      [    7.457115]  __x64_sys_finit_module+0x1a/0x20
      [    7.457166]  do_syscall_64+0x5b/0x110
      [    7.457210]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Signed-off-by: NBrad Love <brad@nextdimension.cc>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6496b963
    • N
      powerpc/pseries: Remove prrn_work workqueue · 6947d853
      Nathan Fontenot 提交于
      [ Upstream commit cd24e457fd8b2d087d9236700c8d2957054598bf ]
      
      When a PRRN event is received we are already running in a worker
      thread. Instead of spawning off another worker thread on the prrn_work
      workqueue to handle the PRRN event we can just call the PRRN handler
      routine directly.
      
      With this update we can also pass the scope variable for the PRRN
      event directly to the handler instead of it being a global variable.
      
      This patch fixes the following oops mnessage we are seeing in PRRN testing:
      
        Oops: Bad kernel stack pointer, sig: 6 [#1]
        SMP NR_CPUS=2048 NUMA pSeries
        Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache binfmt_misc reiserfs vfat fat rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag af_packet xfs libcrc32c dm_service_time ibmveth(X) ses enclosure scsi_transport_sas rtc_generic btrfs xor raid6_pq sd_mod ibmvscsi(X) scsi_transport_srp ipr(X) libata sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
        Supported: Yes, External                                                     54
        CPU: 7 PID: 18967 Comm: kworker/u96:0 Tainted: G                 X 4.4.126-94.22-default #1
        Workqueue: pseries hotplug workque pseries_hp_work_fn
        task: c000000775367790 ti: c00000001ebd4000 task.ti: c00000070d140000
        NIP: 0000000000000000 LR: 000000001fb3d050 CTR: 0000000000000000
        REGS: c00000001ebd7d40 TRAP: 0700   Tainted: G                 X  (4.4.126-94.22-default)
        MSR: 8000000102081000 <41,VEC,ME5  CR: 28000002  XER: 20040018   4
        CFAR: 000000001fb3d084 40 419   1                                3
        GPR00: 000000000000000040000000000010007 000000001ffff400 000000041fffe200
        GPR04: 000000000000008050000000000000000 000000001fb15fa8 0000000500000500
        GPR08: 000000000001f40040000000000000001 0000000000000000 000005:5200040002
        GPR12: 00000000000000005c000000007a05400 c0000000000e89f8 000000001ed9f668
        GPR16: 000000001fbeff944000000001fbeff94 000000001fb545e4 0000006000000060
        GPR20: ffffffffffffffff4ffffffffffffffff 0000000000000000 0000000000000000
        GPR24: 00000000000000005400000001fb3c000 0000000000000000 000000001fb1b040
        GPR28: 000000001fb240004000000001fb440d8 0000000000000008 0000000000000000
        NIP [0000000000000000] 5         (null)
        LR [000000001fb3d050] 031fb3d050
        Call Trace:            4
        Instruction dump:      4                                       5:47 12    2
        XXXXXXXX XXXXXXXX XXXXX4XX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
        XXXXXXXX XXXXXXXX XXXXX5XX XXXXXXXX 60000000 60000000 60000000 60000000
        ---[ end trace aa5627b04a7d9d6b ]---                                       3NMI watchdog: BUG: soft lockup - CPU#27 stuck for 23s! [kworker/27:0:13903]
        Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache binfmt_misc reiserfs vfat fat rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag af_packet xfs libcrc32c dm_service_time ibmveth(X) ses enclosure scsi_transport_sas rtc_generic btrfs xor raid6_pq sd_mod ibmvscsi(X) scsi_transport_srp ipr(X) libata sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
        Supported: Yes, External
        CPU: 27 PID: 13903 Comm: kworker/27:0 Tainted: G      D          X 4.4.126-94.22-default #1
        Workqueue: events prrn_work_fn
        task: c000000747cfa390 ti: c00000074712c000 task.ti: c00000074712c000
        NIP: c0000000008002a8 LR: c000000000090770 CTR: 000000000032e088
        REGS: c00000074712f7b0 TRAP: 0901   Tainted: G      D          X  (4.4.126-94.22-default)
        MSR: 8000000100009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 22482044  XER: 20040000
        CFAR: c0000000008002c4 SOFTE: 1
        GPR00: c000000000090770 c00000074712fa30 c000000000f09800 c000000000fa1928 6:02
        GPR04: c000000775f5e000 fffffffffffffffe 0000000000000001 c000000000f42db8
        GPR08: 0000000000000001 0000000080000007 0000000000000000 0000000000000000
        GPR12: 8006210083180000 c000000007a14400
        NIP [c0000000008002a8] _raw_spin_lock+0x68/0xd0
        LR [c000000000090770] mobility_rtas_call+0x50/0x100
        Call Trace:            59                                        5
        [c00000074712fa60] [c000000000090770] mobility_rtas_call+0x50/0x100
        [c00000074712faf0] [c000000000090b08] pseries_devicetree_update+0xf8/0x530
        [c00000074712fc20] [c000000000031ba4] prrn_work_fn+0x34/0x50
        [c00000074712fc40] [c0000000000e0390] process_one_work+0x1a0/0x4e0
        [c00000074712fcd0] [c0000000000e0870] worker_thread+0x1a0/0x6105:57       2
        [c00000074712fd80] [c0000000000e8b18] kthread+0x128/0x150
        [c00000074712fe30] [c0000000000096f8] ret_from_kernel_thread+0x5c/0x64
        Instruction dump:
        2c090000 40c20010 7d40192d 40c2fff0 7c2004ac 2fa90000 40de0018 5:540030   3
        e8010010 ebe1fff8 7c0803a6 4e800020 <7c210b78> e92d0000 89290009 792affe3
      Signed-off-by: NJohn Allen <jallen@linux.ibm.com>
      Signed-off-by: NHaren Myneni <haren@us.ibm.com>
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6947d853
    • M
      serial: uartps: console_setup() can't be placed to init section · 7863304b
      Michal Simek 提交于
      [ Upstream commit 4bb1ce2350a598502b23088b169e16b43d4bc639 ]
      
      When console device is rebinded, console_setup() is called again.
      But marking it as __init means that function will be clear after boot is
      complete. If console device is binded again console_setup() is not found
      and error "Unable to handle kernel paging request at virtual address"
      is reported.
      Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7863304b
    • P
      netfilter: xt_cgroup: shrink size of v2 path · 1f2b1c6a
      Pablo Neira Ayuso 提交于
      [ Upstream commit 0d704967f4a49cc2212350b3e4a8231f8b4283ed ]
      
      cgroup v2 path field is PATH_MAX which is too large, this is placing too
      much pressure on memory allocation for people with many rules doing
      cgroup v1 classid matching, side effects of this are bug reports like:
      
      https://bugzilla.kernel.org/show_bug.cgi?id=200639
      
      This patch registers a new revision that shrinks the cgroup path to 512
      bytes, which is the same approach we follow in similar extensions that
      have a path field.
      
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1f2b1c6a