1. 07 Dec, 2020 1 commit
  2. 06 Dec, 2020 1 commit
  3. 03 Dec, 2020 1 commit
  4. 02 Dec, 2020 26 commits
    • LibXZR's avatar
      configs: zuk: Enable cpu_input_boost · adf52605
      LibXZR authored
      * Values will be set by boost_control in userspace
      adf52605
    • Sultanxda's avatar
      cpu_input_boost: Import from msm8996 kernel · 5b5d26dd
      Sultanxda authored
      
      
      Last commit: "cpu_input_boost: Prevent panics on init due to race conditions"
      Signed-off-by: default avatarSultanxda <sultanxda@gmail.com>
      5b5d26dd
    • Greg Kroah-Hartman's avatar
    • Filipe Manana's avatar
      btrfs: fix lockdep splat when reading qgroup config on mount · 04dd98b9
      Filipe Manana authored
      
      
      commit 3d05cad3c357a2b749912914356072b38435edfa upstream
      
      Lockdep reported the following splat when running test btrfs/190 from
      fstests:
      
        [ 9482.126098] ======================================================
        [ 9482.126184] WARNING: possible circular locking dependency detected
        [ 9482.126281] 5.10.0-rc4-btrfs-next-73 #1 Not tainted
        [ 9482.126365] ------------------------------------------------------
        [ 9482.126456] mount/24187 is trying to acquire lock:
        [ 9482.126534] ffffa0c869a7dac0 (&fs_info->qgroup_rescan_lock){+.+.}-{3:3}, at: qgroup_rescan_init+0x43/0xf0 [btrfs]
        [ 9482.126647]
      		 but task is already holding lock:
        [ 9482.126777] ffffa0c892ebd3a0 (btrfs-quota-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x120 [btrfs]
        [ 9482.126886]
      		 which lock already depends on the new lock.
      
        [ 9482.127078]
      		 the existing dependency chain (in reverse order) is:
        [ 9482.127213]
      		 -> #1 (btrfs-quota-00){++++}-{3:3}:
        [ 9482.127366]        lock_acquire+0xd8/0x490
        [ 9482.127436]        down_read_nested+0x45/0x220
        [ 9482.127528]        __btrfs_tree_read_lock+0x27/0x120 [btrfs]
        [ 9482.127613]        btrfs_read_lock_root_node+0x41/0x130 [btrfs]
        [ 9482.127702]        btrfs_search_slot+0x514/0xc30 [btrfs]
        [ 9482.127788]        update_qgroup_status_item+0x72/0x140 [btrfs]
        [ 9482.127877]        btrfs_qgroup_rescan_worker+0xde/0x680 [btrfs]
        [ 9482.127964]        btrfs_work_helper+0xf1/0x600 [btrfs]
        [ 9482.128039]        process_one_work+0x24e/0x5e0
        [ 9482.128110]        worker_thread+0x50/0x3b0
        [ 9482.128181]        kthread+0x153/0x170
        [ 9482.128256]        ret_from_fork+0x22/0x30
        [ 9482.128327]
      		 -> #0 (&fs_info->qgroup_rescan_lock){+.+.}-{3:3}:
        [ 9482.128464]        check_prev_add+0x91/0xc60
        [ 9482.128551]        __lock_acquire+0x1740/0x3110
        [ 9482.128623]        lock_acquire+0xd8/0x490
        [ 9482.130029]        __mutex_lock+0xa3/0xb30
        [ 9482.130590]        qgroup_rescan_init+0x43/0xf0 [btrfs]
        [ 9482.131577]        btrfs_read_qgroup_config+0x43a/0x550 [btrfs]
        [ 9482.132175]        open_ctree+0x1228/0x18a0 [btrfs]
        [ 9482.132756]        btrfs_mount_root.cold+0x13/0xed [btrfs]
        [ 9482.133325]        legacy_get_tree+0x30/0x60
        [ 9482.133866]        vfs_get_tree+0x28/0xe0
        [ 9482.134392]        fc_mount+0xe/0x40
        [ 9482.134908]        vfs_kern_mount.part.0+0x71/0x90
        [ 9482.135428]        btrfs_mount+0x13b/0x3e0 [btrfs]
        [ 9482.135942]        legacy_get_tree+0x30/0x60
        [ 9482.136444]        vfs_get_tree+0x28/0xe0
        [ 9482.136949]        path_mount+0x2d7/0xa70
        [ 9482.137438]        do_mount+0x75/0x90
        [ 9482.137923]        __x64_sys_mount+0x8e/0xd0
        [ 9482.138400]        do_syscall_64+0x33/0x80
        [ 9482.138873]        entry_SYSCALL_64_after_hwframe+0x44/0xa9
        [ 9482.139346]
      		 other info that might help us debug this:
      
        [ 9482.140735]  Possible unsafe locking scenario:
      
        [ 9482.141594]        CPU0                    CPU1
        [ 9482.142011]        ----                    ----
        [ 9482.142411]   lock(btrfs-quota-00);
        [ 9482.142806]                                lock(&fs_info->qgroup_rescan_lock);
        [ 9482.143216]                                lock(btrfs-quota-00);
        [ 9482.143629]   lock(&fs_info->qgroup_rescan_lock);
        [ 9482.144056]
      		  *** DEADLOCK ***
      
        [ 9482.145242] 2 locks held by mount/24187:
        [ 9482.145637]  #0: ffffa0c8411c40e8 (&type->s_umount_key#44/1){+.+.}-{3:3}, at: alloc_super+0xb9/0x400
        [ 9482.146061]  #1: ffffa0c892ebd3a0 (btrfs-quota-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x120 [btrfs]
        [ 9482.146509]
      		 stack backtrace:
        [ 9482.147350] CPU: 1 PID: 24187 Comm: mount Not tainted 5.10.0-rc4-btrfs-next-73 #1
        [ 9482.147788] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
        [ 9482.148709] Call Trace:
        [ 9482.149169]  dump_stack+0x8d/0xb5
        [ 9482.149628]  check_noncircular+0xff/0x110
        [ 9482.150090]  check_prev_add+0x91/0xc60
        [ 9482.150561]  ? kvm_clock_read+0x14/0x30
        [ 9482.151017]  ? kvm_sched_clock_read+0x5/0x10
        [ 9482.151470]  __lock_acquire+0x1740/0x3110
        [ 9482.151941]  ? __btrfs_tree_read_lock+0x27/0x120 [btrfs]
        [ 9482.152402]  lock_acquire+0xd8/0x490
        [ 9482.152887]  ? qgroup_rescan_init+0x43/0xf0 [btrfs]
        [ 9482.153354]  __mutex_lock+0xa3/0xb30
        [ 9482.153826]  ? qgroup_rescan_init+0x43/0xf0 [btrfs]
        [ 9482.154301]  ? qgroup_rescan_init+0x43/0xf0 [btrfs]
        [ 9482.154768]  ? qgroup_rescan_init+0x43/0xf0 [btrfs]
        [ 9482.155226]  qgroup_rescan_init+0x43/0xf0 [btrfs]
        [ 9482.155690]  btrfs_read_qgroup_config+0x43a/0x550 [btrfs]
        [ 9482.156160]  open_ctree+0x1228/0x18a0 [btrfs]
        [ 9482.156643]  btrfs_mount_root.cold+0x13/0xed [btrfs]
        [ 9482.157108]  ? rcu_read_lock_sched_held+0x5d/0x90
        [ 9482.157567]  ? kfree+0x31f/0x3e0
        [ 9482.158030]  legacy_get_tree+0x30/0x60
        [ 9482.158489]  vfs_get_tree+0x28/0xe0
        [ 9482.158947]  fc_mount+0xe/0x40
        [ 9482.159403]  vfs_kern_mount.part.0+0x71/0x90
        [ 9482.159875]  btrfs_mount+0x13b/0x3e0 [btrfs]
        [ 9482.160335]  ? rcu_read_lock_sched_held+0x5d/0x90
        [ 9482.160805]  ? kfree+0x31f/0x3e0
        [ 9482.161260]  ? legacy_get_tree+0x30/0x60
        [ 9482.161714]  legacy_get_tree+0x30/0x60
        [ 9482.162166]  vfs_get_tree+0x28/0xe0
        [ 9482.162616]  path_mount+0x2d7/0xa70
        [ 9482.163070]  do_mount+0x75/0x90
        [ 9482.163525]  __x64_sys_mount+0x8e/0xd0
        [ 9482.163986]  do_syscall_64+0x33/0x80
        [ 9482.164437]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
        [ 9482.164902] RIP: 0033:0x7f51e907caaa
      
      This happens because at btrfs_read_qgroup_config() we can call
      qgroup_rescan_init() while holding a read lock on a quota btree leaf,
      acquired by the previous call to btrfs_search_slot_for_read(), and
      qgroup_rescan_init() acquires the mutex qgroup_rescan_lock.
      
      A qgroup rescan worker does the opposite: it acquires the mutex
      qgroup_rescan_lock, at btrfs_qgroup_rescan_worker(), and then tries to
      update the qgroup status item in the quota btree through the call to
      update_qgroup_status_item(). This inversion of locking order
      between the qgroup_rescan_lock mutex and quota btree locks causes the
      splat.
      
      Fix this simply by releasing and freeing the path before calling
      qgroup_rescan_init() at btrfs_read_qgroup_config().
      
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      [sudip: adjust context]
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04dd98b9
    • Alan Stern's avatar
      USB: core: Fix regression in Hercules audio card · 0c2e89d4
      Alan Stern authored
      
      
      commit 184eead057cc7e803558269babc1f2cfb9113ad1 upstream
      
      Commit 3e4f8e21c4f2 ("USB: core: fix check for duplicate endpoints")
      aimed to make the USB stack more reliable by detecting and skipping
      over endpoints that are duplicated between interfaces.  This caused a
      regression for a Hercules audio card (reported as Bugzilla #208357),
      which contains such non-compliant duplications.  Although the
      duplications are harmless, skipping the valid endpoints prevented the
      device from working.
      
      This patch fixes the regression by adding ENDPOINT_IGNORE quirks for
      the Hercules card, telling the kernel to ignore the invalid duplicate
      endpoints and thereby allowing the valid endpoints to be used as
      intended.
      
      Fixes: 3e4f8e21c4f2 ("USB: core: fix check for duplicate endpoints")
      CC: <stable@vger.kernel.org>
      Reported-by: default avatarAlexander Chalikiopoulos <bugzilla.kernel.org@mrtoasted.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Link: https://lore.kernel.org/r/20201119170040.GA576844@rowland.harvard.edu
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [sudip: use usb_endpoint_blacklist and USB_QUIRK_ENDPOINT_BLACKLIST]
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c2e89d4
    • Johan Hovold's avatar
      USB: core: add endpoint-blacklist quirk · d3fa1c6a
      Johan Hovold authored
      
      
      commit 73f8bda9b5dc1c69df2bc55c0cbb24461a6391a9 upstream
      
      Add a new device quirk that can be used to blacklist endpoints.
      
      Since commit 3e4f8e21c4f2 ("USB: core: fix check for duplicate
      endpoints") USB core ignores any duplicate endpoints found during
      descriptor parsing.
      
      In order to handle devices where the first interfaces with duplicate
      endpoints are the ones that should have their endpoints ignored, we need
      to add a blacklist.
      Tested-by: default avataredes <edes@gmx.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20200203153830.26394-2-johan@kernel.org
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [sudip: adjust context]
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3fa1c6a
    • Anand K Mistry's avatar
      x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb · f8e2877d
      Anand K Mistry authored
      
      
      commit 33fc379df76b4991e5ae312f07bcd6820811971e upstream.
      
      When spectre_v2_user={seccomp,prctl},ibpb is specified on the command
      line, IBPB is force-enabled and STIPB is conditionally-enabled (or not
      available).
      
      However, since
      
        21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
      
      the spectre_v2_user_ibpb variable is set to SPECTRE_V2_USER_{PRCTL,SECCOMP}
      instead of SPECTRE_V2_USER_STRICT, which is the actual behaviour.
      Because the issuing of IBPB relies on the switch_mm_*_ibpb static
      branches, the mitigations behave as expected.
      
      Since
      
        1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP")
      
      this discrepency caused the misreporting of IB speculation via prctl().
      
      On CPUs with STIBP always-on and spectre_v2_user=seccomp,ibpb,
      prctl(PR_GET_SPECULATION_CTRL) would return PR_SPEC_PRCTL |
      PR_SPEC_ENABLE instead of PR_SPEC_DISABLE since both IBPB and STIPB are
      always on. It also allowed prctl(PR_SET_SPECULATION_CTRL) to set the IB
      speculation mode, even though the flag is ignored.
      
      Similarly, for CPUs without SMT, prctl(PR_GET_SPECULATION_CTRL) should
      also return PR_SPEC_DISABLE since IBPB is always on and STIBP is not
      available.
      
       [ bp: Massage commit message. ]
      
      Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
      Fixes: 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP")
      Signed-off-by: default avatarAnand K Mistry <amistry@google.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20201110123349.1.Id0cbf996d2151f4c143c90f9028651a5b49a5908@changeid
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8e2877d
    • Alan Stern's avatar
      USB: core: Change %pK for __user pointers to %px · 3040d2ef
      Alan Stern authored
      
      
      commit f3bc432aa8a7a2bfe9ebb432502be5c5d979d7fe upstream.
      
      Commit 2f964780c03b ("USB: core: replace %p with %pK") used the %pK
      format specifier for a bunch of __user pointers.  But as the 'K' in
      the specifier indicates, it is meant for kernel pointers.  The reason
      for the %pK specifier is to avoid leaks of kernel addresses, but when
      the pointer is to an address in userspace the security implications
      are minimal.  In particular, no kernel information is leaked.
      
      This patch changes the __user %pK specifiers (used in a bunch of
      debugging output lines) to %px, which will always print the actual
      address with no mangling.  (Notably, there is no printk format
      specifier particularly intended for __user pointers.)
      
      Fixes: 2f964780c03b ("USB: core: replace %p with %pK")
      CC: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Link: https://lore.kernel.org/r/20201119170228.GB576844@rowland.harvard.edu
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3040d2ef
    • Masami Hiramatsu's avatar
      perf probe: Fix to die_entrypc() returns error correctly · 9cb16919
      Masami Hiramatsu authored
      
      
      [ Upstream commit ab4200c17ba6fe71d2da64317aae8a8aa684624c ]
      
      Fix die_entrypc() to return error correctly if the DIE has no
      DW_AT_ranges attribute. Since dwarf_ranges() will treat the case as an
      empty ranges and return 0, we have to check it by ourselves.
      
      Fixes: 91e2f539eeda ("perf probe: Fix to show function entry line as probe-able")
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Sumanth Korikkar <sumanthk@linux.ibm.com>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Link: http://lore.kernel.org/lkml/160645612634.2824037.5284932731175079426.stgit@devnote2
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9cb16919
    • Ard Biesheuvel's avatar
      efivarfs: revert "fix memory leak in efivarfs_create()" · bc819d48
      Ard Biesheuvel authored
      
      
      [ Upstream commit ff04f3b6f2e27f8ae28a498416af2a8dd5072b43 ]
      
      The memory leak addressed by commit fe5186cf12e3 is a false positive:
      all allocations are recorded in a linked list, and freed when the
      filesystem is unmounted. This leads to double frees, and as reported
      by David, leads to crashes if SLUB is configured to self destruct when
      double frees occur.
      
      So drop the redundant kfree() again, and instead, mark the offending
      pointer variable so the allocation is ignored by kmemleak.
      
      Cc: Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com>
      Fixes: fe5186cf12e3 ("efivarfs: fix memory leak in efivarfs_create()")
      Reported-by: default avatarDavid Laight <David.Laight@aculab.com>
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bc819d48
    • Krzysztof Kozlowski's avatar
      nfc: s3fwrn5: use signed integer for parsing GPIO numbers · 4ed8629d
      Krzysztof Kozlowski authored
      [ Upstream commit d8f0a86795c69f5b697f7d9e5274c124da93c92d ]
      
      GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
      signed integers, where negative number indicates error.  The return
      value of of_get_named_gpio() should not be assigned to an unsigned int
      because in case of !CONFIG_GPIOLIB such number would be a valid GPIO.
      
      Fixes: c04c674f
      
       ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip")
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Link: https://lore.kernel.org/r/20201123162351.209100-1-krzk@kernel.org
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4ed8629d
    • Xiongfeng Wang's avatar
      IB/mthca: fix return value of error branch in mthca_init_cq() · 4116df21
      Xiongfeng Wang authored
      [ Upstream commit 6830ff853a5764c75e56750d59d0bbb6b26f1835 ]
      
      We return 'err' in the error branch, but this variable may be set as zero
      by the above code. Fix it by setting 'err' as a negative value before we
      goto the error label.
      
      Fixes: 74c2174e ("IB uverbs: add mthca user CQ support")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Link: https://lore.kernel.org/r/1605837422-42724-1-git-send-email-wangxiongfeng2@huawei.com
      
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4116df21
    • Michael Chan's avatar
      bnxt_en: Release PCI regions when DMA mask setup fails during probe. · fb638709
      Michael Chan authored
      [ Upstream commit c54bc3ced5106663c2f2b44071800621f505b00e ]
      
      Jump to init_err_release to cleanup.  bnxt_unmap_bars() will also be
      called but it will do nothing if the BARs are not mapped yet.
      
      Fixes: c0c050c5
      
       ("bnxt_en: New Broadcom ethernet driver.")
      Reported-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Link: https://lore.kernel.org/r/1605858271-8209-1-git-send-email-michael.chan@broadcom.com
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fb638709
    • Dexuan Cui's avatar
      video: hyperv_fb: Fix the cache type when mapping the VRAM · 85db97cf
      Dexuan Cui authored
      [ Upstream commit 5f1251a48c17b54939d7477305e39679a565382c ]
      
      x86 Hyper-V used to essentially always overwrite the effective cache type
      of guest memory accesses to WB. This was problematic in cases where there
      is a physical device assigned to the VM, since that often requires that
      the VM should have control over cache types. Thus, on newer Hyper-V since
      2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
      users start to complain that Linux VM's VRAM becomes very slow, and it
      turns out that Linux VM should not map the VRAM uncacheable by ioremap().
      Fix this slowness issue by using ioremap_cache().
      
      On ARM64, ioremap_cache() is also required as the host also maps the VRAM
      cacheable, otherwise VM Connect can't display properly with ioremap() or
      ioremap_wc().
      
      With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
      it's no longer necessary to use the hacks we added to mitigate the
      slowness, i.e. we no longer need to allocate physical memory and use
      it to back up the VRAM in Generation-1 VM, and we also no longer need to
      allocate physical memory to back up the framebuffer in a Generation-2 VM
      and copy the framebuffer to the real VRAM. A further big change will
      address these for v5.11.
      
      Fixes: 68a2d20b
      
       ("drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver")
      Tested-by: default avatarBoqun Feng <boqun.feng@gmail.com>
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Reviewed-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Reviewed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Link: https://lore.kernel.org/r/20201118000305.24797-1-decui@microsoft.com
      
      Signed-off-by: default avatarWei Liu <wei.liu@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      85db97cf
    • Zhang Changzhong's avatar
      bnxt_en: fix error return code in bnxt_init_board() · 1ca5fcf5
      Zhang Changzhong authored
      [ Upstream commit 3383176efc0fb0c0900a191026468a58668b4214 ]
      
      Fix to return a negative error code from the error handling
      case instead of 0, as done elsewhere in this function.
      
      Fixes: c0c050c5
      
       ("bnxt_en: New Broadcom ethernet driver.")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
      Reviewed-by: default avatarEdwin Peer <edwin.peer@broadcom.com>
      Link: https://lore.kernel.org/r/1605792621-6268-1-git-send-email-zhangchangzhong@huawei.com
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1ca5fcf5
    • Stanley Chu's avatar
      scsi: ufs: Fix race between shutdown and runtime resume flow · 081500a2
      Stanley Chu authored
      [ Upstream commit e92643db514803c2c87d72caf5950b4c0a8faf4a ]
      
      If UFS host device is in runtime-suspended state while UFS shutdown
      callback is invoked, UFS device shall be resumed for register
      accesses. Currently only UFS local runtime resume function will be invoked
      to wake up the host.  This is not enough because if someone triggers
      runtime resume from block layer, then race may happen between shutdown and
      runtime resume flow, and finally lead to unlocked register access.
      
      To fix this, in ufshcd_shutdown(), use pm_runtime_get_sync() instead of
      resuming UFS device by ufshcd_runtime_resume() "internally" to let runtime
      PM framework manage the whole resume flow.
      
      Link: https://lore.kernel.org/r/20201119062916.12931-1-stanley.chu@mediatek.com
      Fixes: 57d104c1
      
       ("ufs: add UFS power management support")
      Reviewed-by: default avatarCan Guo <cang@codeaurora.org>
      Signed-off-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      081500a2
    • Mike Christie's avatar
      scsi: target: iscsi: Fix cmd abort fabric stop race · d89606ea
      Mike Christie authored
      [ Upstream commit f36199355c64a39fe82cfddc7623d827c7e050da ]
      
      Maurizio found a race where the abort and cmd stop paths can race as
      follows:
      
       1. thread1 runs iscsit_release_commands_from_conn and sets
          CMD_T_FABRIC_STOP.
      
       2. thread2 runs iscsit_aborted_task and then does __iscsit_free_cmd. It
          then returns from the aborted_task callout and we finish
          target_handle_abort and do:
      
          target_handle_abort -> transport_cmd_check_stop_to_fabric ->
      	lio_check_stop_free -> target_put_sess_cmd
      
          The cmd is now freed.
      
       3. thread1 now finishes iscsit_release_commands_from_conn and runs
          iscsit_free_cmd while accessing a command we just released.
      
      In __target_check_io_state we check for CMD_T_FABRIC_STOP and set the
      CMD_T_ABORTED if the driver is not cleaning up the cmd because of a session
      shutdown. However, iscsit_release_commands_from_conn only sets the
      CMD_T_FABRIC_STOP and does not check to see if the abort path has claimed
      completion ownership of the command.
      
      This adds a check in iscsit_release_commands_from_conn so only the abort or
      fabric stop path cleanup the command.
      
      Link: https://lore.kernel.org/r/1605318378-9269-1-git-send-email-michael.christie@oracle.com
      
      Reported-by: default avatarMaurizio Lombardi <mlombard@redhat.com>
      Reviewed-by: default avatarMaurizio Lombardi <mlombard@redhat.com>
      Signed-off-by: default avatarMike Christie <michael.christie@oracle.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d89606ea
    • Lee Duncan's avatar
      scsi: libiscsi: Fix NOP race condition · dd069602
      Lee Duncan authored
      [ Upstream commit fe0a8a95e7134d0b44cd407bc0085b9ba8d8fe31 ]
      
      iSCSI NOPs are sometimes "lost", mistakenly sent to the user-land iscsid
      daemon instead of handled in the kernel, as they should be, resulting in a
      message from the daemon like:
      
        iscsid: Got nop in, but kernel supports nop handling.
      
      This can occur because of the new forward- and back-locks, and the fact
      that an iSCSI NOP response can occur before processing of the NOP send is
      complete. This can result in "conn->ping_task" being NULL in
      iscsi_nop_out_rsp(), when the pointer is actually in the process of being
      set.
      
      To work around this, we add a new state to the "ping_task" pointer. In
      addition to NULL (not assigned) and a pointer (assigned), we add the state
      "being set", which is signaled with an INVALID pointer (using "-1").
      
      Link: https://lore.kernel.org/r/20201106193317.16993-1-leeman.duncan@gmail.com
      
      Reviewed-by: default avatarMike Christie <michael.christie@oracle.com>
      Signed-off-by: default avatarLee Duncan <lduncan@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dd069602
    • Sugar Zhang's avatar
      dmaengine: pl330: _prep_dma_memcpy: Fix wrong burst size · 94920347
      Sugar Zhang authored
      
      
      [ Upstream commit e773ca7da8beeca7f17fe4c9d1284a2b66839cc1 ]
      
      Actually, burst size is equal to '1 << desc->rqcfg.brst_size'.
      we should use burst size, not desc->rqcfg.brst_size.
      
      dma memcpy performance on Rockchip RV1126
      @ 1512MHz A7, 1056MHz LPDDR3, 200MHz DMA:
      
      dmatest:
      
      /# echo dma0chan0 > /sys/module/dmatest/parameters/channel
      /# echo 4194304 > /sys/module/dmatest/parameters/test_buf_size
      /# echo 8 > /sys/module/dmatest/parameters/iterations
      /# echo y > /sys/module/dmatest/parameters/norandom
      /# echo y > /sys/module/dmatest/parameters/verbose
      /# echo 1 > /sys/module/dmatest/parameters/run
      
      dmatest: dma0chan0-copy0: result #1: 'test passed' with src_off=0x0 dst_off=0x0 len=0x400000
      dmatest: dma0chan0-copy0: result #2: 'test passed' with src_off=0x0 dst_off=0x0 len=0x400000
      dmatest: dma0chan0-copy0: result #3: 'test passed' with src_off=0x0 dst_off=0x0 len=0x400000
      dmatest: dma0chan0-copy0: result #4: 'test passed' with src_off=0x0 dst_off=0x0 len=0x400000
      dmatest: dma0chan0-copy0: result #5: 'test passed' with src_off=0x0 dst_off=0x0 len=0x400000
      dmatest: dma0chan0-copy0: result #6: 'test passed' with src_off=0x0 dst_off=0x0 len=0x400000
      dmatest: dma0chan0-copy0: result #7: 'test passed' with src_off=0x0 dst_off=0x0 len=0x400000
      dmatest: dma0chan0-copy0: result #8: 'test passed' with src_off=0x0 dst_off=0x0 len=0x400000
      
      Before:
      
        dmatest: dma0chan0-copy0: summary 8 tests, 0 failures 48 iops 200338 KB/s (0)
      
      After this patch:
      
        dmatest: dma0chan0-copy0: summary 8 tests, 0 failures 179 iops 734873 KB/s (0)
      
      After this patch and increase dma clk to 400MHz:
      
        dmatest: dma0chan0-copy0: summary 8 tests, 0 failures 259 iops 1062929 KB/s (0)
      Signed-off-by: default avatarSugar Zhang <sugar.zhang@rock-chips.com>
      Link: https://lore.kernel.org/r/1605326106-55681-1-git-send-email-sugar.zhang@rock-chips.com
      
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      94920347
    • Jens Axboe's avatar
      proc: don't allow async path resolution of /proc/self components · ebb83fd9
      Jens Axboe authored
      
      
      [ Upstream commit 8d4c3e76e3be11a64df95ddee52e99092d42fc19 ]
      
      If this is attempted by a kthread, then return -EOPNOTSUPP as we don't
      currently support that. Once we can get task_pid_ptr() doing the right
      thing, then this can go away again.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ebb83fd9
    • Brian Masney's avatar
      x86/xen: don't unbind uninitialized lock_kicker_irq · 22aaeaee
      Brian Masney authored
      
      
      [ Upstream commit 65cae18882f943215d0505ddc7e70495877308e6 ]
      
      When booting a hyperthreaded system with the kernel parameter
      'mitigations=auto,nosmt', the following warning occurs:
      
          WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112 unbind_from_irqhandler+0x4e/0x60
          ...
          Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006
          ...
          Call Trace:
           xen_uninit_lock_cpu+0x28/0x62
           xen_hvm_cpu_die+0x21/0x30
           takedown_cpu+0x9c/0xe0
           ? trace_suspend_resume+0x60/0x60
           cpuhp_invoke_callback+0x9a/0x530
           _cpu_up+0x11a/0x130
           cpu_up+0x7e/0xc0
           bringup_nonboot_cpus+0x48/0x50
           smp_init+0x26/0x79
           kernel_init_freeable+0xea/0x229
           ? rest_init+0xaa/0xaa
           kernel_init+0xa/0x106
           ret_from_fork+0x35/0x40
      
      The secondary CPUs are not activated with the nosmt mitigations and only
      the primary thread on each CPU core is used. In this situation,
      xen_hvm_smp_prepare_cpus(), and more importantly xen_init_lock_cpu(), is
      not called, so the lock_kicker_irq is not initialized for the secondary
      CPUs. Let's fix this by exiting early in xen_uninit_lock_cpu() if the
      irq is not set to avoid the warning from above for each secondary CPU.
      Signed-off-by: default avatarBrian Masney <bmasney@redhat.com>
      Link: https://lore.kernel.org/r/20201107011119.631442-1-bmasney@redhat.com
      
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      22aaeaee
    • Pablo Ceballos's avatar
      HID: hid-sensor-hub: Fix issue with devices with no report ID · 9ef5ed79
      Pablo Ceballos authored
      
      
      [ Upstream commit 34a9fa2025d9d3177c99351c7aaf256c5f50691f ]
      
      Some HID devices don't use a report ID because they only have a single
      report. In those cases, the report ID in struct hid_report will be zero
      and the data for the report will start at the first byte, so don't skip
      over the first byte.
      Signed-off-by: default avatarPablo Ceballos <pceballos@google.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9ef5ed79
    • Hans de Goede's avatar
      Input: i8042 - allow insmod to succeed on devices without an i8042 controller · b550fecd
      Hans de Goede authored
      
      
      [ Upstream commit b1884583fcd17d6a1b1bba94bbb5826e6b5c6e17 ]
      
      The i8042 module exports several symbols which may be used by other
      modules.
      
      Before this commit it would refuse to load (when built as a module itself)
      on systems without an i8042 controller.
      
      This is a problem specifically for the asus-nb-wmi module. Many Asus
      laptops support the Asus WMI interface. Some of them have an i8042
      controller and need to use i8042_install_filter() to filter some kbd
      events. Other models do not have an i8042 controller (e.g. they use an
      USB attached kbd).
      
      Before this commit the asus-nb-wmi driver could not be loaded on Asus
      models without an i8042 controller, when the i8042 code was built as
      a module (as Arch Linux does) because the module_init function of the
      i8042 module would fail with -ENODEV and thus the i8042_install_filter
      symbol could not be loaded.
      
      This commit fixes this by exiting from module_init with a return code
      of 0 if no controller is found.  It also adds a i8042_present bool to
      make the module_exit function a no-op in this case and also adds a
      check for i8042_present to the exported i8042_command function.
      
      The latter i8042_present check should not really be necessary because
      when builtin that function can already be used on systems without
      an i8042 controller, but better safe then sorry.
      Reported-and-tested-by: default avatarMarius Iacob <themariusus@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20201008112628.3979-2-hdegoede@redhat.com
      
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b550fecd
    • Frank Yang's avatar
      HID: cypress: Support Varmilo Keyboards' media hotkeys · cb950f6c
      Frank Yang authored
      
      
      [ Upstream commit 652f3d00de523a17b0cebe7b90debccf13aa8c31 ]
      
      The Varmilo VA104M Keyboard (04b4:07b1, reported as Varmilo Z104M)
      exposes media control hotkeys as a USB HID consumer control device, but
      these keys do not work in the current (5.8-rc1) kernel due to the
      incorrect HID report descriptor. Fix the problem by modifying the
      internal HID report descriptor.
      
      More specifically, the keyboard report descriptor specifies the
      logical boundary as 572~10754 (0x023c ~ 0x2a02) while the usage
      boundary is specified as 0~10754 (0x00 ~ 0x2a02). This results in an
      incorrect interpretation of input reports, causing inputs to be ignored.
      By setting the Logical Minimum to zero, we align the logical boundary
      with the Usage ID boundary.
      
      Some notes:
      
      * There seem to be multiple variants of the VA104M keyboard. This
        patch specifically targets 04b4:07b1 variant.
      
      * The device works out-of-the-box on Windows platform with the generic
        consumer control device driver (hidserv.inf). This suggests that
        Windows either ignores the Logical Minimum/Logical Maximum or
        interprets the Usage ID assignment differently from the linux
        implementation; Maybe there are other devices out there that only
        works on Windows due to this problem?
      Signed-off-by: default avatarFrank Yang <puilp0502@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cb950f6c
    • Qu Wenruo's avatar
      btrfs: inode: Verify inode mode to avoid NULL pointer dereference · d4d0b4f9
      Qu Wenruo authored
      
      
      commit 6bf9e4bd6a277840d3fe8c5d5d530a1fbd3db592 upstream
      
      [BUG]
      When accessing a file on a crafted image, btrfs can crash in block layer:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
        PGD 136501067 P4D 136501067 PUD 124519067 PMD 0
        CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.0.0-rc8-default #252
        RIP: 0010:end_bio_extent_readpage+0x144/0x700
        Call Trace:
         <IRQ>
         blk_update_request+0x8f/0x350
         blk_mq_end_request+0x1a/0x120
         blk_done_softirq+0x99/0xc0
         __do_softirq+0xc7/0x467
         irq_exit+0xd1/0xe0
         call_function_single_interrupt+0xf/0x20
         </IRQ>
        RIP: 0010:default_idle+0x1e/0x170
      
      [CAUSE]
      The crafted image has a tricky corruption, the INODE_ITEM has a
      different type against its parent dir:
      
              item 20 key (268 INODE_ITEM 0) itemoff 2808 itemsize 160
                      generation 13 transid 13 size 1048576 nbytes 1048576
                      block group 0 mode 121644 links 1 uid 0 gid 0 rdev 0
                      sequence 9 flags 0x0(none)
      
      This mode number 0120000 means it's a symlink.
      
      But the dir item think it's still a regular file:
      
              item 8 key (264 DIR_INDEX 5) itemoff 3707 itemsize 32
                      location key (268 INODE_ITEM 0) type FILE
                      transid 13 data_len 0 name_len 2
                      name: f4
              item 40 key (264 DIR_ITEM 51821248) itemoff 1573 itemsize 32
                      location key (268 INODE_ITEM 0) type FILE
                      transid 13 data_len 0 name_len 2
                      name: f4
      
      For symlink, we don't set BTRFS_I(inode)->io_tree.ops and leave it
      empty, as symlink is only designed to have inlined extent, all handled
      by tree block read.  Thus no need to trigger btrfs_submit_bio_hook() for
      inline file extent.
      
      However end_bio_extent_readpage() expects tree->ops populated, as it's
      reading regular data extent.  This causes NULL pointer dereference.
      
      [FIX]
      This patch fixes the problem in two ways:
      
      - Verify inode mode against its dir item when looking up inode
        So in btrfs_lookup_dentry() if we find inode mode mismatch with dir
        item, we error out so that corrupted inode will not be accessed.
      
      - Verify inode mode when getting extent mapping
        Only regular file should have regular or preallocated extent.
        If we found regular/preallocated file extent for symlink or
        the rest, we error out before submitting the read bio.
      
      With this fix that crafted image can be rejected gracefully:
      
        BTRFS critical (device loop0): inode mode mismatch with dir: inode mode=0121644 btrfs type=7 dir type=1
      Reported-by: default avatarYoon Jungyeon <jungyeon@gatech.edu>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=202763
      
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      [sudip: use original btrfs_inode_type(), btrfs_crit with root->fs_info,
      ISREG with inode->i_mode and adjust context]
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d4d0b4f9
    • Qu Wenruo's avatar
      btrfs: tree-checker: Enhance chunk checker to validate chunk profile · fd915013
      Qu Wenruo authored
      
      
      commit 80e46cf22ba0bcb57b39c7c3b52961ab3a0fd5f2 upstream
      
      Btrfs-progs already have a comprehensive type checker, to ensure there
      is only 0 (SINGLE profile) or 1 (DUP/RAID0/1/5/6/10) bit set for chunk
      profile bits.
      
      Do the same work for kernel.
      Reported-by: default avatarYoon Jungyeon <jungyeon@gatech.edu>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=202765
      
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      [sudip: manually backport, use btrfs_err with root->fs_info]
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd915013
  5. 25 Nov, 2020 1 commit
  6. 24 Nov, 2020 10 commits