1. 01 Oct, 2020 40 commits
    • Daniel Borkmann's avatar
      bpf: Fix clobbering of r2 in bpf_gen_ld_abs · 87f947e2
      Daniel Borkmann authored
      [ Upstream commit e6a18d36 ]
      
      Bryce reported that he saw the following with:
      
        0:  r6 = r1
        1:  r1 = 12
        2:  r0 = *(u16 *)skb[r1]
      
      The xlated sequence was incorrectly clobbering r2 with pointer
      value of r6 ...
      
        0: (bf) r6 = r1
        1: (b7) r1 = 12
        2: (bf) r1 = r6
        3: (bf) r2 = r1
        4: (85) call bpf_skb_load_helper_16_no_cache#7692160
      
      ... and hence call to the load helper never succeeded given the
      offset was too high. Fix it by reordering the load of r6 to r1.
      
      Other than that the insn has similar calling convention than BPF
      helpers, that is, r0 - r5 are scratch regs, so nothing else
      affected after the insn.
      
      Fixes: e0cea7ce ("bpf: implement ld_abs/ld_ind in native bpf")
      Reported-by: default avatarBryce Kahle <bryce.kahle@datadoghq.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/cace836e4d07bb63b1a53e49c5dfb238a040c298.1599512096.git.daniel@iogearbox.netSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      87f947e2
    • Eric Dumazet's avatar
      mac802154: tx: fix use-after-free · 788a00c1
      Eric Dumazet authored
      [ Upstream commit 0ff4628f ]
      
      syzbot reported a bug in ieee802154_tx() [1]
      
      A similar issue in ieee802154_xmit_worker() is also fixed in this patch.
      
      [1]
      BUG: KASAN: use-after-free in ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88
      Read of size 4 at addr ffff8880251a8c70 by task syz-executor.3/928
      
      CPU: 0 PID: 928 Comm: syz-executor.3 Not tainted 5.9.0-rc3-syzkaller #0
      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+0x198/0x1fd lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383
       __kasan_report mm/kasan/report.c:513 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
       ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88
       ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130
       __netdev_start_xmit include/linux/netdevice.h:4634 [inline]
       netdev_start_xmit include/linux/netdevice.h:4648 [inline]
       dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203
       packet_snd net/packet/af_packet.c:2989 [inline]
       packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:671
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x45d5b9
      Code: 5d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fc98e749c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 000000000002ccc0 RCX: 000000000045d5b9
      RDX: 0000000000000000 RSI: 0000000020007780 RDI: 000000000000000b
      RBP: 000000000118d020 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118cfec
      R13: 00007fff690c720f R14: 00007fc98e74a9c0 R15: 000000000118cfec
      
      Allocated by task 928:
       kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
       kasan_set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
       slab_post_alloc_hook mm/slab.h:518 [inline]
       slab_alloc_node mm/slab.c:3254 [inline]
       kmem_cache_alloc_node+0x136/0x3e0 mm/slab.c:3574
       __alloc_skb+0x71/0x550 net/core/skbuff.c:198
       alloc_skb include/linux/skbuff.h:1094 [inline]
       alloc_skb_with_frags+0x92/0x570 net/core/skbuff.c:5771
       sock_alloc_send_pskb+0x72a/0x880 net/core/sock.c:2348
       packet_alloc_skb net/packet/af_packet.c:2837 [inline]
       packet_snd net/packet/af_packet.c:2932 [inline]
       packet_sendmsg+0x19fb/0x5290 net/packet/af_packet.c:3014
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:671
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 928:
       kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
       kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
       kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355
       __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422
       __cache_free mm/slab.c:3418 [inline]
       kmem_cache_free.part.0+0x74/0x1e0 mm/slab.c:3693
       kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:622
       __kfree_skb net/core/skbuff.c:679 [inline]
       consume_skb net/core/skbuff.c:838 [inline]
       consume_skb+0xcf/0x160 net/core/skbuff.c:832
       __dev_kfree_skb_any+0x9c/0xc0 net/core/dev.c:3107
       fakelb_hw_xmit+0x20e/0x2a0 drivers/net/ieee802154/fakelb.c:81
       drv_xmit_async net/mac802154/driver-ops.h:16 [inline]
       ieee802154_tx+0x282/0x480 net/mac802154/tx.c:81
       ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130
       __netdev_start_xmit include/linux/netdevice.h:4634 [inline]
       netdev_start_xmit include/linux/netdevice.h:4648 [inline]
       dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203
       packet_snd net/packet/af_packet.c:2989 [inline]
       packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:671
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The buggy address belongs to the object at ffff8880251a8c00
       which belongs to the cache skbuff_head_cache of size 224
      The buggy address is located 112 bytes inside of
       224-byte region [ffff8880251a8c00, ffff8880251a8ce0)
      The buggy address belongs to the page:
      page:0000000062b6a4f1 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x251a8
      flags: 0xfffe0000000200(slab)
      raw: 00fffe0000000200 ffffea0000435c88 ffffea00028b6c08 ffff8880a9055d00
      raw: 0000000000000000 ffff8880251a80c0 000000010000000c 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880251a8b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880251a8b80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff8880251a8c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                   ^
       ffff8880251a8c80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
       ffff8880251a8d00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
      
      Fixes: 409c3b0c ("mac802154: tx: move stats tx increment")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Alexander Aring <alex.aring@gmail.com>
      Cc: Stefan Schmidt <stefan@datenfreihafen.org>
      Cc: linux-wpan@vger.kernel.org
      Link: https://lore.kernel.org/r/20200908104025.4009085-1-edumazet@google.comSigned-off-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      788a00c1
    • Linus Lüssing's avatar
      batman-adv: mcast/TT: fix wrongly dropped or rerouted packets · e63e927d
      Linus Lüssing authored
      [ Upstream commit 7dda5b33 ]
      
      The unicast packet rerouting code makes several assumptions. For
      instance it assumes that there is always exactly one destination in the
      TT. This breaks for multicast frames in a unicast packets in several ways:
      
      For one thing if there is actually no TT entry and the destination node
      was selected due to the multicast tvlv flags it announced. Then an
      intermediate node will wrongly drop the packet.
      
      For another thing if there is a TT entry but the TTVN of this entry is
      newer than the originally addressed destination node: Then the
      intermediate node will wrongly redirect the packet, leading to
      duplicated multicast packets at a multicast listener and missing
      packets at other multicast listeners or multicast routers.
      
      Fixing this by not applying the unicast packet rerouting to batman-adv
      unicast packets with a multicast payload. We are not able to detect a
      roaming multicast listener at the moment and will just continue to send
      the multicast frame to both the new and old destination for a while in
      case of such a roaming multicast listener.
      
      Fixes: a73105b8 ("batman-adv: improved client announcement mechanism")
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e63e927d
    • Jing Xiangfeng's avatar
      atm: eni: fix the missed pci_disable_device() for eni_init_one() · 48fb5d1e
      Jing Xiangfeng authored
      [ Upstream commit c2b94787 ]
      
      eni_init_one() misses to call pci_disable_device() in an error path.
      Jump to err_disable to fix it.
      
      Fixes: ede58ef2 ("atm: remove deprecated use of pci api")
      Signed-off-by: default avatarJing Xiangfeng <jingxiangfeng@huawei.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      48fb5d1e
    • Linus Lüssing's avatar
      batman-adv: bla: fix type misuse for backbone_gw hash indexing · 8d6cd745
      Linus Lüssing authored
      [ Upstream commit 097930e8 ]
      
      It seems that due to a copy & paste error the void pointer
      in batadv_choose_backbone_gw() is cast to the wrong type.
      
      Fixing this by using "struct batadv_bla_backbone_gw" instead of "struct
      batadv_bla_claim" which better matches the caller's side.
      
      For now it seems that we were lucky because the two structs both have
      their orig/vid and addr/vid in the beginning. However I stumbled over
      this issue when I was trying to add some debug variables in front of
      "orig" in batadv_backbone_gw, which caused hash lookups to fail.
      
      Fixes: 07568d03 ("batman-adv: don't rely on positions in struct for hashing")
      Signed-off-by: default avatarLinus Lüssing <ll@simonwunderlich.de>
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8d6cd745
    • Maximilian Luz's avatar
      mwifiex: Increase AES key storage size to 256 bits · 9f59089e
      Maximilian Luz authored
      [ Upstream commit 4afc850e ]
      
      Following commit e1869678 ("mwifiex: Prevent memory corruption
      handling keys") the mwifiex driver fails to authenticate with certain
      networks, specifically networks with 256 bit keys, and repeatedly asks
      for the password. The kernel log repeats the following lines (id and
      bssid redacted):
      
          mwifiex_pcie 0000:01:00.0: info: trying to associate to '<id>' bssid <bssid>
          mwifiex_pcie 0000:01:00.0: info: associated to bssid <bssid> successfully
          mwifiex_pcie 0000:01:00.0: crypto keys added
          mwifiex_pcie 0000:01:00.0: info: successfully disconnected from <bssid>: reason code 3
      
      Tracking down this problem lead to the overflow check introduced by the
      aforementioned commit into mwifiex_ret_802_11_key_material_v2(). This
      check fails on networks with 256 bit keys due to the current storage
      size for AES keys in struct mwifiex_aes_param being only 128 bit.
      
      To fix this issue, increase the storage size for AES keys to 256 bit.
      
      Fixes: e1869678 ("mwifiex: Prevent memory corruption handling keys")
      Signed-off-by: default avatarMaximilian Luz <luzmaximilian@gmail.com>
      Reported-by: default avatarKaloyan Nikolov <konik98@gmail.com>
      Tested-by: default avatarKaloyan Nikolov <konik98@gmail.com>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarBrian Norris <briannorris@chromium.org>
      Tested-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20200825153829.38043-1-luzmaximilian@gmail.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      9f59089e
    • Tianjia Zhang's avatar
      clocksource/drivers/h8300_timer8: Fix wrong return value in h8300_8timer_init() · 907a6ee8
      Tianjia Zhang authored
      [ Upstream commit 400d033f ]
      
      In the init function, if the call to of_iomap() fails, the return
      value is ENXIO instead of -ENXIO.
      
      Change to the right negative errno.
      
      Fixes: 691f8f87 ("clocksource/drivers/h8300_timer8: Convert init function to return error")
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: default avatarTianjia Zhang <tianjia.zhang@linux.alibaba.com>
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Link: https://lore.kernel.org/r/20200802111541.5429-1-tianjia.zhang@linux.alibaba.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      907a6ee8
    • Tom Rix's avatar
      ieee802154/adf7242: check status of adf7242_read_reg · 0ad77d7d
      Tom Rix authored
      [ Upstream commit e3914ed6 ]
      
      Clang static analysis reports this error
      
      adf7242.c:887:6: warning: Assigned value is garbage or undefined
              len = len_u8;
                  ^ ~~~~~~
      
      len_u8 is set in
             adf7242_read_reg(lp, 0, &len_u8);
      
      When this call fails, len_u8 is not set.
      
      So check the return code.
      
      Fixes: 7302b9d9 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154")
      Signed-off-by: default avatarTom Rix <trix@redhat.com>
      Acked-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Link: https://lore.kernel.org/r/20200802142339.21091-1-trix@redhat.comSigned-off-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0ad77d7d
    • Liu Jian's avatar
      ieee802154: fix one possible memleak in ca8210_dev_com_init · a24c2499
      Liu Jian authored
      [ Upstream commit 88f46b3f ]
      
      We should call destroy_workqueue to destroy mlme_workqueue in error branch.
      
      Fixes: ded845a7 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
      Signed-off-by: default avatarLiu Jian <liujian56@huawei.com>
      Link: https://lore.kernel.org/r/20200720143315.40523-1-liujian56@huawei.comSigned-off-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a24c2499
    • Josh Poimboeuf's avatar
      objtool: Fix noreturn detection for ignored functions · 8c821f48
      Josh Poimboeuf authored
      [ Upstream commit db6c6a0d ]
      
      When a function is annotated with STACK_FRAME_NON_STANDARD, objtool
      doesn't validate its code paths.  It also skips sibling call detection
      within the function.
      
      But sibling call detection is actually needed for the case where the
      ignored function doesn't have any return instructions.  Otherwise
      objtool naively marks the function as implicit static noreturn, which
      affects the reachability of its callers, resulting in "unreachable
      instruction" warnings.
      
      Fix it by just enabling sibling call detection for ignored functions.
      The 'insn->ignore' check in add_jump_destinations() is no longer needed
      after
      
        e6da9567 ("objtool: Don't use ignore flag for fake jumps").
      
      Fixes the following warning:
      
        arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_handle_exit_irqoff()+0x142: unreachable instruction
      
      which triggers on an allmodconfig with CONFIG_GCOV_KERNEL unset.
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Link: https://lkml.kernel.org/r/5b1e2536cdbaa5246b60d7791b76130a74082c62.1599751464.git.jpoimboe@redhat.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      8c821f48
    • Hans de Goede's avatar
      i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices() · 8216a385
      Hans de Goede authored
      [ Upstream commit 21653a41 ]
      
      Some ACPI i2c-devices _STA method (which is used to detect if the device
      is present) use autodetection code which probes which device is present
      over i2c. This requires the I2C ACPI OpRegion handler to be registered
      before we enumerate i2c-clients under the i2c-adapter.
      
      This fixes the i2c touchpad on the Lenovo ThinkBook 14-IIL and
      ThinkBook 15 IIL not getting an i2c-client instantiated and thus not
      working.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1842039Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8216a385
    • Dennis Li's avatar
      drm/amdkfd: fix a memory leak issue · ce81be26
      Dennis Li authored
      [ Upstream commit 087d7641 ]
      
      In the resume stage of GPU recovery, start_cpsch will call pm_init
      which set pm->allocated as false, cause the next pm_release_ib has
      no chance to release ib memory.
      
      Add pm_release_ib in stop_cpsch which will be called in the suspend
      stage of GPU recovery.
      Reviewed-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: default avatarDennis Li <Dennis.Li@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ce81be26
    • Sven Schnelle's avatar
      lockdep: fix order in trace_hardirqs_off_caller() · aafa75ff
      Sven Schnelle authored
      [ Upstream commit 73ac74c7 ]
      
      Switch order so that locking state is consistent even
      if the IRQ tracer calls into lockdep again.
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarSven Schnelle <svens@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      aafa75ff
    • Ilya Leoshkevich's avatar
      s390/init: add missing __init annotations · b0800562
      Ilya Leoshkevich authored
      [ Upstream commit fcb2b70c ]
      
      Add __init to reserve_memory_end, reserve_oldmem and remove_oldmem.
      Sometimes these functions are not inlined, and then the build
      complains about section mismatch.
      Signed-off-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b0800562
    • Palmer Dabbelt's avatar
      RISC-V: Take text_mutex in ftrace_init_nop() · f959196c
      Palmer Dabbelt authored
      [ Upstream commit 66d18dbd ]
      
      Without this we get lockdep failures.  They're spurious failures as SMP isn't
      up when ftrace_init_nop() is called.  As far as I can tell the easiest fix is
      to just take the lock, which also seems like the safest fix.
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      Acked-by: default avatarGuo Ren <guoren@kernel.org>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f959196c
    • Hans de Goede's avatar
      ASoC: Intel: bytcr_rt5640: Add quirk for MPMAN Converter9 2-in-1 · 66dc1945
      Hans de Goede authored
      [ Upstream commit 6a013710 ]
      
      The MPMAN Converter9 2-in-1 almost fully works with out default settings.
      The only problem is that it has only 1 speaker so any sounds only playing
      on the right channel get lost.
      
      Add a quirk for this model using the default settings + MONO_SPEAKER.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Link: https://lore.kernel.org/r/20200901080623.4987-1-hdegoede@redhat.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      66dc1945
    • Sylwester Nawrocki's avatar
      ASoC: wm8994: Ensure the device is resumed in wm89xx_mic_detect functions · 9af818a3
      Sylwester Nawrocki authored
      [ Upstream commit f5a2cda4 ]
      
      When the wm8958_mic_detect, wm8994_mic_detect functions get called from
      the machine driver, e.g. from the card's late_probe() callback, the CODEC
      device may be PM runtime suspended and any regmap writes have no effect.
      Add PM runtime calls to these functions to ensure the device registers
      are updated as expected.
      This suppresses an error during boot
      "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
      caused by the regmap access error due to the cache_only flag being set.
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Acked-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Acked-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20200827173357.31891-2-s.nawrocki@samsung.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9af818a3
    • Sylwester Nawrocki's avatar
      ASoC: wm8994: Skip setting of the WM8994_MICBIAS register for WM1811 · 9688d307
      Sylwester Nawrocki authored
      [ Upstream commit 811c5494 ]
      
      The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip
      initialization of that register for that device.
      This suppresses an error during boot:
      "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Acked-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Acked-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20200827173357.31891-1-s.nawrocki@samsung.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9688d307
    • Anthony Iliopoulos's avatar
      nvme: explicitly update mpath disk capacity on revalidation · 906c9129
      Anthony Iliopoulos authored
      [ Upstream commit 05b29021 ]
      
      Commit 3b4b1972 ("nvme: fix possible deadlock when I/O is
      blocked") reverted multipath head disk revalidation due to deadlocks
      caused by holding the bd_mutex during revalidate.
      
      Updating the multipath disk blockdev size is still required though for
      userspace to be able to observe any resizing while the device is
      mounted. Directly update the bdev inode size to avoid unnecessarily
      holding the bdev->bd_mutex.
      
      Fixes: 3b4b1972 ("nvme: fix possible deadlock when I/O is
      blocked")
      Signed-off-by: default avatarAnthony Iliopoulos <ailiop@suse.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      906c9129
    • Tonghao Zhang's avatar
      net: openvswitch: use div_u64() for 64-by-32 divisions · 1e6a4232
      Tonghao Zhang authored
      [ Upstream commit 659d4587 ]
      
      Compile the kernel for arm 32 platform, the build warning found.
      To fix that, should use div_u64() for divisions.
      | net/openvswitch/meter.c:396: undefined reference to `__udivdi3'
      
      [add more commit msg, change reported tag, and use div_u64 instead
      of do_div by Tonghao]
      
      Fixes: e5735887 ("net: openvswitch: use u64 for meter bucket")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarTonghao Zhang <xiangxia.m.yue@gmail.com>
      Tested-by: default avatarTonghao Zhang <xiangxia.m.yue@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1e6a4232
    • Jin Yao's avatar
      perf parse-events: Use strcmp() to compare the PMU name · 31c5c447
      Jin Yao authored
      [ Upstream commit 8510895b ]
      
      A big uncore event group is split into multiple small groups which only
      include the uncore events from the same PMU. This has been supported in
      the commit 3cdc5c2c ("perf parse-events: Handle uncore event
      aliases in small groups properly").
      
      If the event's PMU name starts to repeat, it must be a new event.
      That can be used to distinguish the leader from other members.
      But now it only compares the pointer of pmu_name
      (leader->pmu_name == evsel->pmu_name).
      
      If we use "perf stat -M LLC_MISSES.PCIE_WRITE -a" on cascadelakex,
      the event list is:
      
        evsel->name					evsel->pmu_name
        ---------------------------------------------------------------
        unc_iio_data_req_of_cpu.mem_write.part0		uncore_iio_4 (as leader)
        unc_iio_data_req_of_cpu.mem_write.part0		uncore_iio_2
        unc_iio_data_req_of_cpu.mem_write.part0		uncore_iio_0
        unc_iio_data_req_of_cpu.mem_write.part0		uncore_iio_5
        unc_iio_data_req_of_cpu.mem_write.part0		uncore_iio_3
        unc_iio_data_req_of_cpu.mem_write.part0		uncore_iio_1
        unc_iio_data_req_of_cpu.mem_write.part1		uncore_iio_4
        ......
      
      For the event "unc_iio_data_req_of_cpu.mem_write.part1" with
      "uncore_iio_4", it should be the event from PMU "uncore_iio_4".
      It's not a new leader for this PMU.
      
      But if we use "(leader->pmu_name == evsel->pmu_name)", the check
      would be failed and the event is stored to leaders[] as a new
      PMU leader.
      
      So this patch uses strcmp to compare the PMU name between events.
      
      Fixes: d4953f7e ("perf parse-events: Fix 3 use after frees found with clang ASAN")
      Signed-off-by: default avatarJin Yao <yao.jin@linux.intel.com>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jin Yao <yao.jin@intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lore.kernel.org/lkml/20200430003618.17002-1-yao.jin@linux.intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      31c5c447
    • Hou Tao's avatar
      ubi: fastmap: Free unused fastmap anchor peb during detach · 7d3d6fc1
      Hou Tao authored
      [ Upstream commit c16f39d1 ]
      
      When CONFIG_MTD_UBI_FASTMAP is enabled, fm_anchor will be assigned
      a free PEB during ubi_wl_init() or ubi_update_fastmap(). However
      if fastmap is not used or disabled on the MTD device, ubi_wl_entry
      related with the PEB will not be freed during detach.
      
      So Fix it by freeing the unused fastmap anchor during detach.
      
      Fixes: f9c34bb5 ("ubi: Fix producing anchor PEBs")
      Reported-by: syzbot+f317896aae32eb281a58@syzkaller.appspotmail.com
      Reviewed-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarHou Tao <houtao1@huawei.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7d3d6fc1
    • Qu Wenruo's avatar
      btrfs: qgroup: fix data leak caused by race between writeback and truncate · 803b2f2f
      Qu Wenruo authored
      [ Upstream commit fa91e4aa ]
      
      [BUG]
      When running tests like generic/013 on test device with btrfs quota
      enabled, it can normally lead to data leak, detected at unmount time:
      
        BTRFS warning (device dm-3): qgroup 0/5 has unreleased space, type 0 rsv 4096
        ------------[ cut here ]------------
        WARNING: CPU: 11 PID: 16386 at fs/btrfs/disk-io.c:4142 close_ctree+0x1dc/0x323 [btrfs]
        RIP: 0010:close_ctree+0x1dc/0x323 [btrfs]
        Call Trace:
         btrfs_put_super+0x15/0x17 [btrfs]
         generic_shutdown_super+0x72/0x110
         kill_anon_super+0x18/0x30
         btrfs_kill_super+0x17/0x30 [btrfs]
         deactivate_locked_super+0x3b/0xa0
         deactivate_super+0x40/0x50
         cleanup_mnt+0x135/0x190
         __cleanup_mnt+0x12/0x20
         task_work_run+0x64/0xb0
         __prepare_exit_to_usermode+0x1bc/0x1c0
         __syscall_return_slowpath+0x47/0x230
         do_syscall_64+0x64/0xb0
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        ---[ end trace caf08beafeca2392 ]---
        BTRFS error (device dm-3): qgroup reserved space leaked
      
      [CAUSE]
      In the offending case, the offending operations are:
      2/6: writev f2X[269 1 0 0 0 0] [1006997,67,288] 0
      2/7: truncate f2X[269 1 0 0 48 1026293] 18388 0
      
      The following sequence of events could happen after the writev():
      	CPU1 (writeback)		|		CPU2 (truncate)
      -----------------------------------------------------------------
      btrfs_writepages()			|
      |- extent_write_cache_pages()		|
         |- Got page for 1003520		|
         |  1003520 is Dirty, no writeback	|
         |  So (!clear_page_dirty_for_io())   |
         |  gets called for it		|
         |- Now page 1003520 is Clean.	|
         |					| btrfs_setattr()
         |					| |- btrfs_setsize()
         |					|    |- truncate_setsize()
         |					|       New i_size is 18388
         |- __extent_writepage()		|
         |  |- page_offset() > i_size		|
            |- btrfs_invalidatepage()		|
      	 |- Page is clean, so no qgroup |
      	    callback executed
      
      This means, the qgroup reserved data space is not properly released in
      btrfs_invalidatepage() as the page is Clean.
      
      [FIX]
      Instead of checking the dirty bit of a page, call
      btrfs_qgroup_free_data() unconditionally in btrfs_invalidatepage().
      
      As qgroup rsv are completely bound to the QGROUP_RESERVED bit of
      io_tree, not bound to page status, thus we won't cause double freeing
      anyway.
      
      Fixes: 0b34c261 ("btrfs: qgroup: Prevent qgroup->reserved from going subzero")
      CC: stable@vger.kernel.org # 4.14+
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      803b2f2f
    • Zeng Tao's avatar
      vfio/pci: fix racy on error and request eventfd ctx · 0d1682ca
      Zeng Tao authored
      [ Upstream commit b872d064 ]
      
      The vfio_pci_release call will free and clear the error and request
      eventfd ctx while these ctx could be in use at the same time in the
      function like vfio_pci_request, and it's expected to protect them under
      the vdev->igate mutex, which is missing in vfio_pci_release.
      
      This issue is introduced since commit 1518ac27 ("vfio/pci: fix memory
      leaks of eventfd ctx"),and since commit 5c5866c5 ("vfio/pci: Clear
      error and request eventfd ctx after releasing"), it's very easily to
      trigger the kernel panic like this:
      
      [ 9513.904346] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
      [ 9513.913091] Mem abort info:
      [ 9513.915871]   ESR = 0x96000006
      [ 9513.918912]   EC = 0x25: DABT (current EL), IL = 32 bits
      [ 9513.924198]   SET = 0, FnV = 0
      [ 9513.927238]   EA = 0, S1PTW = 0
      [ 9513.930364] Data abort info:
      [ 9513.933231]   ISV = 0, ISS = 0x00000006
      [ 9513.937048]   CM = 0, WnR = 0
      [ 9513.940003] user pgtable: 4k pages, 48-bit VAs, pgdp=0000007ec7d12000
      [ 9513.946414] [0000000000000008] pgd=0000007ec7d13003, p4d=0000007ec7d13003, pud=0000007ec728c003, pmd=0000000000000000
      [ 9513.956975] Internal error: Oops: 96000006 [#1] PREEMPT SMP
      [ 9513.962521] Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio hclge hns3 hnae3 [last unloaded: vfio_pci]
      [ 9513.972998] CPU: 4 PID: 1327 Comm: bash Tainted: G        W         5.8.0-rc4+ #3
      [ 9513.980443] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B270.01 05/08/2020
      [ 9513.989274] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--)
      [ 9513.994827] pc : _raw_spin_lock_irqsave+0x48/0x88
      [ 9513.999515] lr : eventfd_signal+0x6c/0x1b0
      [ 9514.003591] sp : ffff800038a0b960
      [ 9514.006889] x29: ffff800038a0b960 x28: ffff007ef7f4da10
      [ 9514.012175] x27: ffff207eefbbfc80 x26: ffffbb7903457000
      [ 9514.017462] x25: ffffbb7912191000 x24: ffff007ef7f4d400
      [ 9514.022747] x23: ffff20be6e0e4c00 x22: 0000000000000008
      [ 9514.028033] x21: 0000000000000000 x20: 0000000000000000
      [ 9514.033321] x19: 0000000000000008 x18: 0000000000000000
      [ 9514.038606] x17: 0000000000000000 x16: ffffbb7910029328
      [ 9514.043893] x15: 0000000000000000 x14: 0000000000000001
      [ 9514.049179] x13: 0000000000000000 x12: 0000000000000002
      [ 9514.054466] x11: 0000000000000000 x10: 0000000000000a00
      [ 9514.059752] x9 : ffff800038a0b840 x8 : ffff007ef7f4de60
      [ 9514.065038] x7 : ffff007fffc96690 x6 : fffffe01faffb748
      [ 9514.070324] x5 : 0000000000000000 x4 : 0000000000000000
      [ 9514.075609] x3 : 0000000000000000 x2 : 0000000000000001
      [ 9514.080895] x1 : ffff007ef7f4d400 x0 : 0000000000000000
      [ 9514.086181] Call trace:
      [ 9514.088618]  _raw_spin_lock_irqsave+0x48/0x88
      [ 9514.092954]  eventfd_signal+0x6c/0x1b0
      [ 9514.096691]  vfio_pci_request+0x84/0xd0 [vfio_pci]
      [ 9514.101464]  vfio_del_group_dev+0x150/0x290 [vfio]
      [ 9514.106234]  vfio_pci_remove+0x30/0x128 [vfio_pci]
      [ 9514.111007]  pci_device_remove+0x48/0x108
      [ 9514.115001]  device_release_driver_internal+0x100/0x1b8
      [ 9514.120200]  device_release_driver+0x28/0x38
      [ 9514.124452]  pci_stop_bus_device+0x68/0xa8
      [ 9514.128528]  pci_stop_and_remove_bus_device+0x20/0x38
      [ 9514.133557]  pci_iov_remove_virtfn+0xb4/0x128
      [ 9514.137893]  sriov_disable+0x3c/0x108
      [ 9514.141538]  pci_disable_sriov+0x28/0x38
      [ 9514.145445]  hns3_pci_sriov_configure+0x48/0xb8 [hns3]
      [ 9514.150558]  sriov_numvfs_store+0x110/0x198
      [ 9514.154724]  dev_attr_store+0x44/0x60
      [ 9514.158373]  sysfs_kf_write+0x5c/0x78
      [ 9514.162018]  kernfs_fop_write+0x104/0x210
      [ 9514.166010]  __vfs_write+0x48/0x90
      [ 9514.169395]  vfs_write+0xbc/0x1c0
      [ 9514.172694]  ksys_write+0x74/0x100
      [ 9514.176079]  __arm64_sys_write+0x24/0x30
      [ 9514.179987]  el0_svc_common.constprop.4+0x110/0x200
      [ 9514.184842]  do_el0_svc+0x34/0x98
      [ 9514.188144]  el0_svc+0x14/0x40
      [ 9514.191185]  el0_sync_handler+0xb0/0x2d0
      [ 9514.195088]  el0_sync+0x140/0x180
      [ 9514.198389] Code: b9001020 d2800000 52800022 f9800271 (885ffe61)
      [ 9514.204455] ---[ end trace 648de00c8406465f ]---
      [ 9514.212308] note: bash[1327] exited with preempt_count 1
      
      Cc: Qian Cai <cai@lca.pw>
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Fixes: 1518ac27 ("vfio/pci: fix memory leaks of eventfd ctx")
      Signed-off-by: default avatarZeng Tao <prime.zeng@hisilicon.com>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0d1682ca
    • Andy Lutomirski's avatar
      selftests/x86/syscall_nt: Clear weird flags after each test · 511a287c
      Andy Lutomirski authored
      [ Upstream commit a61fa279 ]
      
      Clear the weird flags before logging to improve strace output --
      logging results while, say, TF is set does no one any favors.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/907bfa5a42d4475b8245e18b67a04b13ca51ffdb.1593191971.git.luto@kernel.orgSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      511a287c
    • Javed Hasan's avatar
      scsi: libfc: Skip additional kref updating work event · 4575845e
      Javed Hasan authored
      [ Upstream commit 823a6540 ]
      
      When an rport event (RPORT_EV_READY) is updated without work being queued,
      avoid taking an additional reference.
      
      This issue was leading to memory leak. Trace from KMEMLEAK tool:
      
        unreferenced object 0xffff8888259e8780 (size 512):
        comm "kworker/2:1", jiffies 4433237386 (age 113021.971s)
          hex dump (first 32 bytes):
      	58 0a ec cf 83 88 ff ff 00 00 00 00 00 00 00 00
      	01 00 00 00 08 00 00 00 13 7d f0 1e 0e 00 00 10
        backtrace:
        [<000000006b25760f>] fc_rport_recv_req+0x3c6/0x18f0 [libfc]
        [<00000000f208d994>] fc_lport_recv_els_req+0x120/0x8a0 [libfc]
        [<00000000a9c437b8>] fc_lport_recv+0xb9/0x130 [libfc]
        [<00000000a9c437b8>] fc_lport_recv+0xb9/0x130 [libfc]
        [<00000000ad5be37b>] qedf_ll2_process_skb+0x73d/0xad0 [qedf]
        [<00000000e0eb6893>] process_one_work+0x382/0x6c0
        [<000000002dfd9e21>] worker_thread+0x57/0x5c0
        [<00000000b648204f>] kthread+0x1a0/0x1c0
        [<0000000072f5ab20>] ret_from_fork+0x35/0x40
        [<000000001d5c05d8>] 0xffffffffffffffff
      
      Below is the log sequence which leads to memory leak.  Here we get the
      RPORT_EV_READY and RPORT_EV_STOP back to back, which lead to overwrite the
      event RPORT_EV_READY by event RPORT_EV_STOP.  Because of this, kref_count
      gets incremented by 1.
      
        kernel: host0: rport fffce5: Received PLOGI request
        kernel: host0: rport fffce5: Received PLOGI in INIT state
        kernel: host0: rport fffce5: Port is Ready
        kernel: host0: rport fffce5: Received PRLI request while in state Ready
        kernel: host0: rport fffce5: PRLI rspp type 8 active 1 passive 0
        kernel: host0: rport fffce5: Received LOGO request while in state Ready
        kernel: host0: rport fffce5: Delete port
        kernel: host0: rport fffce5: Received PLOGI request
        kernel: host0: rport fffce5: Received PLOGI in state Delete - send busy
        kernel: host0: rport fffce5: work event 3
        kernel: host0: rport fffce5: lld callback ev 3
        kernel: host0: rport fffce5: work delete
      
      Link: https://lore.kernel.org/r/20200626094959.32151-1-jhasan@marvell.comReviewed-by: default avatarGirish Basrur <gbasrur@marvell.com>
      Reviewed-by: default avatarSaurav Kashyap <skashyap@marvell.com>
      Reviewed-by: default avatarShyam Sundar <ssundar@marvell.com>
      Signed-off-by: default avatarJaved Hasan <jhasan@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4575845e
    • Javed Hasan's avatar
      scsi: libfc: Handling of extra kref · 694ec54b
      Javed Hasan authored
      [ Upstream commit 71f2bf85 ]
      
      Handling of extra kref which is done by lookup table in case rdata is
      already present in list.
      
      This issue was leading to memory leak. Trace from KMEMLEAK tool:
      
        unreferenced object 0xffff8888259e8780 (size 512):
          comm "kworker/2:1", pid 182614, jiffies 4433237386 (age 113021.971s)
          hex dump (first 32 bytes):
          58 0a ec cf 83 88 ff ff 00 00 00 00 00 00 00 00
          01 00 00 00 08 00 00 00 13 7d f0 1e 0e 00 00 10
        backtrace:
      	[<000000006b25760f>] fc_rport_recv_req+0x3c6/0x18f0 [libfc]
      	[<00000000f208d994>] fc_lport_recv_els_req+0x120/0x8a0 [libfc]
      	[<00000000a9c437b8>] fc_lport_recv+0xb9/0x130 [libfc]
      	[<00000000ad5be37b>] qedf_ll2_process_skb+0x73d/0xad0 [qedf]
      	[<00000000e0eb6893>] process_one_work+0x382/0x6c0
      	[<000000002dfd9e21>] worker_thread+0x57/0x5c0
      	[<00000000b648204f>] kthread+0x1a0/0x1c0
      	[<0000000072f5ab20>] ret_from_fork+0x35/0x40
      	[<000000001d5c05d8>] 0xffffffffffffffff
      
      Below is the log sequence which leads to memory leak. Here we get the
      nested "Received PLOGI request" for same port and this request leads to
      call the fc_rport_create() twice for the same rport.
      
      	kernel: host1: rport fffce5: Received PLOGI request
      	kernel: host1: rport fffce5: Received PLOGI in INIT state
      	kernel: host1: rport fffce5: Port is Ready
      	kernel: host1: rport fffce5: Received PRLI request while in state Ready
      	kernel: host1: rport fffce5: PRLI rspp type 8 active 1 passive 0
      	kernel: host1: rport fffce5: Received LOGO request while in state Ready
      	kernel: host1: rport fffce5: Delete port
      	kernel: host1: rport fffce5: Received PLOGI request
      	kernel: host1: rport fffce5: Received PLOGI in state Delete - send busy
      
      Link: https://lore.kernel.org/r/20200622101212.3922-2-jhasan@marvell.comReviewed-by: default avatarGirish Basrur <gbasrur@marvell.com>
      Reviewed-by: default avatarSaurav Kashyap <skashyap@marvell.com>
      Reviewed-by: default avatarShyam Sundar <ssundar@marvell.com>
      Signed-off-by: default avatarJaved Hasan <jhasan@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      694ec54b
    • Sagi Grimberg's avatar
      nvme: fix possible deadlock when I/O is blocked · 03dfb191
      Sagi Grimberg authored
      [ Upstream commit 3b4b1972 ]
      
      Revert fab7772b ("nvme-multipath: revalidate nvme_ns_head gendisk
      in nvme_validate_ns")
      
      When adding a new namespace to the head disk (via nvme_mpath_set_live)
      we will see partition scan which triggers I/O on the mpath device node.
      This process will usually be triggered from the scan_work which holds
      the scan_lock. If I/O blocks (if we got ana change currently have only
      available paths but none are accessible) this can deadlock on the head
      disk bd_mutex as both partition scan I/O takes it, and head disk revalidation
      takes it to check for resize (also triggered from scan_work on a different
      path). See trace [1].
      
      The mpath disk revalidation was originally added to detect online disk
      size change, but this is no longer needed since commit cb224c3a
      ("nvme: Convert to use set_capacity_revalidate_and_notify") which already
      updates resize info without unnecessarily revalidating the disk (the
      mpath disk doesn't even implement .revalidate_disk fop).
      
      [1]:
      --
      kernel: INFO: task kworker/u65:9:494 blocked for more than 241 seconds.
      kernel:       Tainted: G           OE     5.3.5-050305-generic #201910071830
      kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      kernel: kworker/u65:9   D    0   494      2 0x80004000
      kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core]
      kernel: Call Trace:
      kernel:  __schedule+0x2b9/0x6c0
      kernel:  schedule+0x42/0xb0
      kernel:  schedule_preempt_disabled+0xe/0x10
      kernel:  __mutex_lock.isra.0+0x182/0x4f0
      kernel:  __mutex_lock_slowpath+0x13/0x20
      kernel:  mutex_lock+0x2e/0x40
      kernel:  revalidate_disk+0x63/0xa0
      kernel:  __nvme_revalidate_disk+0xfe/0x110 [nvme_core]
      kernel:  nvme_revalidate_disk+0xa4/0x160 [nvme_core]
      kernel:  ? evict+0x14c/0x1b0
      kernel:  revalidate_disk+0x2b/0xa0
      kernel:  nvme_validate_ns+0x49/0x940 [nvme_core]
      kernel:  ? blk_mq_free_request+0xd2/0x100
      kernel:  ? __nvme_submit_sync_cmd+0xbe/0x1e0 [nvme_core]
      kernel:  nvme_scan_work+0x24f/0x380 [nvme_core]
      kernel:  process_one_work+0x1db/0x380
      kernel:  worker_thread+0x249/0x400
      kernel:  kthread+0x104/0x140
      kernel:  ? process_one_work+0x380/0x380
      kernel:  ? kthread_park+0x80/0x80
      kernel:  ret_from_fork+0x1f/0x40
      ...
      kernel: INFO: task kworker/u65:1:2630 blocked for more than 241 seconds.
      kernel:       Tainted: G           OE     5.3.5-050305-generic #201910071830
      kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      kernel: kworker/u65:1   D    0  2630      2 0x80004000
      kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core]
      kernel: Call Trace:
      kernel:  __schedule+0x2b9/0x6c0
      kernel:  schedule+0x42/0xb0
      kernel:  io_schedule+0x16/0x40
      kernel:  do_read_cache_page+0x438/0x830
      kernel:  ? __switch_to_asm+0x34/0x70
      kernel:  ? file_fdatawait_range+0x30/0x30
      kernel:  read_cache_page+0x12/0x20
      kernel:  read_dev_sector+0x27/0xc0
      kernel:  read_lba+0xc1/0x220
      kernel:  ? kmem_cache_alloc_trace+0x19c/0x230
      kernel:  efi_partition+0x1e6/0x708
      kernel:  ? vsnprintf+0x39e/0x4e0
      kernel:  ? snprintf+0x49/0x60
      kernel:  check_partition+0x154/0x244
      kernel:  rescan_partitions+0xae/0x280
      kernel:  __blkdev_get+0x40f/0x560
      kernel:  blkdev_get+0x3d/0x140
      kernel:  __device_add_disk+0x388/0x480
      kernel:  device_add_disk+0x13/0x20
      kernel:  nvme_mpath_set_live+0x119/0x140 [nvme_core]
      kernel:  nvme_update_ns_ana_state+0x5c/0x60 [nvme_core]
      kernel:  nvme_set_ns_ana_state+0x1e/0x30 [nvme_core]
      kernel:  nvme_parse_ana_log+0xa1/0x180 [nvme_core]
      kernel:  ? nvme_update_ns_ana_state+0x60/0x60 [nvme_core]
      kernel:  nvme_mpath_add_disk+0x47/0x90 [nvme_core]
      kernel:  nvme_validate_ns+0x396/0x940 [nvme_core]
      kernel:  ? blk_mq_free_request+0xd2/0x100
      kernel:  nvme_scan_work+0x24f/0x380 [nvme_core]
      kernel:  process_one_work+0x1db/0x380
      kernel:  worker_thread+0x249/0x400
      kernel:  kthread+0x104/0x140
      kernel:  ? process_one_work+0x380/0x380
      kernel:  ? kthread_park+0x80/0x80
      kernel:  ret_from_fork+0x1f/0x40
      --
      
      Fixes: fab7772b ("nvme-multipath: revalidate nvme_ns_head gendisk
      in nvme_validate_ns")
      Signed-off-by: default avatarAnton Eidelman <anton@lightbitslabs.com>
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      03dfb191
    • Zhang Xiaoxu's avatar
      cifs: Fix double add page to memcg when cifs_readpages · 5f7ca306
      Zhang Xiaoxu authored
      [ Upstream commit 95a3d8f3 ]
      
      When xfstests generic/451, there is an BUG at mm/memcontrol.c:
        page:ffffea000560f2c0 refcount:2 mapcount:0 mapping:000000008544e0ea
             index:0xf
        mapping->aops:cifs_addr_ops dentry name:"tst-aio-dio-cycle-write.451"
        flags: 0x2fffff80000001(locked)
        raw: 002fffff80000001 ffffc90002023c50 ffffea0005280088 ffff88815cda0210
        raw: 000000000000000f 0000000000000000 00000002ffffffff ffff88817287d000
        page dumped because: VM_BUG_ON_PAGE(page->mem_cgroup)
        page->mem_cgroup:ffff88817287d000
        ------------[ cut here ]------------
        kernel BUG at mm/memcontrol.c:2659!
        invalid opcode: 0000 [#1] SMP
        CPU: 2 PID: 2038 Comm: xfs_io Not tainted 5.8.0-rc1 #44
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_
          073836-buildvm-ppc64le-16.ppc.4
        RIP: 0010:commit_charge+0x35/0x50
        Code: 0d 48 83 05 54 b2 02 05 01 48 89 77 38 c3 48 c7
              c6 78 4a ea ba 48 83 05 38 b2 02 05 01 e8 63 0d9
        RSP: 0018:ffffc90002023a50 EFLAGS: 00010202
        RAX: 0000000000000000 RBX: ffff88817287d000 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: ffff88817ac97ea0 RDI: ffff88817ac97ea0
        RBP: ffffea000560f2c0 R08: 0000000000000203 R09: 0000000000000005
        R10: 0000000000000030 R11: ffffc900020237a8 R12: 0000000000000000
        R13: 0000000000000001 R14: 0000000000000001 R15: ffff88815a1272c0
        FS:  00007f5071ab0800(0000) GS:ffff88817ac80000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 000055efcd5ca000 CR3: 000000015d312000 CR4: 00000000000006e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         mem_cgroup_charge+0x166/0x4f0
         __add_to_page_cache_locked+0x4a9/0x710
         add_to_page_cache_locked+0x15/0x20
         cifs_readpages+0x217/0x1270
         read_pages+0x29a/0x670
         page_cache_readahead_unbounded+0x24f/0x390
         __do_page_cache_readahead+0x3f/0x60
         ondemand_readahead+0x1f1/0x470
         page_cache_async_readahead+0x14c/0x170
         generic_file_buffered_read+0x5df/0x1100
         generic_file_read_iter+0x10c/0x1d0
         cifs_strict_readv+0x139/0x170
         new_sync_read+0x164/0x250
         __vfs_read+0x39/0x60
         vfs_read+0xb5/0x1e0
         ksys_pread64+0x85/0xf0
         __x64_sys_pread64+0x22/0x30
         do_syscall_64+0x69/0x150
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x7f5071fcb1af
        Code: Bad RIP value.
        RSP: 002b:00007ffde2cdb8e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011
        RAX: ffffffffffffffda RBX: 00007ffde2cdb990 RCX: 00007f5071fcb1af
        RDX: 0000000000001000 RSI: 000055efcd5ca000 RDI: 0000000000000003
        RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
        R10: 0000000000001000 R11: 0000000000000293 R12: 0000000000000001
        R13: 000000000009f000 R14: 0000000000000000 R15: 0000000000001000
        Modules linked in:
        ---[ end trace 725fa14a3e1af65c ]---
      
      Since commit 3fea5a49 ("mm: memcontrol: convert page cache to a new
      mem_cgroup_charge() API") not cancel the page charge, the pages maybe
      double add to pagecache:
      thread1                       | thread2
      cifs_readpages
      readpages_get_pages
       add_to_page_cache_locked(head,index=n)=0
                                    | readpages_get_pages
                                    | add_to_page_cache_locked(head,index=n+1)=0
       add_to_page_cache_locked(head, index=n+1)=-EEXIST
       then, will next loop with list head page's
       index=n+1 and the page->mapping not NULL
      readpages_get_pages
      add_to_page_cache_locked(head, index=n+1)
       commit_charge
        VM_BUG_ON_PAGE
      
      So, we should not do the next loop when any page add to page cache
      failed.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarZhang Xiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Acked-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5f7ca306
    • Alex Williamson's avatar
      vfio/pci: Clear error and request eventfd ctx after releasing · 41a77298
      Alex Williamson authored
      [ Upstream commit 5c5866c5 ]
      
      The next use of the device will generate an underflow from the
      stale reference.
      
      Cc: Qian Cai <cai@lca.pw>
      Fixes: 1518ac27 ("vfio/pci: fix memory leaks of eventfd ctx")
      Reported-by: default avatarDaniel Wagner <dwagner@suse.de>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Tested-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      41a77298
    • Thomas Gleixner's avatar
      x86/speculation/mds: Mark mds_user_clear_cpu_buffers() __always_inline · f0e13175
      Thomas Gleixner authored
      [ Upstream commit a7ef9ba9 ]
      
      Prevent the compiler from uninlining and creating traceable/probable
      functions as this is invoked _after_ context tracking switched to
      CONTEXT_USER and rcu idle.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarAlexandre Chartre <alexandre.chartre@oracle.com>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20200505134340.902709267@linutronix.deSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      f0e13175
    • Boris Brezillon's avatar
      mtd: parser: cmdline: Support MTD names containing one or more colons · 9a59dfdd
      Boris Brezillon authored
      [ Upstream commit eb13fa02 ]
      
      Looks like some drivers define MTD names with a colon in it, thus
      making mtdpart= parsing impossible. Let's fix the parser to gracefully
      handle that case: the last ':' in a partition definition sequence is
      considered instead of the first one.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: default avatarRon Minnich <rminnich@google.com>
      Tested-by: default avatarRon Minnich <rminnich@google.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9a59dfdd
    • Madhuparna Bhowmik's avatar
      rapidio: avoid data race between file operation callbacks and mport_cdev_add(). · a44cb303
      Madhuparna Bhowmik authored
      [ Upstream commit e1c3cdb2 ]
      
      Fields of md(mport_dev) are set after cdev_device_add().  However, the
      file operation callbacks can be called after cdev_device_add() and
      therefore accesses to fields of md in the callbacks can race with the rest
      of the mport_cdev_add() function.
      
      One such example is INIT_LIST_HEAD(&md->portwrites) in mport_cdev_add(),
      the list is initialised after cdev_device_add().  This can race with
      list_add_tail(&pw_filter->md_node,&md->portwrites) in
      rio_mport_add_pw_filter() which is called by unlocked_ioctl.
      
      To avoid such data races use cdev_device_add() after initializing md.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarMadhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarAlexandre Bounine <alex.bou9@gmail.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Mike Marshall <hubcap@omnibond.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ira Weiny <ira.weiny@intel.com>
      Cc: Allison Randal <allison@lohutok.net>
      Cc: Pavel Andrianov <andrianov@ispras.ru>
      Link: http://lkml.kernel.org/r/20200426112950.1803-1-madhuparnabhowmik10@gmail.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a44cb303
    • Qian Cai's avatar
      mm/swap_state: fix a data race in swapin_nr_pages · 8cc3afd5
      Qian Cai authored
      [ Upstream commit d6c1f098 ]
      
      "prev_offset" is a static variable in swapin_nr_pages() that can be
      accessed concurrently with only mmap_sem held in read mode as noticed by
      KCSAN,
      
       BUG: KCSAN: data-race in swap_cluster_readahead / swap_cluster_readahead
      
       write to 0xffffffff92763830 of 8 bytes by task 14795 on cpu 17:
        swap_cluster_readahead+0x2a6/0x5e0
        swapin_readahead+0x92/0x8dc
        do_swap_page+0x49b/0xf20
        __handle_mm_fault+0xcfb/0xd70
        handle_mm_fault+0xfc/0x2f0
        do_page_fault+0x263/0x715
        page_fault+0x34/0x40
      
       1 lock held by (dnf)/14795:
        #0: ffff897bd2e98858 (&mm->mmap_sem#2){++++}-{3:3}, at: do_page_fault+0x143/0x715
        do_user_addr_fault at arch/x86/mm/fault.c:1405
        (inlined by) do_page_fault at arch/x86/mm/fault.c:1535
       irq event stamp: 83493
       count_memcg_event_mm+0x1a6/0x270
       count_memcg_event_mm+0x119/0x270
       __do_softirq+0x365/0x589
       irq_exit+0xa2/0xc0
      
       read to 0xffffffff92763830 of 8 bytes by task 1 on cpu 22:
        swap_cluster_readahead+0xfd/0x5e0
        swapin_readahead+0x92/0x8dc
        do_swap_page+0x49b/0xf20
        __handle_mm_fault+0xcfb/0xd70
        handle_mm_fault+0xfc/0x2f0
        do_page_fault+0x263/0x715
        page_fault+0x34/0x40
      
       1 lock held by systemd/1:
        #0: ffff897c38f14858 (&mm->mmap_sem#2){++++}-{3:3}, at: do_page_fault+0x143/0x715
       irq event stamp: 43530289
       count_memcg_event_mm+0x1a6/0x270
       count_memcg_event_mm+0x119/0x270
       __do_softirq+0x365/0x589
       irq_exit+0xa2/0xc0
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Marco Elver <elver@google.com>
      Cc: Hugh Dickins <hughd@google.com>
      Link: http://lkml.kernel.org/r/20200402213748.2237-1-cai@lca.pwSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8cc3afd5
    • Jeff Layton's avatar
      ceph: fix potential race in ceph_check_caps · c42c61e9
      Jeff Layton authored
      [ Upstream commit dc3da046 ]
      
      Nothing ensures that session will still be valid by the time we
      dereference the pointer. Take and put a reference.
      
      In principle, we should always be able to get a reference here, but
      throw a warning if that's ever not the case.
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c42c61e9
    • Dinghao Liu's avatar
      PCI: tegra: Fix runtime PM imbalance on error · 23c233c6
      Dinghao Liu authored
      [ Upstream commit fcee90cd ]
      
      pm_runtime_get_sync() increments the runtime PM usage counter even
      when it returns an error code. Thus a pairing decrement is needed on
      the error handling path to keep the counter balanced.
      
      Also, call pm_runtime_disable() when pm_runtime_get_sync() returns
      an error code.
      
      Link: https://lore.kernel.org/r/20200521024709.2368-1-dinghao.liu@zju.edu.cnSigned-off-by: default avatarDinghao Liu <dinghao.liu@zju.edu.cn>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      23c233c6
    • Dinghao Liu's avatar
      mtd: rawnand: omap_elm: Fix runtime PM imbalance on error · 2138dc84
      Dinghao Liu authored
      [ Upstream commit 37f72121 ]
      
      pm_runtime_get_sync() increments the runtime PM usage counter even
      when it returns an error code. Thus a pairing decrement is needed on
      the error handling path to keep the counter balanced.
      Signed-off-by: default avatarDinghao Liu <dinghao.liu@zju.edu.cn>
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Link: https://lore.kernel.org/linux-mtd/20200522104008.28340-1-dinghao.liu@zju.edu.cnSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      2138dc84
    • Dinghao Liu's avatar
      wlcore: fix runtime pm imbalance in wlcore_regdomain_config · 345d68b4
      Dinghao Liu authored
      [ Upstream commit 282a04bf ]
      
      pm_runtime_get_sync() increments the runtime PM usage counter even
      the call returns an error code. Thus a pairing decrement is needed
      on the error handling path to keep the counter balanced.
      Signed-off-by: default avatarDinghao Liu <dinghao.liu@zju.edu.cn>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20200520124649.10848-1-dinghao.liu@zju.edu.cnSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      345d68b4
    • Dinghao Liu's avatar
      wlcore: fix runtime pm imbalance in wl1271_tx_work · 3ad6b023
      Dinghao Liu authored
      [ Upstream commit 9604617e ]
      
      There are two error handling paths in this functon. When
      wlcore_tx_work_locked() returns an error code, we should
      decrease the runtime PM usage counter the same way as the
      error handling path beginning from pm_runtime_get_sync().
      Signed-off-by: default avatarDinghao Liu <dinghao.liu@zju.edu.cn>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20200520124241.9931-1-dinghao.liu@zju.edu.cnSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      3ad6b023
    • Dinghao Liu's avatar
      ASoC: img-i2s-out: Fix runtime PM imbalance on error · fce356af
      Dinghao Liu authored
      [ Upstream commit 65bd91dd ]
      
      pm_runtime_get_sync() increments the runtime PM usage counter even
      the call returns an error code. Thus a pairing decrement is needed
      on the error handling path to keep the counter balanced.
      Signed-off-by: default avatarDinghao Liu <dinghao.liu@zju.edu.cn>
      Link: https://lore.kernel.org/r/20200529012230.5863-1-dinghao.liu@zju.edu.cnSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fce356af