1. 20 Apr, 2019 40 commits
    • Pi-Hsun Shih's avatar
      include/linux/swap.h: use offsetof() instead of custom __swapoffset macro · c43e2bdd
      Pi-Hsun Shih authored
      [ Upstream commit a4046c06 ]
      
      Use offsetof() to calculate offset of a field to take advantage of
      compiler built-in version when possible, and avoid UBSAN warning when
      compiling with Clang:
      
        UBSAN: Undefined behaviour in mm/swapfile.c:3010:38
        member access within null pointer of type 'union swap_header'
        CPU: 6 PID: 1833 Comm: swapon Tainted: G S                4.19.23 #43
        Call trace:
         dump_backtrace+0x0/0x194
         show_stack+0x20/0x2c
         __dump_stack+0x20/0x28
         dump_stack+0x70/0x94
         ubsan_epilogue+0x14/0x44
         ubsan_type_mismatch_common+0xf4/0xfc
         __ubsan_handle_type_mismatch_v1+0x34/0x54
         __se_sys_swapon+0x654/0x1084
         __arm64_sys_swapon+0x1c/0x24
         el0_svc_common+0xa8/0x150
         el0_svc_compat_handler+0x2c/0x38
         el0_svc_compat+0x8/0x18
      
      Link: http://lkml.kernel.org/r/20190312081902.223764-1-pihsun@chromium.orgSigned-off-by: default avatarPi-Hsun Shih <pihsun@chromium.org>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c43e2bdd
    • Stanislaw Gruszka's avatar
      lib/div64.c: off by one in shift · 6dc75ccb
      Stanislaw Gruszka authored
      [ Upstream commit cdc94a37 ]
      
      fls counts bits starting from 1 to 32 (returns 0 for zero argument).  If
      we add 1 we shift right one bit more and loose precision from divisor,
      what cause function incorect results with some numbers.
      
      Corrected code was tested in user-space, see bugzilla:
         https://bugzilla.kernel.org/show_bug.cgi?id=202391
      
      Link: http://lkml.kernel.org/r/1548686944-11891-1-git-send-email-sgruszka@redhat.com
      Fixes: 658716d1 ("div64_u64(): improve precision on 32bit platforms")
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Reported-by: default avatarSiarhei Volkau <lis8215@gmail.com>
      Tested-by: default avatarSiarhei Volkau <lis8215@gmail.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6dc75ccb
    • YueHaibing's avatar
      appletalk: Fix use-after-free in atalk_proc_exit · 0ba1fa56
      YueHaibing authored
      [ Upstream commit 6377f787 ]
      
      KASAN report this:
      
      BUG: KASAN: use-after-free in pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71
      Read of size 8 at addr ffff8881f41fe5b0 by task syz-executor.0/2806
      
      CPU: 0 PID: 2806 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xfa/0x1ce lib/dump_stack.c:113
       print_address_description+0x65/0x270 mm/kasan/report.c:187
       kasan_report+0x149/0x18d mm/kasan/report.c:317
       pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71
       remove_proc_entry+0xe8/0x420 fs/proc/generic.c:667
       atalk_proc_exit+0x18/0x820 [appletalk]
       atalk_exit+0xf/0x5a [appletalk]
       __do_sys_delete_module kernel/module.c:1018 [inline]
       __se_sys_delete_module kernel/module.c:961 [inline]
       __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007fb2de6b9c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200001c0
      RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb2de6ba6bc
      R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff
      
      Allocated by task 2806:
       set_track mm/kasan/common.c:85 [inline]
       __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496
       slab_post_alloc_hook mm/slab.h:444 [inline]
       slab_alloc_node mm/slub.c:2739 [inline]
       slab_alloc mm/slub.c:2747 [inline]
       kmem_cache_alloc+0xcf/0x250 mm/slub.c:2752
       kmem_cache_zalloc include/linux/slab.h:730 [inline]
       __proc_create+0x30f/0xa20 fs/proc/generic.c:408
       proc_mkdir_data+0x47/0x190 fs/proc/generic.c:469
       0xffffffffc10c01bb
       0xffffffffc10c0166
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 2806:
       set_track mm/kasan/common.c:85 [inline]
       __kasan_slab_free+0x130/0x180 mm/kasan/common.c:458
       slab_free_hook mm/slub.c:1409 [inline]
       slab_free_freelist_hook mm/slub.c:1436 [inline]
       slab_free mm/slub.c:2986 [inline]
       kmem_cache_free+0xa6/0x2a0 mm/slub.c:3002
       pde_put+0x6e/0x80 fs/proc/generic.c:647
       remove_proc_entry+0x1d3/0x420 fs/proc/generic.c:684
       0xffffffffc10c031c
       0xffffffffc10c0166
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8881f41fe500
       which belongs to the cache proc_dir_entry of size 256
      The buggy address is located 176 bytes inside of
       256-byte region [ffff8881f41fe500, ffff8881f41fe600)
      The buggy address belongs to the page:
      page:ffffea0007d07f80 count:1 mapcount:0 mapping:ffff8881f6e69a00 index:0x0
      flags: 0x2fffc0000000200(slab)
      raw: 02fffc0000000200 dead000000000100 dead000000000200 ffff8881f6e69a00
      raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8881f41fe480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff8881f41fe500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8881f41fe580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                           ^
       ffff8881f41fe600: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
       ffff8881f41fe680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      It should check the return value of atalk_proc_init fails,
      otherwise atalk_exit will trgger use-after-free in pde_subdir_find
      while unload the module.This patch fix error cleanup path of atalk_init
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0ba1fa56
    • Kevin Wang's avatar
      drm/amdkfd: use init_mqd function to allocate object for hid_mqd (CI) · 86c7f76a
      Kevin Wang authored
      [ Upstream commit cac734c2 ]
      
      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: default avatarKevin Wang <kevin1.wang@amd.com>
      Reviewed-by: default avatarOak Zeng <Oak.Zeng@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      86c7f76a
    • Yang Shi's avatar
      ARM: 8839/1: kprobe: make patch_lock a raw_spinlock_t · 5e3f6ba8
      Yang Shi authored
      [ Upstream commit 143c2a89 ]
      
      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: default avatarYang Shi <yang.shi@linaro.org>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5e3f6ba8
    • Ilia Mirkin's avatar
      drm/nouveau/volt/gf117: fix speedo readout register · 03e67ed3
      Ilia Mirkin authored
      [ Upstream commit fc782242 ]
      
      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: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      03e67ed3
    • Leo Yan's avatar
      coresight: cpu-debug: Support for CA73 CPUs · a68ee104
      Leo Yan authored
      [ Upstream commit a0f890ab ]
      
      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: default avatarLeo Yan <leo.yan@linaro.org>
      Signed-off-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a68ee104
    • Zhang Rui's avatar
      Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk" · 3e3adeb2
      Zhang Rui authored
      [ Upstream commit b6a3e147 ]
      
      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: default avatarOrtwin Glück <odi@odi.ch>
      Tested-by: default avatarFrancisco Cribari <cribari@gmail.com>
      Tested-by: default avatarBalazs Varga <balazs4web@gmail.com>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3e3adeb2
    • Lars Persson's avatar
      crypto: axis - fix for recursive locking from bottom half · 56828309
      Lars Persson authored
      [ Upstream commit c34a8382 ]
      
      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: default avatarLars Persson <larper@axis.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      56828309
    • Hsin-Yi, Wang's avatar
      drm/panel: panel-innolux: set display off in innolux_panel_unprepare · 61bea6ad
      Hsin-Yi, Wang authored
      [ Upstream commit 46f3ceaf ]
      
      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: default avatarHsin-Yi, Wang <hsinyi@chromium.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190109065922.231753-1-hsinyi@chromium.orgSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      61bea6ad
    • Christophe Leroy's avatar
      lkdtm: Add tests for NULL pointer dereference · f2778b35
      Christophe Leroy authored
      [ Upstream commit 59a12205 ]
      
      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: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f2778b35
    • Christophe Leroy's avatar
      lkdtm: Print real addresses · b035faf5
      Christophe Leroy authored
      [ Upstream commit 4c411157 ]
      
      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: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b035faf5
    • Dmitry Osipenko's avatar
      soc/tegra: pmc: Drop locking from tegra_powergate_is_powered() · 201aee30
      Dmitry Osipenko authored
      [ Upstream commit b6e1fd17 ]
      
      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: default avatarDmitry Osipenko <digetx@gmail.com>
      Acked-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      201aee30
    • Julia Cartwright's avatar
      iommu/dmar: Fix buffer overflow during PCI bus notification · e2f0e69f
      Julia Cartwright authored
      [ Upstream commit cffaaf0c ]
      
      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: default avatarJulia Cartwright <julia@ni.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e2f0e69f
    • Ard Biesheuvel's avatar
      crypto: sha512/arm - fix crash bug in Thumb2 build · 29b56343
      Ard Biesheuvel authored
      [ Upstream commit c6431650 ]
      
      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: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      29b56343
    • Ard Biesheuvel's avatar
      crypto: sha256/arm - fix crash bug in Thumb2 build · 92562a9f
      Ard Biesheuvel authored
      [ Upstream commit 69216a54 ]
      
      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: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      92562a9f
    • Vitaly Kuznetsov's avatar
      kernel: hung_task.c: disable on suspend · 507f2f17
      Vitaly Kuznetsov authored
      [ Upstream commit a1c6ca3c ]
      
      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: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      507f2f17
    • Steve French's avatar
      cifs: fallback to older infolevels on findfirst queryinfo retry · 1d41cd12
      Steve French authored
      [ Upstream commit 3b7960ca ]
      
      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: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1d41cd12
    • ndesaulniers@google.com's avatar
      compiler.h: update definition of unreachable() · 82017e26
      ndesaulniers@google.com authored
      [ Upstream commit fe0640eb ]
      
      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: default avatarAndy Lutomirski <luto@amacapital.net>
      Suggested-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Tested-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      82017e26
    • Sean Christopherson's avatar
      KVM: nVMX: restore host state in nested_vmx_vmexit for VMFail · 05e78850
      Sean Christopherson authored
      [ Upstream commit bd18bffc ]
      
      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: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      05e78850
    • Ronald Tschalär's avatar
      ACPI / SBS: Fix GPE storm on recent MacBookPro's · 00254adf
      Ronald Tschalär authored
      [ Upstream commit ca1721c5 ]
      
      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: default avatarRonald Tschalär <ronald@innovation.ch>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      00254adf
    • Maciej Żenczykowski's avatar
      usbip: fix vhci_hcd controller counting · 0dd66375
      Maciej Żenczykowski authored
      [ Upstream commit e0a2e73e ]
      
      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: default avatarMaciej Żenczykowski <zenczykowski@gmail.com>
      Acked-by: default avatarShuah Khan (Samsung OSG) <shuah@kernel.org>
      Tested-by: default avatarJonathan Dieter <jdieter@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0dd66375
    • Bartlomiej Zolnierkiewicz's avatar
      ARM: samsung: Limit SAMSUNG_PM_CHECK config option to non-Exynos platforms · ef9f4326
      Bartlomiej Zolnierkiewicz authored
      [ Upstream commit 6862fdf2 ]
      
      "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: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ef9f4326
    • Julian Sax's avatar
      HID: i2c-hid: override HID descriptors for certain devices · e058a6e5
      Julian Sax authored
      [ Upstream commit 9ee3e066 ]
      
      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: default avatarBruno Jesus <bruno.fl.jesus@gmail.com>
      Reported-and-tested-by: default avatarDietrich <enaut.w@googlemail.com>
      Reported-and-tested-by: kloxdami@yahoo.com
      Signed-off-by: default avatarJulian Sax <jsbc@gmx.de>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e058a6e5
    • Brad Love's avatar
      media: au0828: cannot kfree dev before usb disconnect · fec306b2
      Brad Love authored
      [ Upstream commit 4add7104 ]
      
      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: default avatarBrad Love <brad@nextdimension.cc>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fec306b2
    • Nathan Fontenot's avatar
      powerpc/pseries: Remove prrn_work workqueue · 8b8fa987
      Nathan Fontenot authored
      [ Upstream commit cd24e457 ]
      
      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: default avatarJohn Allen <jallen@linux.ibm.com>
      Signed-off-by: default avatarHaren Myneni <haren@us.ibm.com>
      Signed-off-by: default avatarNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8b8fa987
    • Michal Simek's avatar
      serial: uartps: console_setup() can't be placed to init section · 1fa5208a
      Michal Simek authored
      [ Upstream commit 4bb1ce23 ]
      
      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: default avatarMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1fa5208a
    • Pablo Neira Ayuso's avatar
      netfilter: xt_cgroup: shrink size of v2 path · edbcdafa
      Pablo Neira Ayuso authored
      [ Upstream commit 0d704967 ]
      
      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: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      edbcdafa
    • Chao Yu's avatar
      f2fs: fix to do sanity check with current segment number · 40e8d128
      Chao Yu authored
      [ Upstream commit 042be0f8 ]
      
      https://bugzilla.kernel.org/show_bug.cgi?id=200219
      
      Reproduction way:
      - mount image
      - run poc code
      - umount image
      
      F2FS-fs (loop1): Bitmap was wrongly set, blk:15364
      ------------[ cut here ]------------
      kernel BUG at /home/yuchao/git/devf2fs/segment.c:2061!
      invalid opcode: 0000 [#1] PREEMPT SMP
      CPU: 2 PID: 17686 Comm: umount Tainted: G        W  O      4.18.0-rc2+ #39
      Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      EIP: update_sit_entry+0x459/0x4e0 [f2fs]
      Code: e8 1c b5 fd ff 0f 0b 0f 0b 8b 45 e4 c7 44 24 08 9c 7a 6c f8 c7 44 24 04 bc 4a 6c f8 89 44 24 0c 8b 06 89 04 24 e8 f7 b4 fd ff <0f> 0b 8b 45 e4 0f b6 d2 89 54 24 10 c7 44 24 08 60 7a 6c f8 c7 44
      EAX: 00000032 EBX: 000000f8 ECX: 00000002 EDX: 00000001
      ESI: d7177000 EDI: f520fe68 EBP: d6477c6c ESP: d6477c34
      DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010282
      CR0: 80050033 CR2: b7fbe000 CR3: 2a99b3c0 CR4: 000406f0
      Call Trace:
       f2fs_allocate_data_block+0x124/0x580 [f2fs]
       do_write_page+0x78/0x150 [f2fs]
       f2fs_do_write_node_page+0x25/0xa0 [f2fs]
       __write_node_page+0x2bf/0x550 [f2fs]
       f2fs_sync_node_pages+0x60e/0x6d0 [f2fs]
       ? sync_inode_metadata+0x2f/0x40
       ? f2fs_write_checkpoint+0x28f/0x7d0 [f2fs]
       ? up_write+0x1e/0x80
       f2fs_write_checkpoint+0x2a9/0x7d0 [f2fs]
       ? mark_held_locks+0x5d/0x80
       ? _raw_spin_unlock_irq+0x27/0x50
       kill_f2fs_super+0x68/0x90 [f2fs]
       deactivate_locked_super+0x3d/0x70
       deactivate_super+0x40/0x60
       cleanup_mnt+0x39/0x70
       __cleanup_mnt+0x10/0x20
       task_work_run+0x81/0xa0
       exit_to_usermode_loop+0x59/0xa7
       do_fast_syscall_32+0x1f5/0x22c
       entry_SYSENTER_32+0x53/0x86
      EIP: 0xb7f95c51
      Code: c1 1e f7 ff ff 89 e5 8b 55 08 85 d2 8b 81 64 cd ff ff 74 02 89 02 5d c3 8b 0c 24 c3 8b 1c 24 c3 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
      EAX: 00000000 EBX: 0871ab90 ECX: bfb2cd00 EDX: 00000000
      ESI: 00000000 EDI: 0871ab90 EBP: 0871ab90 ESP: bfb2cd7c
      DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
      Modules linked in: f2fs(O) crc32_generic bnep rfcomm bluetooth ecdh_generic snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq pcbc joydev aesni_intel snd_seq_device aes_i586 snd_timer crypto_simd snd cryptd soundcore mac_hid serio_raw video i2c_piix4 parport_pc ppdev lp parport hid_generic psmouse usbhid hid e1000 [last unloaded: f2fs]
      ---[ end trace d423f83982cfcdc5 ]---
      
      The reason is, different log headers using the same segment, once
      one log's next block address is used by another log, it will cause
      panic as above.
      
      Main area: 24 segs, 24 secs 24 zones
        - COLD  data: 0, 0, 0
        - WARM  data: 1, 1, 1
        - HOT   data: 20, 20, 20
        - Dir   dnode: 22, 22, 22
        - File   dnode: 22, 22, 22
        - Indir nodes: 21, 21, 21
      
      So this patch adds sanity check to detect such condition to avoid
      this issue.
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      40e8d128
    • Dinu-Razvan Chis-Serban's avatar
      9p locks: add mount option for lock retry interval · 85a2ad15
      Dinu-Razvan Chis-Serban authored
      [ Upstream commit 5e172f75 ]
      
      The default P9_LOCK_TIMEOUT can be too long for some users exporting
      a local file system to a guest VM (30s), make this configurable at
      mount time.
      
      Link: http://lkml.kernel.org/r/1536295827-3181-1-git-send-email-asmadeus@codewreck.org
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195727Signed-off-by: default avatarDinu-Razvan Chis-Serban <justcsdr@gmail.com>
      Signed-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      85a2ad15
    • Gertjan Halkes's avatar
      9p: do not trust pdu content for stat item size · fdf0c593
      Gertjan Halkes authored
      [ Upstream commit 2803cf43 ]
      
      v9fs_dir_readdir() could deadloop if a struct was sent with a size set
      to -2
      
      Link: http://lkml.kernel.org/r/1536134432-11997-1-git-send-email-asmadeus@codewreck.org
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88021Signed-off-by: default avatarGertjan Halkes <gertjan@google.com>
      Signed-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fdf0c593
    • Siva Rebbagondla's avatar
      rsi: improve kernel thread handling to fix kernel panic · ad78e2e0
      Siva Rebbagondla authored
      [ Upstream commit 4c62764d ]
      
      While running regressions, observed below kernel panic when sdio disconnect
      called. This is because of, kthread_stop() is taking care of
      wait_for_completion() by default. When wait_for_completion triggered
      in kthread_stop and as it was done already, giving kernel panic.
      Hence, removing redundant wait_for_completion() from rsi_kill_thread().
      
      ... skipping ...
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50
      PGD 0
      Oops: 0002 [#1] SMP
      CPU: 0 PID: 6502 Comm: rmmod Tainted: G  OE   4.15.9-Generic #154-Ubuntu
      Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017
      Stack:
      ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000
      ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000
      ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15
      Call Trace:
      [<ffffffff8108160a>] __put_task_struct+0x5a/0x140
      [<ffffffff810a484b>] kthread_stop+0x10b/0x110
      [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio]
      [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80
      [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100
      [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150
      [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0
      [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0
      [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50
      [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20
      [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio]
      [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210
      [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb
      Signed-off-by: default avatarSiva Rebbagondla <siva.rebbagondla@redpinesignals.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ad78e2e0
    • Robert Jarzmik's avatar
      gpio: pxa: handle corner case of unprobed device · 15fbb1fe
      Robert Jarzmik authored
      [ Upstream commit 9ce3ebe9 ]
      
      In the corner case where the gpio driver probe fails, for whatever
      reason, the suspend and resume handlers will still be called as they
      have to be registered as syscore operations. This applies as well when
      no probe was called while the driver has been built in the kernel.
      
      Nicolas tracked this in :
      https://bugzilla.kernel.org/show_bug.cgi?id=200905
      
      Therefore, add a failsafe in these function, and test if a proper probe
      succeeded and the driver is functional.
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Reported-by: default avatarNicolas Chauvet <kwizart@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      15fbb1fe
    • Darrick J. Wong's avatar
      ext4: prohibit fstrim in norecovery mode · 6fee657d
      Darrick J. Wong authored
      [ Upstream commit 18915b58 ]
      
      The ext4 fstrim implementation uses the block bitmaps to find free space
      that can be discarded.  If we haven't replayed the journal, the bitmaps
      will be stale and we absolutely *cannot* use stale metadata to zap the
      underlying storage.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6fee657d
    • Steve French's avatar
      fix incorrect error code mapping for OBJECTID_NOT_FOUND · 329f34e8
      Steve French authored
      [ Upstream commit 85f9987b ]
      
      It was mapped to EIO which can be confusing when user space
      queries for an object GUID for an object for which the server
      file system doesn't support (or hasn't saved one).
      
      As Amir Goldstein suggested this is similar to ENOATTR
      (equivalently ENODATA in Linux errno definitions) so
      changing NT STATUS code mapping for OBJECTID_NOT_FOUND
      to ENODATA.
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Amir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      329f34e8
    • Nathan Chancellor's avatar
      x86/hw_breakpoints: Make default case in hw_breakpoint_arch_parse() return an error · 727344f1
      Nathan Chancellor authored
      [ Upstream commit e898e69d ]
      
      When building with -Wsometimes-uninitialized, Clang warns:
      
      arch/x86/kernel/hw_breakpoint.c:355:2: warning: variable 'align' is used
      uninitialized whenever switch default is taken
      [-Wsometimes-uninitialized]
      
      The default cannot be reached because arch_build_bp_info() initializes
      hw->len to one of the specified cases. Nevertheless the warning is valid
      and returning -EINVAL makes sure that this cannot be broken by future
      modifications.
      Suggested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: clang-built-linux@googlegroups.com
      Link: https://github.com/ClangBuiltLinux/linux/issues/392
      Link: https://lkml.kernel.org/r/20190307212756.4648-1-natechancellor@gmail.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      727344f1
    • Lu Baolu's avatar
      iommu/vt-d: Check capability before disabling protected memory · 486d8220
      Lu Baolu authored
      [ Upstream commit 5bb71fc7 ]
      
      The spec states in 10.4.16 that the Protected Memory Enable
      Register should be treated as read-only for implementations
      not supporting protected memory regions (PLMR and PHMR fields
      reported as Clear in the Capability register).
      
      Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
      Cc: mark gross <mgross@intel.com>
      Suggested-by: default avatarAshok Raj <ashok.raj@intel.com>
      Fixes: f8bab735 ("intel-iommu: PMEN support")
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      486d8220
    • YueHaibing's avatar
      drm/nouveau/debugfs: Fix check of pm_runtime_get_sync failure · 19525f7b
      YueHaibing authored
      [ Upstream commit 909e9c9c ]
      
      pm_runtime_get_sync returns negative on failure.
      
      Fixes: eaeb9010 ("drm/nouveau/debugfs: Wake up GPU before doing any reclocking")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      19525f7b
    • Matthew Whitehead's avatar
      x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors · 20afb90f
      Matthew Whitehead authored
      [ Upstream commit 18fb053f ]
      
      There are comments in processor-cyrix.h advising you to _not_ make calls
      using the deprecated macros in this style:
      
        setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
      
      This is because it expands the macro into a non-functioning calling
      sequence. The calling order must be:
      
        outb(CX86_CCR2, 0x22);
        inb(0x23);
      
      From the comments:
      
       * When using the old macros a line like
       *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
       * gets expanded to:
       *  do {
       *    outb((CX86_CCR2), 0x22);
       *    outb((({
       *        outb((CX86_CCR2), 0x22);
       *        inb(0x23);
       *    }) | 0x88), 0x23);
       *  } while (0);
      
      The new macros fix this problem, so use them instead. Tested on an
      actual Geode processor.
      Signed-off-by: default avatarMatthew Whitehead <tedheadster@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: luto@kernel.org
      Link: https://lkml.kernel.org/r/1552596361-8967-2-git-send-email-tedheadster@gmail.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      20afb90f
    • Aditya Pakki's avatar
      x86/hpet: Prevent potential NULL pointer dereference · c65812de
      Aditya Pakki authored
      [ Upstream commit 2e84f116 ]
      
      hpet_virt_address may be NULL when ioremap_nocache fail, but the code lacks
      a check.
      
      Add a check to prevent NULL pointer dereference.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: kjlu@umn.edu
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Nicolai Stange <nstange@suse.de>
      Cc: Roland Dreier <roland@purestorage.com>
      Link: https://lkml.kernel.org/r/20190319021958.17275-1-pakki001@umn.eduSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      c65812de