1. 01 Oct, 2020 40 commits
    • Qian Cai's avatar
      mm/vmscan.c: fix data races using kswapd_classzone_idx · b73c7440
      Qian Cai authored
      [ Upstream commit 5644e1fb ]
      
      pgdat->kswapd_classzone_idx could be accessed concurrently in
      wakeup_kswapd().  Plain writes and reads without any lock protection
      result in data races.  Fix them by adding a pair of READ|WRITE_ONCE() as
      well as saving a branch (compilers might well optimize the original code
      in an unintentional way anyway).  While at it, also take care of
      pgdat->kswapd_order and non-kswapd threads in allow_direct_reclaim().  The
      data races were reported by KCSAN,
      
       BUG: KCSAN: data-race in wakeup_kswapd / wakeup_kswapd
      
       write to 0xffff9f427ffff2dc of 4 bytes by task 7454 on cpu 13:
        wakeup_kswapd+0xf1/0x400
        wakeup_kswapd at mm/vmscan.c:3967
        wake_all_kswapds+0x59/0xc0
        wake_all_kswapds at mm/page_alloc.c:4241
        __alloc_pages_slowpath+0xdcc/0x1290
        __alloc_pages_slowpath at mm/page_alloc.c:4512
        __alloc_pages_nodemask+0x3bb/0x450
        alloc_pages_vma+0x8a/0x2c0
        do_anonymous_page+0x16e/0x6f0
        __handle_mm_fault+0xcd5/0xd40
        handle_mm_fault+0xfc/0x2f0
        do_page_fault+0x263/0x6f9
        page_fault+0x34/0x40
      
       1 lock held by mtest01/7454:
        #0: ffff9f425afe8808 (&mm->mmap_sem#2){++++}, at:
       do_page_fault+0x143/0x6f9
       do_user_addr_fault at arch/x86/mm/fault.c:1405
       (inlined by) do_page_fault at arch/x86/mm/fault.c:1539
       irq event stamp: 6944085
       count_memcg_event_mm+0x1a6/0x270
       count_memcg_event_mm+0x119/0x270
       __do_softirq+0x34c/0x57c
       irq_exit+0xa2/0xc0
      
       read to 0xffff9f427ffff2dc of 4 bytes by task 7472 on cpu 38:
        wakeup_kswapd+0xc8/0x400
        wake_all_kswapds+0x59/0xc0
        __alloc_pages_slowpath+0xdcc/0x1290
        __alloc_pages_nodemask+0x3bb/0x450
        alloc_pages_vma+0x8a/0x2c0
        do_anonymous_page+0x16e/0x6f0
        __handle_mm_fault+0xcd5/0xd40
        handle_mm_fault+0xfc/0x2f0
        do_page_fault+0x263/0x6f9
        page_fault+0x34/0x40
      
       1 lock held by mtest01/7472:
        #0: ffff9f425a9ac148 (&mm->mmap_sem#2){++++}, at:
       do_page_fault+0x143/0x6f9
       irq event stamp: 6793561
       count_memcg_event_mm+0x1a6/0x270
       count_memcg_event_mm+0x119/0x270
       __do_softirq+0x34c/0x57c
       irq_exit+0xa2/0xc0
      
       BUG: KCSAN: data-race in kswapd / wakeup_kswapd
      
       write to 0xffff90973ffff2dc of 4 bytes by task 820 on cpu 6:
        kswapd+0x27c/0x8d0
        kthread+0x1e0/0x200
        ret_from_fork+0x27/0x50
      
       read to 0xffff90973ffff2dc of 4 bytes by task 6299 on cpu 0:
        wakeup_kswapd+0xf3/0x450
        wake_all_kswapds+0x59/0xc0
        __alloc_pages_slowpath+0xdcc/0x1290
        __alloc_pages_nodemask+0x3bb/0x450
        alloc_pages_vma+0x8a/0x2c0
        do_anonymous_page+0x170/0x700
        __handle_mm_fault+0xc9f/0xd00
        handle_mm_fault+0xfc/0x2f0
        do_page_fault+0x263/0x6f9
        page_fault+0x34/0x40
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Marco Elver <elver@google.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Link: http://lkml.kernel.org/r/1582749472-5171-1-git-send-email-cai@lca.pwSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b73c7440
    • Xianting Tian's avatar
      mm/filemap.c: clear page error before actual read · cebefe4f
      Xianting Tian authored
      [ Upstream commit faffdfa0 ]
      
      Mount failure issue happens under the scenario: Application forked dozens
      of threads to mount the same number of cramfs images separately in docker,
      but several mounts failed with high probability.  Mount failed due to the
      checking result of the page(read from the superblock of loop dev) is not
      uptodate after wait_on_page_locked(page) returned in function cramfs_read:
      
         wait_on_page_locked(page);
         if (!PageUptodate(page)) {
            ...
         }
      
      The reason of the checking result of the page not uptodate: systemd-udevd
      read the loopX dev before mount, because the status of loopX is Lo_unbound
      at this time, so loop_make_request directly trigger the calling of io_end
      handler end_buffer_async_read, which called SetPageError(page).  So It
      caused the page can't be set to uptodate in function
      end_buffer_async_read:
      
         if(page_uptodate && !PageError(page)) {
            SetPageUptodate(page);
         }
      
      Then mount operation is performed, it used the same page which is just
      accessed by systemd-udevd above, Because this page is not uptodate, it
      will launch a actual read via submit_bh, then wait on this page by calling
      wait_on_page_locked(page).  When the I/O of the page done, io_end handler
      end_buffer_async_read is called, because no one cleared the page
      error(during the whole read path of mount), which is caused by
      systemd-udevd reading, so this page is still in "PageError" status, which
      can't be set to uptodate in function end_buffer_async_read, then caused
      mount failure.
      
      But sometimes mount succeed even through systemd-udeved read loopX dev
      just before, The reason is systemd-udevd launched other loopX read just
      between step 3.1 and 3.2, the steps as below:
      
      1, loopX dev default status is Lo_unbound;
      2, systemd-udved read loopX dev (page is set to PageError);
      3, mount operation
         1) set loopX status to Lo_bound;
         ==>systemd-udevd read loopX dev<==
         2) read loopX dev(page has no error)
         3) mount succeed
      
      As the loopX dev status is set to Lo_bound after step 3.1, so the other
      loopX dev read by systemd-udevd will go through the whole I/O stack, part
      of the call trace as below:
      
         SYS_read
            vfs_read
                do_sync_read
                    blkdev_aio_read
                       generic_file_aio_read
                           do_generic_file_read:
                              ClearPageError(page);
                              mapping->a_ops->readpage(filp, page);
      
      here, mapping->a_ops->readpage() is blkdev_readpage.  In latest kernel,
      some function name changed, the call trace as below:
      
         blkdev_read_iter
            generic_file_read_iter
               generic_file_buffered_read:
                  /*
                   * A previous I/O error may have been due to temporary
                   * failures, eg. mutipath errors.
                   * Pg_error will be set again if readpage fails.
                   */
                  ClearPageError(page);
                  /* Start the actual read. The read will unlock the page*/
                  error=mapping->a_ops->readpage(flip, page);
      
      We can see ClearPageError(page) is called before the actual read,
      then the read in step 3.2 succeed.
      
      This patch is to add the calling of ClearPageError just before the actual
      read of read path of cramfs mount.  Without the patch, the call trace as
      below when performing cramfs mount:
      
         do_mount
            cramfs_read
               cramfs_blkdev_read
                  read_cache_page
                     do_read_cache_page:
                        filler(data, page);
                        or
                        mapping->a_ops->readpage(data, page);
      
      With the patch, the call trace as below when performing mount:
      
         do_mount
            cramfs_read
               cramfs_blkdev_read
                  read_cache_page:
                     do_read_cache_page:
                        ClearPageError(page); <== new add
                        filler(data, page);
                        or
                        mapping->a_ops->readpage(data, page);
      
      With the patch, mount operation trigger the calling of
      ClearPageError(page) before the actual read, the page has no error if no
      additional page error happen when I/O done.
      Signed-off-by: default avatarXianting Tian <xianting_tian@126.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: default avatarMatthew Wilcox (Oracle) <willy@infradead.org>
      Cc: Jan Kara <jack@suse.cz>
      Cc: <yubin@h3c.com>
      Link: http://lkml.kernel.org/r/1583318844-22971-1-git-send-email-xianting_tian@126.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cebefe4f
    • Nathan Chancellor's avatar
      mm/kmemleak.c: use address-of operator on section symbols · afe00148
      Nathan Chancellor authored
      [ Upstream commit b0d14fc4 ]
      
      Clang warns:
      
        mm/kmemleak.c:1955:28: warning: array comparison always evaluates to a constant [-Wtautological-compare]
              if (__start_ro_after_init < _sdata || __end_ro_after_init > _edata)
                                        ^
        mm/kmemleak.c:1955:60: warning: array comparison always evaluates to a constant [-Wtautological-compare]
              if (__start_ro_after_init < _sdata || __end_ro_after_init > _edata)
      
      These are not true arrays, they are linker defined symbols, which are just
      addresses.  Using the address of operator silences the warning and does
      not change the resulting assembly with either clang/ld.lld or gcc/ld
      (tested with diff + objdump -Dr).
      Suggested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Link: https://github.com/ClangBuiltLinux/linux/issues/895
      Link: http://lkml.kernel.org/r/20200220051551.44000-1-natechancellor@gmail.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      afe00148
    • Trond Myklebust's avatar
      NFS: Fix races nfs_page_group_destroy() vs nfs_destroy_unlinked_subrequests() · 1f39a7cc
      Trond Myklebust authored
      [ Upstream commit 08ca8b21 ]
      
      When a subrequest is being detached from the subgroup, we want to
      ensure that it is not holding the group lock, or in the process
      of waiting for the group lock.
      
      Fixes: 5b2b5187 ("NFS: Fix nfs_page_group_destroy() and nfs_lock_and_join_requests() race cases")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1f39a7cc
    • Stuart Hayes's avatar
      PCI: pciehp: Fix MSI interrupt race · a8cc5227
      Stuart Hayes authored
      [ Upstream commit 8edf5332 ]
      
      Without this commit, a PCIe hotplug port can stop generating interrupts on
      hotplug events, so device adds and removals will not be seen:
      
      The pciehp interrupt handler pciehp_isr() reads the Slot Status register
      and then writes back to it to clear the bits that caused the interrupt.  If
      a different interrupt event bit gets set between the read and the write,
      pciehp_isr() returns without having cleared all of the interrupt event
      bits.  If this happens when the MSI isn't masked (which by default it isn't
      in handle_edge_irq(), and which it will never be when MSI per-vector
      masking is not supported), we won't get any more hotplug interrupts from
      that device.
      
      That is expected behavior, according to the PCIe Base Spec r5.0, section
      6.7.3.4, "Software Notification of Hot-Plug Events".
      
      Because the Presence Detect Changed and Data Link Layer State Changed event
      bits can both get set at nearly the same time when a device is added or
      removed, this is more likely to happen than it might seem.  The issue was
      found (and can be reproduced rather easily) by connecting and disconnecting
      an NVMe storage device on at least one system model where the NVMe devices
      were being connected to an AMD PCIe port (PCI device 0x1022/0x1483).
      
      Fix the issue by modifying pciehp_isr() to loop back and re-read the Slot
      Status register immediately after writing to it, until it sees that all of
      the event status bits have been cleared.
      
      [lukas: drop loop count limitation, write "events" instead of "status",
      don't loop back in INTx and poll modes, tweak code comment & commit msg]
      Link: https://lore.kernel.org/r/78b4ced5072bfe6e369d20e8b47c279b8c7af12e.1582121613.git.lukas@wunner.deTested-by: default avatarStuart Hayes <stuart.w.hayes@gmail.com>
      Signed-off-by: default avatarStuart Hayes <stuart.w.hayes@gmail.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a8cc5227
    • Andreas Steinmetz's avatar
      ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor · 65d95462
      Andreas Steinmetz authored
      [ Upstream commit 5c6cd702 ]
      
      The Miditech MIDIFACE 16x16 (USB ID 1290:1749) has more than one extra
      endpoint descriptor.
      
      The first extra descriptor is: 0x06 0x30 0x00 0x00 0x00 0x00
      
      As the code in snd_usbmidi_get_ms_info() looks only at the
      first extra descriptor to find USB_DT_CS_ENDPOINT the device
      as such is recognized but there is neither input nor output
      configured.
      
      The patch iterates through the extra descriptors to find the
      proper one. With this patch the device is correctly configured.
      Signed-off-by: default avatarAndreas Steinmetz <ast@domdv.de>
      Link: https://lore.kernel.org/r/1c3b431a86f69e1d60745b6110cdb93c299f120b.camel@domdv.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      65d95462
    • Liu Song's avatar
      ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len · 2f0a77cc
      Liu Song authored
      [ Upstream commit acc5af3e ]
      
      In “ubifs_check_node”, when the value of "node_len" is abnormal,
      the code will goto label of "out_len" for execution. Then, in the
      following "ubifs_dump_node", if inode type is "UBIFS_DATA_NODE",
      in "print_hex_dump", an out-of-bounds access may occur due to the
      wrong "ch->len".
      
      Therefore, when the value of "node_len" is abnormal, data length
      should to be adjusted to a reasonable safe range. At this time,
      structured data is not credible, so dump the corrupted data directly
      for analysis.
      Signed-off-by: default avatarLiu Song <liu.song11@zte.com.cn>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2f0a77cc
    • Mikel Rychliski's avatar
      PCI: Use ioremap(), not phys_to_virt() for platform ROM · 1841a993
      Mikel Rychliski authored
      [ Upstream commit 72e0ef0e ]
      
      On some EFI systems, the video BIOS is provided by the EFI firmware.  The
      boot stub code stores the physical address of the ROM image in pdev->rom.
      Currently we attempt to access this pointer using phys_to_virt(), which
      doesn't work with CONFIG_HIGHMEM.
      
      On these systems, attempting to load the radeon module on a x86_32 kernel
      can result in the following:
      
        BUG: unable to handle page fault for address: 3e8ed03c
        #PF: supervisor read access in kernel mode
        #PF: error_code(0x0000) - not-present page
        *pde = 00000000
        Oops: 0000 [#1] PREEMPT SMP
        CPU: 0 PID: 317 Comm: systemd-udevd Not tainted 5.6.0-rc3-next-20200228 #2
        Hardware name: Apple Computer, Inc. MacPro1,1/Mac-F4208DC8, BIOS     MP11.88Z.005C.B08.0707021221 07/02/07
        EIP: radeon_get_bios+0x5ed/0xe50 [radeon]
        Code: 00 00 84 c0 0f 85 12 fd ff ff c7 87 64 01 00 00 00 00 00 00 8b 47 08 8b 55 b0 e8 1e 83 e1 d6 85 c0 74 1a 8b 55 c0 85 d2 74 13 <80> 38 55 75 0e 80 78 01 aa 0f 84 a4 03 00 00 8d 74 26 00 68 dc 06
        EAX: 3e8ed03c EBX: 00000000 ECX: 3e8ed03c EDX: 00010000
        ESI: 00040000 EDI: eec04000 EBP: eef3fc60 ESP: eef3fbe0
        DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010206
        CR0: 80050033 CR2: 3e8ed03c CR3: 2ec77000 CR4: 000006d0
        Call Trace:
         r520_init+0x26/0x240 [radeon]
         radeon_device_init+0x533/0xa50 [radeon]
         radeon_driver_load_kms+0x80/0x220 [radeon]
         drm_dev_register+0xa7/0x180 [drm]
         radeon_pci_probe+0x10f/0x1a0 [radeon]
         pci_device_probe+0xd4/0x140
      
      Fix the issue by updating all drivers which can access a platform provided
      ROM. Instead of calling the helper function pci_platform_rom() which uses
      phys_to_virt(), call ioremap() directly on the pdev->rom.
      
      radeon_read_platform_bios() previously directly accessed an __iomem
      pointer. Avoid this by calling memcpy_fromio() instead of kmemdup().
      
      pci_platform_rom() now has no remaining callers, so remove it.
      
      Link: https://lore.kernel.org/r/20200319021623.5426-1-mikel@mikelr.comSigned-off-by: default avatarMikel Rychliski <mikel@mikelr.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1841a993
    • Chuck Lever's avatar
      svcrdma: Fix leak of transport addresses · 308aeb36
      Chuck Lever authored
      [ Upstream commit 1a33d8a2 ]
      
      Kernel memory leak detected:
      
      unreferenced object 0xffff888849cdf480 (size 8):
        comm "kworker/u8:3", pid 2086, jiffies 4297898756 (age 4269.856s)
        hex dump (first 8 bytes):
          30 00 cd 49 88 88 ff ff                          0..I....
        backtrace:
          [<00000000acfc370b>] __kmalloc_track_caller+0x137/0x183
          [<00000000a2724354>] kstrdup+0x2b/0x43
          [<0000000082964f84>] xprt_rdma_format_addresses+0x114/0x17d [rpcrdma]
          [<00000000dfa6ed00>] xprt_setup_rdma_bc+0xc0/0x10c [rpcrdma]
          [<0000000073051a83>] xprt_create_transport+0x3f/0x1a0 [sunrpc]
          [<0000000053531a8e>] rpc_create+0x118/0x1cd [sunrpc]
          [<000000003a51b5f8>] setup_callback_client+0x1a5/0x27d [nfsd]
          [<000000001bd410af>] nfsd4_process_cb_update.isra.7+0x16c/0x1ac [nfsd]
          [<000000007f4bbd56>] nfsd4_run_cb_work+0x4c/0xbd [nfsd]
          [<0000000055c5586b>] process_one_work+0x1b2/0x2fe
          [<00000000b1e3e8ef>] worker_thread+0x1a6/0x25a
          [<000000005205fb78>] kthread+0xf6/0xfb
          [<000000006d2dc057>] ret_from_fork+0x3a/0x50
      
      Introduce a call to xprt_rdma_free_addresses() similar to the way
      that the TCP backchannel releases a transport's peer address
      strings.
      
      Fixes: 5d252f90 ("svcrdma: Add class for RDMA backwards direction transport")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      308aeb36
    • Christophe JAILLET's avatar
      SUNRPC: Fix a potential buffer overflow in 'svc_print_xprts()' · 38c46471
      Christophe JAILLET authored
      [ Upstream commit b25b60d7 ]
      
      'maxlen' is the total size of the destination buffer. There is only one
      caller and this value is 256.
      
      When we compute the size already used and what we would like to add in
      the buffer, the trailling NULL character is not taken into account.
      However, this trailling character will be added by the 'strcat' once we
      have checked that we have enough place.
      
      So, there is a off-by-one issue and 1 byte of the stack could be
      erroneously overwridden.
      
      Take into account the trailling NULL, when checking if there is enough
      place in the destination buffer.
      
      While at it, also replace a 'sprintf' by a safer 'snprintf', check for
      output truncation and avoid a superfluous 'strlen'.
      
      Fixes: dc9a16e4 ("svc: Add /proc/sys/sunrpc/transport files")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      [ cel: very minor fix to documenting comment
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      38c46471
    • Don Brace's avatar
      scsi: hpsa: correct race condition in offload enabled · b125a752
      Don Brace authored
      [ Upstream commit 3e16e83a ]
      
      Correct race condition where ioaccel is re-enabled before the raid_map is
      updated. For RAID_1, RAID_1ADM, and RAID 5/6 there is a BUG_ON called which
      is bad.
      
       - Change event thread to disable ioaccel only. Send all requests down the
         RAID path instead.
      
       - Have rescan thread handle offload_enable.
      
       - Since there is only one rescan allowed at a time, turning
         offload_enabled on/off should not be racy. Each handler queues up a
         rescan if one is already in progress.
      
        - For timing diagram, offload_enabled is initially off due to a change
          (transformation: splitmirror/remirror), ...
      
        otbe = offload_to_be_enabled
        oe   = offload_enabled
      
        Time Event         Rescan              Completion     Request
             Worker        Worker              Thread         Thread
        ---- ------        ------              ----------     -------
         T0   |             |                       + UA      |
         T1   |             + rescan started        | 0x3f    |
         T2   + Event       |                       | 0x0e    |
         T3   + Ack msg     |                       |         |
         T4   |             + if (!dev[i]->oe &&    |         |
         T5   |             |     dev[i]->otbe)     |         |
         T6   |             |      get_raid_map     |         |
         T7   + otbe = 1    |                       |         |
         T8   |             |                       |         |
         T9   |             + oe = otbe             |         |
         T10  |             |                       |         + ioaccel request
         T11                                                  * BUG_ON
      
        T0 - I/O completion with UA 0x3f 0x0e sets rescan flag.
        T1 - rescan worker thread starts a rescan.
        T2 - event comes in
        T3 - event thread starts and issues "Acknowledge" message
        ...
        T6 - rescan thread has bypassed code to reload new raid map.
        ...
        T7 - event thread runs and sets offload_to_be_enabled
        ...
        T9 - rescan thread turns on offload_enabled.
        T10- request comes in and goes down ioaccel path.
        T11- BUG_ON.
      
       - After the patch is applied, ioaccel_enabled can only be re-enabled in
         the re-scan thread.
      
      Link: https://lore.kernel.org/r/158472877894.14200.7077843399036368335.stgit@brunhildaReviewed-by: default avatarScott Teel <scott.teel@microsemi.com>
      Reviewed-by: default avatarMatt Perricone <matt.perricone@microsemi.com>
      Reviewed-by: default avatarScott Benesh <scott.benesh@microsemi.com>
      Signed-off-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b125a752
    • Zhu Yanjun's avatar
      RDMA/rxe: Set sys_image_guid to be aligned with HW IB devices · db96986c
      Zhu Yanjun authored
      [ Upstream commit d0ca2c35 ]
      
      The RXE driver doesn't set sys_image_guid and user space applications see
      zeros. This causes to pyverbs tests to fail with the following traceback,
      because the IBTA spec requires to have valid sys_image_guid.
      
       Traceback (most recent call last):
         File "./tests/test_device.py", line 51, in test_query_device
           self.verify_device_attr(attr)
         File "./tests/test_device.py", line 74, in verify_device_attr
           assert attr.sys_image_guid != 0
      
      In order to fix it, set sys_image_guid to be equal to node_guid.
      
      Before:
       5: rxe0: ... node_guid 5054:00ff:feaa:5363 sys_image_guid
       0000:0000:0000:0000
      
      After:
       5: rxe0: ... node_guid 5054:00ff:feaa:5363 sys_image_guid
       5054:00ff:feaa:5363
      
      Fixes: 8700e3e7 ("Soft RoCE driver")
      Link: https://lore.kernel.org/r/20200323112800.1444784-1-leon@kernel.orgSigned-off-by: default avatarZhu Yanjun <yanjunz@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      db96986c
    • Israel Rukshin's avatar
      nvme: Fix controller creation races with teardown flow · 6f7baf41
      Israel Rukshin authored
      [ Upstream commit ce151813 ]
      
      Calling nvme_sysfs_delete() when the controller is in the middle of
      creation may cause several bugs. If the controller is in NEW state we
      remove delete_controller file and don't delete the controller. The user
      will not be able to use nvme disconnect command on that controller again,
      although the controller may be active. Other bugs may happen if the
      controller is in the middle of create_ctrl callback and
      nvme_do_delete_ctrl() starts. For example, freeing I/O tagset at
      nvme_do_delete_ctrl() before it was allocated at create_ctrl callback.
      
      To fix all those races don't allow the user to delete the controller
      before it was fully created.
      Signed-off-by: default avatarIsrael Rukshin <israelr@mellanox.com>
      Reviewed-by: default avatarMax Gurtovoy <maxg@mellanox.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarKeith Busch <kbusch@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6f7baf41
    • John Meneghini's avatar
      nvme-multipath: do not reset on unknown status · b3dc81c1
      John Meneghini authored
      [ Upstream commit 764e9332 ]
      
      The nvme multipath error handling defaults to controller reset if the
      error is unknown. There are, however, no existing nvme status codes that
      indicate a reset should be used, and resetting causes unnecessary
      disruption to the rest of IO.
      
      Change nvme's error handling to first check if failover should happen.
      If not, let the normal error handling take over rather than reset the
      controller.
      Based-on-a-patch-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarJohn Meneghini <johnm@netapp.com>
      Signed-off-by: default avatarKeith Busch <kbusch@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b3dc81c1
    • Gabriel Ravier's avatar
      tools: gpio-hammer: Avoid potential overflow in main · 1d0e4829
      Gabriel Ravier authored
      [ Upstream commit d1ee7e1f ]
      
      If '-o' was used more than 64 times in a single invocation of gpio-hammer,
      this could lead to an overflow of the 'lines' array. This commit fixes
      this by avoiding the overflow and giving a proper diagnostic back to the
      user
      Signed-off-by: default avatarGabriel Ravier <gabravier@gmail.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1d0e4829
    • Pratik Rajesh Sampat's avatar
      cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_work_fn · 68aaf039
      Pratik Rajesh Sampat authored
      [ Upstream commit d95fe371 ]
      
      The patch avoids allocating cpufreq_policy on stack hence fixing frame
      size overflow in 'powernv_cpufreq_work_fn'
      
      Fixes: 22794280 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling")
      Signed-off-by: default avatarPratik Rajesh Sampat <psampat@linux.ibm.com>
      Reviewed-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200316135743.57735-1-psampat@linux.ibm.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      68aaf039
    • Christophe JAILLET's avatar
      perf cpumap: Fix snprintf overflow check · 9a1d2d2e
      Christophe JAILLET authored
      [ Upstream commit d74b181a ]
      
      'snprintf' returns the number of characters which would be generated for
      the given input.
      
      If the returned value is *greater than* or equal to the buffer size, it
      means that the output has been truncated.
      
      Fix the overflow test accordingly.
      
      Fixes: 7780c25b ("perf tools: Allow ability to map cpus to nodes easily")
      Fixes: 92a7e127 ("perf cpumap: Add cpu__max_present_cpu()")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Suggested-by: default avatarDavid Laight <David.Laight@ACULAB.COM>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: He Zhe <zhe.he@windriver.com>
      Cc: Jan Stancek <jstancek@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: kernel-janitors@vger.kernel.org
      Link: http://lore.kernel.org/lkml/20200324070319.10901-1-christophe.jaillet@wanadoo.frSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9a1d2d2e
    • Vignesh Raghavendra's avatar
      serial: 8250: 8250_omap: Terminate DMA before pushing data on RX timeout · 69077bd8
      Vignesh Raghavendra authored
      [ Upstream commit 7cf4df30 ]
      
      Terminate and flush DMA internal buffers, before pushing RX data to
      higher layer. Otherwise, this will lead to data corruption, as driver
      would end up pushing stale buffer data to higher layer while actual data
      is still stuck inside DMA hardware and has yet not arrived at the
      memory.
      While at that, replace deprecated dmaengine_terminate_all() with
      dmaengine_terminate_async().
      Signed-off-by: default avatarVignesh Raghavendra <vigneshr@ti.com>
      Link: https://lore.kernel.org/r/20200319110344.21348-2-vigneshr@ti.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      69077bd8
    • Peter Ujfalusi's avatar
      serial: 8250_omap: Fix sleeping function called from invalid context during probe · 10aa90fe
      Peter Ujfalusi authored
      [ Upstream commit 4ce35a36 ]
      
      When booting j721e the following bug is printed:
      
      [    1.154821] BUG: sleeping function called from invalid context at kernel/sched/completion.c:99
      [    1.154827] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 12, name: kworker/0:1
      [    1.154832] 3 locks held by kworker/0:1/12:
      [    1.154836]  #0: ffff000840030728 ((wq_completion)events){+.+.}, at: process_one_work+0x1d4/0x6e8
      [    1.154852]  #1: ffff80001214fdd8 (deferred_probe_work){+.+.}, at: process_one_work+0x1d4/0x6e8
      [    1.154860]  #2: ffff00084060b170 (&dev->mutex){....}, at: __device_attach+0x38/0x138
      [    1.154872] irq event stamp: 63096
      [    1.154881] hardirqs last  enabled at (63095): [<ffff800010b74318>] _raw_spin_unlock_irqrestore+0x70/0x78
      [    1.154887] hardirqs last disabled at (63096): [<ffff800010b740d8>] _raw_spin_lock_irqsave+0x28/0x80
      [    1.154893] softirqs last  enabled at (62254): [<ffff800010080c88>] _stext+0x488/0x564
      [    1.154899] softirqs last disabled at (62247): [<ffff8000100fdb3c>] irq_exit+0x114/0x140
      [    1.154906] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.0-rc6-next-20200318-00094-g45e4089b0bd3 #221
      [    1.154911] Hardware name: Texas Instruments K3 J721E SoC (DT)
      [    1.154917] Workqueue: events deferred_probe_work_func
      [    1.154923] Call trace:
      [    1.154928]  dump_backtrace+0x0/0x190
      [    1.154933]  show_stack+0x14/0x20
      [    1.154940]  dump_stack+0xe0/0x148
      [    1.154946]  ___might_sleep+0x150/0x1f0
      [    1.154952]  __might_sleep+0x4c/0x80
      [    1.154957]  wait_for_completion_timeout+0x40/0x140
      [    1.154964]  ti_sci_set_device_state+0xa0/0x158
      [    1.154969]  ti_sci_cmd_get_device_exclusive+0x14/0x20
      [    1.154977]  ti_sci_dev_start+0x34/0x50
      [    1.154984]  genpd_runtime_resume+0x78/0x1f8
      [    1.154991]  __rpm_callback+0x3c/0x140
      [    1.154996]  rpm_callback+0x20/0x80
      [    1.155001]  rpm_resume+0x568/0x758
      [    1.155007]  __pm_runtime_resume+0x44/0xb0
      [    1.155013]  omap8250_probe+0x2b4/0x508
      [    1.155019]  platform_drv_probe+0x50/0xa0
      [    1.155023]  really_probe+0xd4/0x318
      [    1.155028]  driver_probe_device+0x54/0xe8
      [    1.155033]  __device_attach_driver+0x80/0xb8
      [    1.155039]  bus_for_each_drv+0x74/0xc0
      [    1.155044]  __device_attach+0xdc/0x138
      [    1.155049]  device_initial_probe+0x10/0x18
      [    1.155053]  bus_probe_device+0x98/0xa0
      [    1.155058]  deferred_probe_work_func+0x74/0xb0
      [    1.155063]  process_one_work+0x280/0x6e8
      [    1.155068]  worker_thread+0x48/0x430
      [    1.155073]  kthread+0x108/0x138
      [    1.155079]  ret_from_fork+0x10/0x18
      
      To fix the bug we need to first call pm_runtime_enable() prior to any
      pm_runtime calls.
      Reported-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Link: https://lore.kernel.org/r/20200320125200.6772-1-peter.ujfalusi@ti.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      10aa90fe
    • Vignesh Raghavendra's avatar
      serial: 8250_port: Don't service RX FIFO if throttled · 20191760
      Vignesh Raghavendra authored
      [ Upstream commit f19c3f6c ]
      
      When port's throttle callback is called, it should stop pushing any more
      data into TTY buffer to avoid buffer overflow. This means driver has to
      stop HW from receiving more data and assert the HW flow control. For
      UARTs with auto HW flow control (such as 8250_omap) manual assertion of
      flow control line is not possible and only way is to allow RX FIFO to
      fill up, thus trigger auto HW flow control logic.
      
      Therefore make sure that 8250 generic IRQ handler does not drain data
      when port is stopped (i.e UART_LSR_DR is unset in read_status_mask). Not
      servicing, RX FIFO would trigger auto HW flow control when FIFO
      occupancy reaches preset threshold, thus halting RX.
      Since, error conditions in UART_LSR register are cleared just by reading
      the register, data has to be drained in case there are FIFO errors, else
      error information will lost.
      Signed-off-by: default avatarVignesh Raghavendra <vigneshr@ti.com>
      Link: https://lore.kernel.org/r/20200319103230.16867-2-vigneshr@ti.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      20191760
    • Ian Rogers's avatar
      perf parse-events: Fix 3 use after frees found with clang ASAN · a0100a36
      Ian Rogers authored
      [ Upstream commit d4953f7e ]
      
      Reproducible with a clang asan build and then running perf test in
      particular 'Parse event definition strings'.
      Signed-off-by: default avatarIan Rogers <irogers@google.com>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: clang-built-linux@googlegroups.com
      Link: http://lore.kernel.org/lkml/20200314170356.62914-1-irogers@google.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a0100a36
    • Niklas Söderlund's avatar
      thermal: rcar_thermal: Handle probe error gracefully · 9d8b5dba
      Niklas Söderlund authored
      [ Upstream commit 39056e8a ]
      
      If the common register memory resource is not available the driver needs
      to fail gracefully to disable PM. Instead of returning the error
      directly store it in ret and use the already existing error path.
      Signed-off-by: default avatarNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Link: https://lore.kernel.org/r/20200310114709.1483860-1-niklas.soderlund+renesas@ragnatech.seSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      9d8b5dba
    • Nathan Chancellor's avatar
      tracing: Use address-of operator on section symbols · b92d156a
      Nathan Chancellor authored
      [ Upstream commit bf2cbe04 ]
      
      Clang warns:
      
      ../kernel/trace/trace.c:9335:33: warning: array comparison always
      evaluates to true [-Wtautological-compare]
              if (__stop___trace_bprintk_fmt != __start___trace_bprintk_fmt)
                                             ^
      1 warning generated.
      
      These are not true arrays, they are linker defined symbols, which are
      just addresses. Using the address of operator silences the warning and
      does not change the runtime result of the check (tested with some print
      statements compiled in with clang + ld.lld and gcc + ld.bfd in QEMU).
      
      Link: http://lkml.kernel.org/r/20200220051011.26113-1-natechancellor@gmail.com
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/893Suggested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b92d156a
    • Jordan Crouse's avatar
      drm/msm/a5xx: Always set an OPP supported hardware value · 102bdec1
      Jordan Crouse authored
      [ Upstream commit 0478b4fc ]
      
      If the opp table specifies opp-supported-hw as a property but the driver
      has not set a supported hardware value the OPP subsystem will reject
      all the table entries.
      
      Set a "default" value that will match the default table entries but not
      conflict with any possible real bin values. Also fix a small memory leak
      and free the buffer allocated by nvmem_cell_read().
      Signed-off-by: default avatarJordan Crouse <jcrouse@codeaurora.org>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      102bdec1
    • Pavel Machek's avatar
      drm/msm: fix leaks if initialization fails · 45e61801
      Pavel Machek authored
      [ Upstream commit 66be340f ]
      
      We should free resources in unlikely case of allocation failure.
      Signed-off-by: default avatarPavel Machek <pavel@denx.de>
      Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      45e61801
    • Gustavo Romero's avatar
      KVM: PPC: Book3S HV: Treat TM-related invalid form instructions on P9 like the valid ones · 22840383
      Gustavo Romero authored
      [ Upstream commit 1dff3064 ]
      
      On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
      KVM. This is handled at first by the hardware raising a softpatch interrupt
      when certain TM instructions that need KVM assistance are executed in the
      guest. Althought some TM instructions per Power ISA are invalid forms they
      can raise a softpatch interrupt too. For instance, 'tresume.' instruction
      as defined in the ISA must have bit 31 set (1), but an instruction that
      matches 'tresume.' PO and XO opcode fields but has bit 31 not set (0), like
      0x7cfe9ddc, also raises a softpatch interrupt. Similarly for 'treclaim.'
      and 'trechkpt.' instructions with bit 31 = 0, i.e. 0x7c00075c and
      0x7c0007dc, respectively. Hence, if a code like the following is executed
      in the guest it will raise a softpatch interrupt just like a 'tresume.'
      when the TM facility is enabled ('tabort. 0' in the example is used only
      to enable the TM facility):
      
      int main() { asm("tabort. 0; .long 0x7cfe9ddc;"); }
      
      Currently in such a case KVM throws a complete trace like:
      
      [345523.705984] WARNING: CPU: 24 PID: 64413 at arch/powerpc/kvm/book3s_hv_tm.c:211 kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
      [345523.705985] Modules linked in: kvm_hv(E) xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat
      iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ebtable_filter ebtables ip6table_filter
      ip6_tables iptable_filter bridge stp llc sch_fq_codel ipmi_powernv at24 vmx_crypto ipmi_devintf ipmi_msghandler
      ibmpowernv uio_pdrv_genirq kvm opal_prd uio leds_powernv ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp
      libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456
      async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear tg3
      crct10dif_vpmsum crc32c_vpmsum ipr [last unloaded: kvm_hv]
      [345523.706030] CPU: 24 PID: 64413 Comm: CPU 0/KVM Tainted: G        W   E     5.5.0+ #1
      [345523.706031] NIP:  c0080000072cb9c0 LR: c0080000072b5e80 CTR: c0080000085c7850
      [345523.706034] REGS: c000000399467680 TRAP: 0700   Tainted: G        W   E      (5.5.0+)
      [345523.706034] MSR:  900000010282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 24022428  XER: 00000000
      [345523.706042] CFAR: c0080000072b5e7c IRQMASK: 0
                      GPR00: c0080000072b5e80 c000000399467910 c0080000072db500 c000000375ccc720
                      GPR04: c000000375ccc720 00000003fbec0000 0000a10395dda5a6 0000000000000000
                      GPR08: 000000007cfe9ddc 7cfe9ddc000005dc 7cfe9ddc7c0005dc c0080000072cd530
                      GPR12: c0080000085c7850 c0000003fffeb800 0000000000000001 00007dfb737f0000
                      GPR16: c0002001edcca558 0000000000000000 0000000000000000 0000000000000001
                      GPR20: c000000001b21258 c0002001edcca558 0000000000000018 0000000000000000
                      GPR24: 0000000001000000 ffffffffffffffff 0000000000000001 0000000000001500
                      GPR28: c0002001edcc4278 c00000037dd80000 800000050280f033 c000000375ccc720
      [345523.706062] NIP [c0080000072cb9c0] kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
      [345523.706065] LR [c0080000072b5e80] kvmppc_handle_exit_hv.isra.53+0x3e8/0x798 [kvm_hv]
      [345523.706066] Call Trace:
      [345523.706069] [c000000399467910] [c000000399467940] 0xc000000399467940 (unreliable)
      [345523.706071] [c000000399467950] [c000000399467980] 0xc000000399467980
      [345523.706075] [c0000003994679f0] [c0080000072bd1c4] kvmhv_run_single_vcpu+0xa1c/0xb80 [kvm_hv]
      [345523.706079] [c000000399467ac0] [c0080000072bd8e0] kvmppc_vcpu_run_hv+0x5b8/0xb00 [kvm_hv]
      [345523.706087] [c000000399467b90] [c0080000085c93cc] kvmppc_vcpu_run+0x34/0x48 [kvm]
      [345523.706095] [c000000399467bb0] [c0080000085c582c] kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm]
      [345523.706101] [c000000399467c40] [c0080000085b7498] kvm_vcpu_ioctl+0x3d0/0x7b0 [kvm]
      [345523.706105] [c000000399467db0] [c0000000004adf9c] ksys_ioctl+0x13c/0x170
      [345523.706107] [c000000399467e00] [c0000000004adff8] sys_ioctl+0x28/0x80
      [345523.706111] [c000000399467e20] [c00000000000b278] system_call+0x5c/0x68
      [345523.706112] Instruction dump:
      [345523.706114] 419e0390 7f8a4840 409d0048 6d497c00 2f89075d 419e021c 6d497c00 2f8907dd
      [345523.706119] 419e01c0 6d497c00 2f8905dd 419e00a4 <0fe00000> 38210040 38600000 ebc1fff0
      
      and then treats the executed instruction as a 'nop'.
      
      However the POWER9 User's Manual, in section "4.6.10 Book II Invalid
      Forms", informs that for TM instructions bit 31 is in fact ignored, thus
      for the TM-related invalid forms ignoring bit 31 and handling them like the
      valid forms is an acceptable way to handle them. POWER8 behaves the same
      way too.
      
      This commit changes the handling of the cases here described by treating
      the TM-related invalid forms that can generate a softpatch interrupt
      just like their valid forms (w/ bit 31 = 1) instead of as a 'nop' and by
      gently reporting any other unrecognized case to the host and treating it as
      illegal instruction instead of throwing a trace and treating it as a 'nop'.
      Signed-off-by: default avatarGustavo Romero <gromero@linux.ibm.com>
      Reviewed-by: default avatarSegher Boessenkool <segher@kernel.crashing.org>
      Acked-By: default avatarMichael Neuling <mikey@neuling.org>
      Reviewed-by: default avatarLeonardo Bras <leonardo@linux.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      22840383
    • Jason Gunthorpe's avatar
      RDMA/cm: Remove a race freeing timewait_info · 851eba10
      Jason Gunthorpe authored
      [ Upstream commit bede86a3 ]
      
      When creating a cm_id during REQ the id immediately becomes visible to the
      other MAD handlers, and shortly after the state is moved to IB_CM_REQ_RCVD
      
      This allows cm_rej_handler() to run concurrently and free the work:
      
              CPU 0                                CPU1
       cm_req_handler()
        ib_create_cm_id()
        cm_match_req()
          id_priv->state = IB_CM_REQ_RCVD
                                             cm_rej_handler()
                                               cm_acquire_id()
                                               spin_lock(&id_priv->lock)
                                               switch (id_priv->state)
        					   case IB_CM_REQ_RCVD:
                                                  cm_reset_to_idle()
                                                   kfree(id_priv->timewait_info);
         goto destroy
        destroy:
          kfree(id_priv->timewait_info);
                                                   id_priv->timewait_info = NULL
      
      Causing a double free or worse.
      
      Do not free the timewait_info without also holding the
      id_priv->lock. Simplify this entire flow by making the free unconditional
      during cm_destroy_id() and removing the confusing special case error
      unwind during creation of the timewait_info.
      
      This also fixes a leak of the timewait if cm_destroy_id() is called in
      IB_CM_ESTABLISHED with an XRC TGT QP. The state machine will be left in
      ESTABLISHED while it needed to transition through IB_CM_TIMEWAIT to
      release the timewait pointer.
      
      Also fix a leak of the timewait_info if the caller mis-uses the API and
      does ib_send_cm_reqs().
      
      Fixes: a977049d ("[PATCH] IB: Add the kernel CM implementation")
      Link: https://lore.kernel.org/r/20200310092545.251365-4-leon@kernel.orgSigned-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      851eba10
    • Trond Myklebust's avatar
      nfsd: Don't add locks to closed or closing open stateids · 1ab250aa
      Trond Myklebust authored
      [ Upstream commit a451b123 ]
      
      In NFSv4, the lock stateids are tied to the lockowner, and the open stateid,
      so that the action of closing the file also results in either an automatic
      loss of the locks, or an error of the form NFS4ERR_LOCKS_HELD.
      
      In practice this means we must not add new locks to the open stateid
      after the close process has been invoked. In fact doing so, can result
      in the following panic:
      
       kernel BUG at lib/list_debug.c:51!
       invalid opcode: 0000 [#1] SMP NOPTI
       CPU: 2 PID: 1085 Comm: nfsd Not tainted 5.6.0-rc3+ #2
       Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.14410784.B64.1908150010 08/15/2019
       RIP: 0010:__list_del_entry_valid.cold+0x31/0x55
       Code: 1a 3d 9b e8 74 10 c2 ff 0f 0b 48 c7 c7 f0 1a 3d 9b e8 66 10 c2 ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 b0 1a 3d 9b e8 52 10 c2 ff <0f> 0b 48 89 fe 4c 89 c2 48 c7 c7 78 1a 3d 9b e8 3e 10 c2 ff 0f 0b
       RSP: 0018:ffffb296c1d47d90 EFLAGS: 00010246
       RAX: 0000000000000054 RBX: ffff8ba032456ec8 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffff8ba039e99cc8 RDI: ffff8ba039e99cc8
       RBP: ffff8ba032456e60 R08: 0000000000000781 R09: 0000000000000003
       R10: 0000000000000000 R11: 0000000000000001 R12: ffff8ba009a4abe0
       R13: ffff8ba032456e8c R14: 0000000000000000 R15: ffff8ba00adb01d8
       FS:  0000000000000000(0000) GS:ffff8ba039e80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007fb213f0b008 CR3: 00000001347de006 CR4: 00000000003606e0
       Call Trace:
        release_lock_stateid+0x2b/0x80 [nfsd]
        nfsd4_free_stateid+0x1e9/0x210 [nfsd]
        nfsd4_proc_compound+0x414/0x700 [nfsd]
        ? nfs4svc_decode_compoundargs+0x407/0x4c0 [nfsd]
        nfsd_dispatch+0xc1/0x200 [nfsd]
        svc_process_common+0x476/0x6f0 [sunrpc]
        ? svc_sock_secure_port+0x12/0x30 [sunrpc]
        ? svc_recv+0x313/0x9c0 [sunrpc]
        ? nfsd_svc+0x2d0/0x2d0 [nfsd]
        svc_process+0xd4/0x110 [sunrpc]
        nfsd+0xe3/0x140 [nfsd]
        kthread+0xf9/0x130
        ? nfsd_destroy+0x50/0x50 [nfsd]
        ? kthread_park+0x90/0x90
        ret_from_fork+0x1f/0x40
      
      The fix is to ensure that lock creation tests for whether or not the
      open stateid is unhashed, and to fail if that is the case.
      
      Fixes: 659aefb6 ("nfsd: Ensure we don't recognise lock stateids after freeing them")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1ab250aa
    • Alexandre Belloni's avatar
      rtc: ds1374: fix possible race condition · 142513a2
      Alexandre Belloni authored
      [ Upstream commit c11af813 ]
      
      The RTC IRQ is requested before the struct rtc_device is allocated,
      this may lead to a NULL pointer dereference in the IRQ handler.
      
      To fix this issue, allocating the rtc_device struct before requesting
      the RTC IRQ using devm_rtc_allocate_device, and use rtc_register_device
      to register the RTC device.
      
      Link: https://lore.kernel.org/r/20200306073404.56921-1-alexandre.belloni@bootlin.comSigned-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      142513a2
    • Alexandre Belloni's avatar
      rtc: sa1100: fix possible race condition · e934a66d
      Alexandre Belloni authored
      [ Upstream commit f2997775 ]
      
      Both RTC IRQs are requested before the struct rtc_device is allocated,
      this may lead to a NULL pointer dereference in the IRQ handler.
      
      To fix this issue, allocating the rtc_device struct before requesting
      the IRQs using devm_rtc_allocate_device, and use rtc_register_device
      to register the RTC device.
      
      Link: https://lore.kernel.org/r/20200306010146.39762-1-alexandre.belloni@bootlin.comSigned-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e934a66d
    • Stefan Berger's avatar
      tpm: ibmvtpm: Wait for buffer to be set before proceeding · abc5b427
      Stefan Berger authored
      [ Upstream commit d8d74ea3 ]
      
      Synchronize with the results from the CRQs before continuing with
      the initialization. This avoids trying to send TPM commands while
      the rtce buffer has not been allocated, yet.
      
      This patch fixes an existing race condition that may occurr if the
      hypervisor does not quickly respond to the VTPM_GET_RTCE_BUFFER_SIZE
      request sent during initialization and therefore the ibmvtpm->rtce_buf
      has not been allocated at the time the first TPM command is sent.
      
      Fixes: 132f7629 ("drivers/char/tpm: Add new device driver to support IBM vTPM")
      Signed-off-by: default avatarStefan Berger <stefanb@linux.ibm.com>
      Acked-by: default avatarNayna Jain <nayna@linux.ibm.com>
      Tested-by: default avatarNayna Jain <nayna@linux.ibm.com>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      abc5b427
    • Dmitry Monakhov's avatar
      ext4: mark block bitmap corrupted when found instead of BUGON · ff331054
      Dmitry Monakhov authored
      [ Upstream commit eb576086 ]
      
      We already has similar code in ext4_mb_complex_scan_group(), but
      ext4_mb_simple_scan_group() still affected.
      
      Other reports: https://www.spinics.net/lists/linux-ext4/msg60231.htmlReviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Signed-off-by: default avatarDmitry Monakhov <dmonakhov@gmail.com>
      Link: https://lore.kernel.org/r/20200310150156.641-1-dmonakhov@gmail.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ff331054
    • Darrick J. Wong's avatar
      xfs: mark dir corrupt when lookup-by-hash fails · 7fff3f7f
      Darrick J. Wong authored
      [ Upstream commit 2e107cf8 ]
      
      In xchk_dir_actor, we attempt to validate the directory hash structures
      by performing a directory entry lookup by (hashed) name.  If the lookup
      returns ENOENT, that means that the hash information is corrupt.  The
      _process_error functions don't catch this, so we have to add that
      explicitly.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7fff3f7f
    • Darrick J. Wong's avatar
      xfs: don't ever return a stale pointer from __xfs_dir3_free_read · 6ab959f1
      Darrick J. Wong authored
      [ Upstream commit 1cb5deb5 ]
      
      If we decide that a directory free block is corrupt, we must take care
      not to leak a buffer pointer to the caller.  After xfs_trans_brelse
      returns, the buffer can be freed or reused, which means that we have to
      set *bpp back to NULL.
      
      Callers are supposed to notice the nonzero return value and not use the
      buffer pointer, but we should code more defensively, even if all current
      callers handle this situation correctly.
      
      Fixes: de14c5f5 ("xfs: verify free block header fields")
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6ab959f1
    • Colin Ian King's avatar
      media: tda10071: fix unsigned sign extension overflow · 7bf06146
      Colin Ian King authored
      [ Upstream commit a7463e2d ]
      
      The shifting of buf[3] by 24 bits to the left will be promoted to
      a 32 bit signed int and then sign-extended to an unsigned long. In
      the unlikely event that the the top bit of buf[3] is set then all
      then all the upper bits end up as also being set because of
      the sign-extension and this affect the ev->post_bit_error sum.
      Fix this by using the temporary u32 variable bit_error to avoid
      the sign-extension promotion. This also removes the need to do the
      computation twice.
      
      Addresses-Coverity: ("Unintended sign extension")
      
      Fixes: 267897a4 ("[media] tda10071: implement DVBv5 statistics")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7bf06146
    • Howard Chung's avatar
      Bluetooth: L2CAP: handle l2cap config request during open state · 8828622f
      Howard Chung authored
      [ Upstream commit 96298f64 ]
      
      According to Core Spec Version 5.2 | Vol 3, Part A 6.1.5,
      the incoming L2CAP_ConfigReq should be handled during
      OPEN state.
      
      The section below shows the btmon trace when running
      L2CAP/COS/CFD/BV-12-C before and after this change.
      
      === Before ===
      ...
      > ACL Data RX: Handle 256 flags 0x02 dlen 12                #22
            L2CAP: Connection Request (0x02) ident 2 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      < ACL Data TX: Handle 256 flags 0x00 dlen 16                #23
            L2CAP: Connection Response (0x03) ident 2 len 8
              Destination CID: 64
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 256 flags 0x00 dlen 12                #24
            L2CAP: Configure Request (0x04) ident 2 len 4
              Destination CID: 65
              Flags: 0x0000
      > HCI Event: Number of Completed Packets (0x13) plen 5      #25
              Num handles: 1
              Handle: 256
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5      #26
              Num handles: 1
              Handle: 256
              Count: 1
      > ACL Data RX: Handle 256 flags 0x02 dlen 16                #27
            L2CAP: Configure Request (0x04) ident 3 len 8
              Destination CID: 64
              Flags: 0x0000
              Option: Unknown (0x10) [hint]
              01 00                                            ..
      < ACL Data TX: Handle 256 flags 0x00 dlen 18                #28
            L2CAP: Configure Response (0x05) ident 3 len 10
              Source CID: 65
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 672
      > HCI Event: Number of Completed Packets (0x13) plen 5      #29
              Num handles: 1
              Handle: 256
              Count: 1
      > ACL Data RX: Handle 256 flags 0x02 dlen 14                #30
            L2CAP: Configure Response (0x05) ident 2 len 6
              Source CID: 64
              Flags: 0x0000
              Result: Success (0x0000)
      > ACL Data RX: Handle 256 flags 0x02 dlen 20                #31
            L2CAP: Configure Request (0x04) ident 3 len 12
              Destination CID: 64
              Flags: 0x0000
              Option: Unknown (0x10) [hint]
              01 00 91 02 11 11                                ......
      < ACL Data TX: Handle 256 flags 0x00 dlen 14                #32
            L2CAP: Command Reject (0x01) ident 3 len 6
              Reason: Invalid CID in request (0x0002)
              Destination CID: 64
              Source CID: 65
      > HCI Event: Number of Completed Packets (0x13) plen 5      #33
              Num handles: 1
              Handle: 256
              Count: 1
      ...
      === After ===
      ...
      > ACL Data RX: Handle 256 flags 0x02 dlen 12               #22
            L2CAP: Connection Request (0x02) ident 2 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      < ACL Data TX: Handle 256 flags 0x00 dlen 16               #23
            L2CAP: Connection Response (0x03) ident 2 len 8
              Destination CID: 64
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 256 flags 0x00 dlen 12               #24
            L2CAP: Configure Request (0x04) ident 2 len 4
              Destination CID: 65
              Flags: 0x0000
      > HCI Event: Number of Completed Packets (0x13) plen 5     #25
              Num handles: 1
              Handle: 256
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5     #26
              Num handles: 1
              Handle: 256
              Count: 1
      > ACL Data RX: Handle 256 flags 0x02 dlen 16               #27
            L2CAP: Configure Request (0x04) ident 3 len 8
              Destination CID: 64
              Flags: 0x0000
              Option: Unknown (0x10) [hint]
              01 00                                            ..
      < ACL Data TX: Handle 256 flags 0x00 dlen 18               #28
            L2CAP: Configure Response (0x05) ident 3 len 10
              Source CID: 65
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 672
      > HCI Event: Number of Completed Packets (0x13) plen 5     #29
              Num handles: 1
              Handle: 256
              Count: 1
      > ACL Data RX: Handle 256 flags 0x02 dlen 14               #30
            L2CAP: Configure Response (0x05) ident 2 len 6
              Source CID: 64
              Flags: 0x0000
              Result: Success (0x0000)
      > ACL Data RX: Handle 256 flags 0x02 dlen 20               #31
            L2CAP: Configure Request (0x04) ident 3 len 12
              Destination CID: 64
              Flags: 0x0000
              Option: Unknown (0x10) [hint]
              01 00 91 02 11 11                                .....
      < ACL Data TX: Handle 256 flags 0x00 dlen 18               #32
            L2CAP: Configure Response (0x05) ident 3 len 10
              Source CID: 65
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 672
      < ACL Data TX: Handle 256 flags 0x00 dlen 12               #33
            L2CAP: Configure Request (0x04) ident 3 len 4
              Destination CID: 65
              Flags: 0x0000
      > HCI Event: Number of Completed Packets (0x13) plen 5     #34
              Num handles: 1
              Handle: 256
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5     #35
              Num handles: 1
              Handle: 256
              Count: 1
      ...
      Signed-off-by: default avatarHoward Chung <howardchung@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8828622f
    • Sagar Biradar's avatar
      scsi: aacraid: Disabling TM path and only processing IOP reset · ae5afc39
      Sagar Biradar authored
      [ Upstream commit bef18d30 ]
      
      Fixes the occasional adapter panic when sg_reset is issued with -d, -t, -b
      and -H flags.  Removal of command type HBA_IU_TYPE_SCSI_TM_REQ in
      aac_hba_send since iu_type, request_id and fib_flags are not populated.
      Device and target reset handlers are made to send TMF commands only when
      reset_state is 0.
      
      Link: https://lore.kernel.org/r/1581553771-25796-1-git-send-email-Sagar.Biradar@microchip.comReviewed-by: default avatarSagar Biradar <Sagar.Biradar@microchip.com>
      Signed-off-by: default avatarSagar Biradar <Sagar.Biradar@microchip.com>
      Signed-off-by: default avatarBalsundar P <balsundar.p@microsemi.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ae5afc39
    • Wen Gong's avatar
      ath10k: use kzalloc to read for ath10k_sdio_hif_diag_read · 6854738c
      Wen Gong authored
      [ Upstream commit 402f2992 ]
      
      When use command to read values, it crashed.
      
      command:
      dd if=/sys/kernel/debug/ieee80211/phy0/ath10k/mem_value count=1 bs=4 skip=$((0x100233))
      
      It will call to ath10k_sdio_hif_diag_read with address = 0x4008cc and buf_len = 4.
      
      Then system crash:
      [ 1786.013258] Unable to handle kernel paging request at virtual address ffffffc00bd45000
      [ 1786.013273] Mem abort info:
      [ 1786.013281]   ESR = 0x96000045
      [ 1786.013291]   Exception class = DABT (current EL), IL = 32 bits
      [ 1786.013299]   SET = 0, FnV = 0
      [ 1786.013307]   EA = 0, S1PTW = 0
      [ 1786.013314] Data abort info:
      [ 1786.013322]   ISV = 0, ISS = 0x00000045
      [ 1786.013330]   CM = 0, WnR = 1
      [ 1786.013342] swapper pgtable: 4k pages, 39-bit VAs, pgdp = 000000008542a60e
      [ 1786.013350] [ffffffc00bd45000] pgd=0000000000000000, pud=0000000000000000
      [ 1786.013368] Internal error: Oops: 96000045 [#1] PREEMPT SMP
      [ 1786.013609] Process swapper/0 (pid: 0, stack limit = 0x0000000084b153c6)
      [ 1786.013623] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.86 #137
      [ 1786.013631] Hardware name: MediaTek krane sku176 board (DT)
      [ 1786.013643] pstate: 80000085 (Nzcv daIf -PAN -UAO)
      [ 1786.013662] pc : __memcpy+0x94/0x180
      [ 1786.013678] lr : swiotlb_tbl_unmap_single+0x84/0x150
      [ 1786.013686] sp : ffffff8008003c60
      [ 1786.013694] x29: ffffff8008003c90 x28: ffffffae96411f80
      [ 1786.013708] x27: ffffffae960d2018 x26: ffffff8019a4b9a8
      [ 1786.013721] x25: 0000000000000000 x24: 0000000000000001
      [ 1786.013734] x23: ffffffae96567000 x22: 00000000000051d4
      [ 1786.013747] x21: 0000000000000000 x20: 00000000fe6e9000
      [ 1786.013760] x19: 0000000000000004 x18: 0000000000000020
      [ 1786.013773] x17: 0000000000000001 x16: 0000000000000000
      [ 1786.013787] x15: 00000000ffffffff x14: 00000000000044c0
      [ 1786.013800] x13: 0000000000365ba4 x12: 0000000000000000
      [ 1786.013813] x11: 0000000000000001 x10: 00000037be6e9000
      [ 1786.013826] x9 : ffffffc940000000 x8 : 000000000bd45000
      [ 1786.013839] x7 : 0000000000000000 x6 : ffffffc00bd45000
      [ 1786.013852] x5 : 0000000000000000 x4 : 0000000000000000
      [ 1786.013865] x3 : 0000000000000c00 x2 : 0000000000000004
      [ 1786.013878] x1 : fffffff7be6e9004 x0 : ffffffc00bd45000
      [ 1786.013891] Call trace:
      [ 1786.013903]  __memcpy+0x94/0x180
      [ 1786.013914]  unmap_single+0x6c/0x84
      [ 1786.013925]  swiotlb_unmap_sg_attrs+0x54/0x80
      [ 1786.013938]  __swiotlb_unmap_sg_attrs+0x8c/0xa4
      [ 1786.013952]  msdc_unprepare_data+0x6c/0x84
      [ 1786.013963]  msdc_request_done+0x58/0x84
      [ 1786.013974]  msdc_data_xfer_done+0x1a0/0x1c8
      [ 1786.013985]  msdc_irq+0x12c/0x17c
      [ 1786.013996]  __handle_irq_event_percpu+0xe4/0x250
      [ 1786.014006]  handle_irq_event_percpu+0x28/0x68
      [ 1786.014015]  handle_irq_event+0x48/0x78
      [ 1786.014026]  handle_fasteoi_irq+0xd0/0x1a0
      [ 1786.014039]  __handle_domain_irq+0x84/0xc4
      [ 1786.014050]  gic_handle_irq+0x124/0x1a4
      [ 1786.014059]  el1_irq+0xb0/0x128
      [ 1786.014072]  cpuidle_enter_state+0x298/0x328
      [ 1786.014082]  cpuidle_enter+0x30/0x40
      [ 1786.014094]  do_idle+0x190/0x268
      [ 1786.014104]  cpu_startup_entry+0x24/0x28
      [ 1786.014116]  rest_init+0xd4/0xe0
      [ 1786.014126]  start_kernel+0x30c/0x38c
      [ 1786.014139] Code: f8408423 f80084c3 36100062 b8404423 (b80044c3)
      [ 1786.014150] ---[ end trace 3b02ddb698ea69ee ]---
      [ 1786.015415] Kernel panic - not syncing: Fatal exception in interrupt
      [ 1786.015433] SMP: stopping secondary CPUs
      [ 1786.015447] Kernel Offset: 0x2e8d200000 from 0xffffff8008000000
      [ 1786.015458] CPU features: 0x0,2188200c
      [ 1786.015466] Memory Limit: none
      
      For sdio chip, it need the memory which is kmalloc, if it is
      vmalloc from ath10k_mem_value_read, then it have a memory error.
      kzalloc of ath10k_sdio_hif_diag_read32 is the correct type, so
      add kzalloc in ath10k_sdio_hif_diag_read to replace the buffer
      which is vmalloc from ath10k_mem_value_read.
      
      This patch only effect sdio chip.
      
      Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029.
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6854738c
    • Rodrigo Siqueira's avatar
      drm/amd/display: Stop if retimer is not available · 47721e8f
      Rodrigo Siqueira authored
      [ Upstream commit a0e40018 ]
      
      Raven provides retimer feature support that requires i2c interaction in
      order to make it work well, all settings required for this configuration
      are loaded from the Atom bios which include the i2c address. If the
      retimer feature is not available, we should abort the attempt to set
      this feature, otherwise, it makes the following line return
      I2C_CHANNEL_OPERATION_NO_RESPONSE:
      
       i2c_success = i2c_write(pipe_ctx, slave_address, buffer, sizeof(buffer));
       ...
       if (!i2c_success)
         ASSERT(i2c_success);
      
      This ends up causing problems with hotplugging HDMI displays on Raven,
      and causes retimer settings to warn like so:
      
      WARNING: CPU: 1 PID: 429 at
      drivers/gpu/drm/amd/amdgpu/../dal/dc/core/dc_link.c:1998
      write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Modules linked in:
      edac_mce_amd ccp kvm irqbypass binfmt_misc crct10dif_pclmul crc32_pclmul
      ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic
      ledtrig_audio snd_hda_codec_hdmi snd_hda_intel amdgpu(+) snd_hda_codec
      snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
      snd_rawmidi aesni_intel snd_seq amd_iommu_v2 gpu_sched aes_x86_64
      crypto_simd cryptd glue_helper snd_seq_device ttm drm_kms_helper
      snd_timer eeepc_wmi wmi_bmof asus_wmi sparse_keymap drm mxm_wmi snd
      k10temp fb_sys_fops syscopyarea sysfillrect sysimgblt soundcore joydev
      input_leds mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables
      x_tables autofs4 igb i2c_algo_bit hid_generic usbhid i2c_piix4 dca ahci
      hid libahci video wmi gpio_amdpt gpio_generic CPU: 1 PID: 429 Comm:
      systemd-udevd Tainted: G        W         5.2.0-rc1sept162019+ #1
      Hardware name: System manufacturer System Product Name/ROG STRIX B450-F
      GAMING, BIOS 2605 08/06/2019
      RIP: 0010:write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu]
      Code: ff 0f b6 4d ce 44 0f b6 45 cf 44 0f b6 c8 45 89 cf 44 89 e2 48 c7
      c6 f0 34 bc c0 bf 04 00 00 00 e8 63 b0 90 ff 45 84 ff 75 02 <0f> 0b 42
      0f b6 04 73 8d 50 f6 80 fa 02 77 8c 3c 0a 0f 85 c8 00 00 RSP:
      0018:ffffa99d02726fd0 EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffffa99d02727035 RCX: 0000000000000006
      RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff976acc857440
      RBP: ffffa99d02727018 R08: 0000000000000002 R09: 000000000002a600
      R10: ffffe90610193680 R11: 00000000000005e3 R12: 000000000000005d
      R13: ffff976ac4b201b8 R14: 0000000000000001 R15: 0000000000000000
      FS:  00007f14f99e1680(0000) GS:ffff976acc840000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fdf212843b8 CR3: 0000000408906000 CR4: 00000000003406e0
      Call Trace:
       core_link_enable_stream+0x626/0x680 [amdgpu]
       dce110_apply_ctx_to_hw+0x414/0x4e0 [amdgpu]
       dc_commit_state+0x331/0x5e0 [amdgpu]
       ? drm_calc_timestamping_constants+0xf9/0x150 [drm]
       amdgpu_dm_atomic_commit_tail+0x395/0x1e00 [amdgpu]
       ? dm_plane_helper_prepare_fb+0x20c/0x280 [amdgpu]
       commit_tail+0x42/0x70 [drm_kms_helper]
       drm_atomic_helper_commit+0x10c/0x120 [drm_kms_helper]
       amdgpu_dm_atomic_commit+0x95/0xa0 [amdgpu]
       drm_atomic_commit+0x4a/0x50 [drm]
       restore_fbdev_mode_atomic+0x1c0/0x1e0 [drm_kms_helper]
       restore_fbdev_mode+0x4c/0x160 [drm_kms_helper]
       ? _cond_resched+0x19/0x40
       drm_fb_helper_restore_fbdev_mode_unlocked+0x4e/0xa0 [drm_kms_helper]
       drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
       fbcon_init+0x471/0x630
       visual_init+0xd5/0x130
       do_bind_con_driver+0x20a/0x430
       do_take_over_console+0x7d/0x1b0
       do_fbcon_takeover+0x5c/0xb0
       fbcon_event_notify+0x6cd/0x8a0
       notifier_call_chain+0x4c/0x70
       blocking_notifier_call_chain+0x43/0x60
       fb_notifier_call_chain+0x1b/0x20
       register_framebuffer+0x254/0x360
       __drm_fb_helper_initial_config_and_unlock+0x2c5/0x510 [drm_kms_helper]
       drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper]
       amdgpu_fbdev_init+0xcd/0x100 [amdgpu]
       amdgpu_device_init+0x1156/0x1930 [amdgpu]
       amdgpu_driver_load_kms+0x8d/0x2e0 [amdgpu]
       drm_dev_register+0x12b/0x1c0 [drm]
       amdgpu_pci_probe+0xd3/0x160 [amdgpu]
       local_pci_probe+0x47/0xa0
       pci_device_probe+0x142/0x1b0
       really_probe+0xf5/0x3d0
       driver_probe_device+0x11b/0x130
       device_driver_attach+0x58/0x60
       __driver_attach+0xa3/0x140
       ? device_driver_attach+0x60/0x60
       ? device_driver_attach+0x60/0x60
       bus_for_each_dev+0x74/0xb0
       ? kmem_cache_alloc_trace+0x1a3/0x1c0
       driver_attach+0x1e/0x20
       bus_add_driver+0x147/0x220
       ? 0xffffffffc0cb9000
       driver_register+0x60/0x100
       ? 0xffffffffc0cb9000
       __pci_register_driver+0x5a/0x60
       amdgpu_init+0x74/0x83 [amdgpu]
       do_one_initcall+0x4a/0x1fa
       ? _cond_resched+0x19/0x40
       ? kmem_cache_alloc_trace+0x3f/0x1c0
       ? __vunmap+0x1cc/0x200
       do_init_module+0x5f/0x227
       load_module+0x2330/0x2b40
       __do_sys_finit_module+0xfc/0x120
       ? __do_sys_finit_module+0xfc/0x120
       __x64_sys_finit_module+0x1a/0x20
       do_syscall_64+0x5a/0x130
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7f14f9500839
      Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89
      f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
      f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
      RSP: 002b:00007fff9bc4f5a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000055afb5abce30 RCX: 00007f14f9500839
      RDX: 0000000000000000 RSI: 000055afb5ace0f0 RDI: 0000000000000017
      RBP: 000055afb5ace0f0 R08: 0000000000000000 R09: 000000000000000a
      R10: 0000000000000017 R11: 0000000000000246 R12: 0000000000000000
      R13: 000055afb5aad800 R14: 0000000000020000 R15: 0000000000000000
      ---[ end trace c286e96563966f08 ]---
      
      This commit reworks the way that we handle i2c write for retimer in the
      way that we abort this configuration if the feature is not available in
      the device. For debug sake, we kept a simple log message in case the
      retimer is not available.
      Signed-off-by: default avatarRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
      Reviewed-by: default avatarHersen Wu <hersenxs.wu@amd.com>
      Acked-by: default avatarRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      47721e8f
    • John Clements's avatar
      drm/amdgpu: increase atombios cmd timeout · e5bc081a
      John Clements authored
      [ Upstream commit 1b3460a8 ]
      
      mitigates race condition on BACO reset between GPU bootcode and driver reload
      Reviewed-by: default avatarHawking Zhang <Hawking.Zhang@amd.com>
      Signed-off-by: default avatarJohn Clements <john.clements@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e5bc081a