1. 22 Jun, 2019 40 commits
    • Jason Yan's avatar
      scsi: libsas: delete sas port if expander discover failed · 114e8135
      Jason Yan authored
      [ Upstream commit 3b054179 ]
      
      The sas_port(phy->port) allocated in sas_ex_discover_expander() will not be
      deleted when the expander failed to discover. This will cause resource leak
      and a further issue of kernel BUG like below:
      
      [159785.843156]  port-2:17:29: trying to add phy phy-2:17:29 fails: it's
      already part of another port
      [159785.852144] ------------[ cut here  ]------------
      [159785.856833] kernel BUG at drivers/scsi/scsi_transport_sas.c:1086!
      [159785.863000] Internal error: Oops - BUG: 0 [#1] SMP
      [159785.867866] CPU: 39 PID: 16993 Comm: kworker/u96:2 Tainted: G
      W  OE     4.19.25-vhulk1901.1.0.h111.aarch64 #1
      [159785.878458] Hardware name: Huawei Technologies Co., Ltd.
      Hi1620EVBCS/Hi1620EVBCS, BIOS Hi1620 CS B070 1P TA 03/21/2019
      [159785.889231] Workqueue: 0000:74:02.0_disco_q sas_discover_domain
      [159785.895224] pstate: 40c00009 (nZcv daif +PAN +UAO)
      [159785.900094] pc : sas_port_add_phy+0x188/0x1b8
      [159785.904524] lr : sas_port_add_phy+0x188/0x1b8
      [159785.908952] sp : ffff0001120e3b80
      [159785.912341] x29: ffff0001120e3b80 x28: 0000000000000000
      [159785.917727] x27: ffff802ade8f5400 x26: ffff0000681b7560
      [159785.923111] x25: ffff802adf11a800 x24: ffff0000680e8000
      [159785.928496] x23: ffff802ade8f5728 x22: ffff802ade8f5708
      [159785.933880] x21: ffff802adea2db40 x20: ffff802ade8f5400
      [159785.939264] x19: ffff802adea2d800 x18: 0000000000000010
      [159785.944649] x17: 00000000821bf734 x16: ffff00006714faa0
      [159785.950033] x15: ffff0000e8ab4ecf x14: 7261702079646165
      [159785.955417] x13: 726c612073277469 x12: ffff00006887b830
      [159785.960802] x11: ffff00006773eaa0 x10: 7968702079687020
      [159785.966186] x9 : 0000000000002453 x8 : 726f702072656874
      [159785.971570] x7 : 6f6e6120666f2074 x6 : ffff802bcfb21290
      [159785.976955] x5 : ffff802bcfb21290 x4 : 0000000000000000
      [159785.982339] x3 : ffff802bcfb298c8 x2 : 337752b234c2ab00
      [159785.987723] x1 : 337752b234c2ab00 x0 : 0000000000000000
      [159785.993108] Process kworker/u96:2 (pid: 16993, stack limit =
      0x0000000072dae094)
      [159786.000576] Call trace:
      [159786.003097]  sas_port_add_phy+0x188/0x1b8
      [159786.007179]  sas_ex_get_linkrate.isra.5+0x134/0x140
      [159786.012130]  sas_ex_discover_expander+0x128/0x408
      [159786.016906]  sas_ex_discover_dev+0x218/0x4c8
      [159786.021249]  sas_ex_discover_devices+0x9c/0x1a8
      [159786.025852]  sas_discover_root_expander+0x134/0x160
      [159786.030802]  sas_discover_domain+0x1b8/0x1e8
      [159786.035148]  process_one_work+0x1b4/0x3f8
      [159786.039230]  worker_thread+0x54/0x470
      [159786.042967]  kthread+0x134/0x138
      [159786.046269]  ret_from_fork+0x10/0x18
      [159786.049918] Code: 91322300 f0004402 91178042 97fe4c9b (d4210000)
      [159786.056083] Modules linked in: hns3_enet_ut(OE) hclge(OE) hnae3(OE)
      hisi_sas_test_hw(OE) hisi_sas_test_main(OE) serdes(OE)
      [159786.067202] ---[ end trace 03622b9e2d99e196  ]---
      [159786.071893] Kernel panic - not syncing: Fatal exception
      [159786.077190] SMP: stopping secondary CPUs
      [159786.081192] Kernel Offset: disabled
      [159786.084753] CPU features: 0x2,a2a00a38
      
      Fixes: 2908d778
      
       ("[SCSI] aic94xx: new driver")
      Reported-by: default avatarJian Luo <luojian5@huawei.com>
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      CC: John Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      114e8135
    • YueHaibing's avatar
      scsi: scsi_dh_alua: Fix possible null-ptr-deref · 89ede9d8
      YueHaibing authored
      [ Upstream commit 12e750bc
      
       ]
      
      If alloc_workqueue fails in alua_init, it should return -ENOMEM, otherwise
      it will trigger null-ptr-deref while unloading module which calls
      destroy_workqueue dereference
      wq->lock like this:
      
      BUG: KASAN: null-ptr-deref in __lock_acquire+0x6b4/0x1ee0
      Read of size 8 at addr 0000000000000080 by task syz-executor.0/7045
      
      CPU: 0 PID: 7045 Comm: syz-executor.0 Tainted: G         C        5.1.0+ #28
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
      Call Trace:
       dump_stack+0xa9/0x10e
       __kasan_report+0x171/0x18d
       ? __lock_acquire+0x6b4/0x1ee0
       kasan_report+0xe/0x20
       __lock_acquire+0x6b4/0x1ee0
       lock_acquire+0xb4/0x1b0
       __mutex_lock+0xd8/0xb90
       drain_workqueue+0x25/0x290
       destroy_workqueue+0x1f/0x3f0
       __x64_sys_delete_module+0x244/0x330
       do_syscall_64+0x72/0x2a0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 03197b61
      
       ("scsi_dh_alua: Use workqueue for RTPG")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      89ede9d8
    • Lianbo Jiang's avatar
      scsi: smartpqi: properly set both the DMA mask and the coherent DMA mask · cb7c6c33
      Lianbo Jiang authored
      [ Upstream commit 1d94f06e
      
       ]
      
      When SME is enabled, the smartpqi driver won't work on the HP DL385 G10
      machine, which causes the failure of kernel boot because it fails to
      allocate pqi error buffer. Please refer to the kernel log:
      ....
      [    9.431749] usbcore: registered new interface driver uas
      [    9.441524] Microsemi PQI Driver (v1.1.4-130)
      [    9.442956] i40e 0000:04:00.0: fw 6.70.48768 api 1.7 nvm 10.2.5
      [    9.447237] smartpqi 0000:23:00.0: Microsemi Smart Family Controller found
               Starting dracut initqueue hook...
      [  OK  ] Started Show Plymouth Boot Scre[    9.471654] Broadcom NetXtreme-C/E driver bnxt_en v1.9.1
      en.
      [  OK  ] Started Forward Password Requests to Plymouth Directory Watch.
      [[0;[    9.487108] smartpqi 0000:23:00.0: failed to allocate PQI error buffer
      ....
      [  139.050544] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts
      [  139.589779] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts
      
      Basically, the fact that the coherent DMA mask value wasn't set caused the
      driver to fall back to SWIOTLB when SME is active.
      
      For correct operation, lets call the dma_set_mask_and_coherent() to
      properly set the mask for both streaming and coherent, in order to inform
      the kernel about the devices DMA addressing capabilities.
      Signed-off-by: default avatarLianbo Jiang <lijiang@redhat.com>
      Acked-by: default avatarDon Brace <don.brace@microsemi.com>
      Tested-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>
      cb7c6c33
    • Varun Prakash's avatar
      scsi: libcxgbi: add a check for NULL pointer in cxgbi_check_route() · 214c5933
      Varun Prakash authored
      [ Upstream commit cc555759
      
       ]
      
      ip_dev_find() can return NULL so add a check for NULL pointer.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      214c5933
    • Max Uvarov's avatar
      net: phy: dp83867: Set up RGMII TX delay · 7b9e1094
      Max Uvarov authored
      [ Upstream commit 2b892649 ]
      
      PHY_INTERFACE_MODE_RGMII_RXID is less then TXID
      so code to set tx delay is never called.
      
      Fixes: 2a10154a
      
       ("net: phy: dp83867: Add TI dp83867 phy")
      Signed-off-by: default avatarMax Uvarov <muvarov@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7b9e1094
    • Russell King's avatar
      net: phylink: ensure consistent phy interface mode · 7698ad8c
      Russell King authored
      [ Upstream commit c6787263
      
       ]
      
      Ensure that we supply the same phy interface mode to mac_link_down() as
      we did for the corresponding mac_link_up() call.  This ensures that MAC
      drivers that use the phy interface mode in these methods can depend on
      mac_link_down() always corresponding to a mac_link_up() call for the
      same interface mode.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7698ad8c
    • Yoshihiro Shimoda's avatar
      net: sh_eth: fix mdio access in sh_eth_close() for R-Car Gen2 and RZ/A1 SoCs · 8fb2c796
      Yoshihiro Shimoda authored
      [ Upstream commit 315ca92d
      
       ]
      
      The sh_eth_close() resets the MAC and then calls phy_stop()
      so that mdio read access result is incorrect without any error
      according to kernel trace like below:
      
      ifconfig-216   [003] .n..   109.133124: mdio_access: ee700000.ethernet-ffffffff read  phy:0x01 reg:0x00 val:0xffff
      
      According to the hardware manual, the RMII mode should be set to 1
      before operation the Ethernet MAC. However, the previous code was not
      set to 1 after the driver issued the soft_reset in sh_eth_dev_exit()
      so that the mdio read access result seemed incorrect. To fix the issue,
      this patch adds a condition and set the RMII mode register in
      sh_eth_dev_exit() for R-Car Gen2 and RZ/A1 SoCs.
      
      Note that when I have tried to move the sh_eth_dev_exit() calling
      after phy_stop() on sh_eth_close(), but it gets worse (kernel panic
      happened and it seems that a register is accessed while the clock is
      off).
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8fb2c796
    • Sami Tolvanen's avatar
      arm64: use the correct function type for __arm64_sys_ni_syscall · 467f9026
      Sami Tolvanen authored
      [ Upstream commit 1e29ab31
      
       ]
      
      Calling sys_ni_syscall through a syscall_fn_t pointer trips indirect
      call Control-Flow Integrity checking due to a function type
      mismatch. Use SYSCALL_DEFINE0 for __arm64_sys_ni_syscall instead and
      remove the now unnecessary casts.
      Signed-off-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      467f9026
    • Sami Tolvanen's avatar
      arm64: use the correct function type in SYSCALL_DEFINE0 · 98fd62e0
      Sami Tolvanen authored
      [ Upstream commit 0e358bd7
      
       ]
      
      Although a syscall defined using SYSCALL_DEFINE0 doesn't accept
      parameters, use the correct function type to avoid indirect call
      type mismatches with Control-Flow Integrity checking.
      Signed-off-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      98fd62e0
    • Sami Tolvanen's avatar
      arm64: fix syscall_fn_t type · c5fdfaed
      Sami Tolvanen authored
      [ Upstream commit 8ef8f368
      
       ]
      
      Syscall wrappers in <asm/syscall_wrapper.h> use const struct pt_regs *
      as the argument type. Use const in syscall_fn_t as well to fix indirect
      call type mismatches with Control-Flow Integrity checking.
      Signed-off-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c5fdfaed
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Don't take kvm->lock around kvm_for_each_vcpu · df6384e0
      Paul Mackerras authored
      [ Upstream commit 5a3f4936
      
       ]
      
      Currently the HV KVM code takes the kvm->lock around calls to
      kvm_for_each_vcpu() and kvm_get_vcpu_by_id() (which can call
      kvm_for_each_vcpu() internally).  However, that leads to a lock
      order inversion problem, because these are called in contexts where
      the vcpu mutex is held, but the vcpu mutexes nest within kvm->lock
      according to Documentation/virtual/kvm/locking.txt.  Hence there
      is a possibility of deadlock.
      
      To fix this, we simply don't take the kvm->lock mutex around these
      calls.  This is safe because the implementations of kvm_for_each_vcpu()
      and kvm_get_vcpu_by_id() have been designed to be able to be called
      locklessly.
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Reviewed-by: default avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      df6384e0
    • Paul Mackerras's avatar
      KVM: PPC: Book3S: Use new mutex to synchronize access to rtas token list · b376683f
      Paul Mackerras authored
      [ Upstream commit 1659e27d
      
       ]
      
      Currently the Book 3S KVM code uses kvm->lock to synchronize access
      to the kvm->arch.rtas_tokens list.  Because this list is scanned
      inside kvmppc_rtas_hcall(), which is called with the vcpu mutex held,
      taking kvm->lock cause a lock inversion problem, which could lead to
      a deadlock.
      
      To fix this, we add a new mutex, kvm->arch.rtas_token_lock, which nests
      inside the vcpu mutexes, and use that instead of kvm->lock when
      accessing the rtas token list.
      
      This removes the lockdep_assert_held() in kvmppc_rtas_tokens_free().
      At this point we don't hold the new mutex, but that is OK because
      kvmppc_rtas_tokens_free() is only called when the whole VM is being
      destroyed, and at that point nothing can be looking up a token in
      the list.
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b376683f
    • Ross Lagerwall's avatar
      xenbus: Avoid deadlock during suspend due to open transactions · 4acce744
      Ross Lagerwall authored
      [ Upstream commit d10e0cc1
      
       ]
      
      During a suspend/resume, the xenwatch thread waits for all outstanding
      xenstore requests and transactions to complete. This does not work
      correctly for transactions started by userspace because it waits for
      them to complete after freezing userspace threads which means the
      transactions have no way of completing, resulting in a deadlock. This is
      trivial to reproduce by running this script and then suspending the VM:
      
          import pyxs, time
          c = pyxs.client.Client(xen_bus_path="/dev/xen/xenbus")
          c.connect()
          c.transaction()
          time.sleep(3600)
      
      Even if this deadlock were resolved, misbehaving userspace should not
      prevent a VM from being migrated. So, instead of waiting for these
      transactions to complete before suspending, store the current generation
      id for each transaction when it is started. The global generation id is
      incremented during resume. If the caller commits the transaction and the
      generation id does not match the current generation id, return EAGAIN so
      that they try again. If the transaction was instead discarded, return OK
      since no changes were made anyway.
      
      This only affects users of the xenbus file interface. In-kernel users of
      xenbus are assumed to be well-behaved and complete all transactions
      before freezing.
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.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>
      4acce744
    • YueHaibing's avatar
      xen/pvcalls: Remove set but not used variable · 66f33b2b
      YueHaibing authored
      [ Upstream commit 41349672
      
       ]
      
      Fixes gcc '-Wunused-but-set-variable' warning:
      
      drivers/xen/pvcalls-front.c: In function pvcalls_front_sendmsg:
      drivers/xen/pvcalls-front.c:543:25: warning: variable bedata set but not used [-Wunused-but-set-variable]
      drivers/xen/pvcalls-front.c: In function pvcalls_front_recvmsg:
      drivers/xen/pvcalls-front.c:638:25: warning: variable bedata set but not used [-Wunused-but-set-variable]
      
      They are never used since introduction.
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.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>
      66f33b2b
    • Randy Dunlap's avatar
      ia64: fix build errors by exporting paddr_to_nid() · d92ebe0c
      Randy Dunlap authored
      [ Upstream commit 9a626c4a
      
       ]
      
      Fix build errors on ia64 when DISCONTIGMEM=y and NUMA=y by
      exporting paddr_to_nid().
      
      Fixes these build errors:
      
      ERROR: "paddr_to_nid" [sound/core/snd-pcm.ko] undefined!
      ERROR: "paddr_to_nid" [net/sunrpc/sunrpc.ko] undefined!
      ERROR: "paddr_to_nid" [fs/cifs/cifs.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/video/fbdev/core/fb.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/usb/mon/usbmon.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/usb/core/usbcore.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/raid1.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/dm-mod.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/dm-crypt.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/dm-bufio.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/ide/ide-core.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/ide/ide-cd_mod.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/gpu/drm/drm.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/char/agp/agpgart.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/block/nbd.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/block/loop.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/block/brd.ko] undefined!
      ERROR: "paddr_to_nid" [crypto/ccm.ko] undefined!
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d92ebe0c
    • Thomas Richter's avatar
      perf record: Fix s390 missing module symbol and warning for non-root users · 60a3e3b9
      Thomas Richter authored
      [ Upstream commit 6738028d
      
       ]
      
      Command 'perf record' and 'perf report' on a system without kernel
      debuginfo packages uses /proc/kallsyms and /proc/modules to find
      addresses for kernel and module symbols. On x86 this works for root and
      non-root users.
      
      On s390, when invoked as non-root user, many of the following warnings
      are shown and module symbols are missing:
      
          proc/{kallsyms,modules} inconsistency while looking for
              "[sha1_s390]" module!
      
      Command 'perf record' creates a list of module start addresses by
      parsing the output of /proc/modules and creates a PERF_RECORD_MMAP
      record for the kernel and each module. The following function call
      sequence is executed:
      
        machine__create_kernel_maps
          machine__create_module
            modules__parse
              machine__create_module --> for each line in /proc/modules
                arch__fix_module_text_start
      
      Function arch__fix_module_text_start() is s390 specific. It opens
      file /sys/module/<name>/sections/.text to extract the module's .text
      section start address. On s390 the module loader prepends a header
      before the first section, whereas on x86 the module's text section
      address is identical the the module's load address.
      
      However module section files are root readable only. For non-root the
      read operation fails and machine__create_module() returns an error.
      Command perf record does not generate any PERF_RECORD_MMAP record
      for loaded modules. Later command perf report complains about missing
      module maps.
      
      To fix this function arch__fix_module_text_start() always returns
      success. For root users there is no change, for non-root users
      the module's load address is used as module's text start address
      (the prepended header then counts as part of the text section).
      
      This enable non-root users to use module symbols and avoid the
      warning when perf report is executed.
      
      Output before:
      
        [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP
        0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text
      
      Output after:
      
        [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP
        0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text
        0 0x1b8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../autofs4.ko.xz
        0 0x250 [0xa8]: PERF_RECORD_MMAP ... x /lib/modules/.../sha_common.ko.xz
        0 0x2f8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../des_generic.ko.xz
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Link: http://lkml.kernel.org/r/20190522144601.50763-4-tmricht@linux.ibm.com
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      60a3e3b9
    • Namhyung Kim's avatar
      perf namespace: Protect reading thread's namespace · be0e6266
      Namhyung Kim authored
      [ Upstream commit 6584140b
      
       ]
      
      It seems that the current code lacks holding the namespace lock in
      thread__namespaces().  Otherwise it can see inconsistent results.
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Krister Johansen <kjlx@templeofstupid.com>
      Link: http://lkml.kernel.org/r/20190522053250.207156-2-namhyung@kernel.org
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      be0e6266
    • Shawn Landden's avatar
      perf data: Fix 'strncat may truncate' build failure with recent gcc · 7d523e33
      Shawn Landden authored
      [ Upstream commit 97acec7d
      
       ]
      
      This strncat() is safe because the buffer was allocated with zalloc(),
      however gcc doesn't know that. Since the string always has 4 non-null
      bytes, just use memcpy() here.
      
          CC       /home/shawn/linux/tools/perf/util/data-convert-bt.o
        In file included from /usr/include/string.h:494,
                         from /home/shawn/linux/tools/lib/traceevent/event-parse.h:27,
                         from util/data-convert-bt.c:22:
        In function ‘strncat’,
            inlined from ‘string_set_value’ at util/data-convert-bt.c:274:4:
        /usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation]
          136 |   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
              |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: default avatarShawn Landden <shawn@git.icu>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      LPU-Reference: 20190518183238.10954-1-shawn@git.icu
      Link: https://lkml.kernel.org/n/tip-289f1jice17ta7tr3tstm9jm@git.kernel.org
      
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7d523e33
    • Sahitya Tummala's avatar
      configfs: Fix use-after-free when accessing sd->s_dentry · e9fcebe0
      Sahitya Tummala authored
      [ Upstream commit f6122ed2 ]
      
      In the vfs_statx() context, during path lookup, the dentry gets
      added to sd->s_dentry via configfs_attach_attr(). In the end,
      vfs_statx() kills the dentry by calling path_put(), which invokes
      configfs_d_iput(). Ideally, this dentry must be removed from
      sd->s_dentry but it doesn't if the sd->s_count >= 3. As a result,
      sd->s_dentry is holding reference to a stale dentry pointer whose
      memory is already freed up. This results in use-after-free issue,
      when this stale sd->s_dentry is accessed later in
      configfs_readdir() path.
      
      This issue can be easily reproduced, by running the LTP test case -
      sh fs_racer_file_list.sh /config
      (https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh)
      
      Fixes: 76ae281f
      
       ('configfs: fix race between dentry put and lookup')
      Signed-off-by: default avatarSahitya Tummala <stummala@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e9fcebe0
    • Bard Liao's avatar
      ALSA: hda - Force polling mode on CNL for fixing codec communication · ab7a3d9a
      Bard Liao authored
      [ Upstream commit fa763f1b ]
      
      We observed the same issue as reported by commit a8d7bde2
      
      
      ("ALSA: hda - Force polling mode on CFL for fixing codec communication")
      We don't have a better solution. So apply the same workaround to CNL.
      Signed-off-by: default avatarBard Liao <yung-chuan.liao@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ab7a3d9a
    • Yingjoe Chen's avatar
      i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwr · 7bea5618
      Yingjoe Chen authored
      [ Upstream commit a0692f0e ]
      
      If I2C_M_RECV_LEN check failed, msgs[i].buf allocated by memdup_user
      will not be freed. Pump index up so it will be freed.
      
      Fixes: 838bfa60
      
       ("i2c-dev: Add support for I2C_M_RECV_LEN")
      Signed-off-by: default avatarYingjoe Chen <yingjoe.chen@mediatek.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7bea5618
    • Dmitry Bogdanov's avatar
      net: aquantia: fix LRO with FCS error · 197501af
      Dmitry Bogdanov authored
      [ Upstream commit eaeb3b74 ]
      
      Driver stops producing skbs on ring if a packet with FCS error
      was coalesced into LRO session. Ring gets hang forever.
      
      Thats a logical error in driver processing descriptors:
      When rx_stat indicates MAC Error, next pointer and eop flags
      are not filled. This confuses driver so it waits for descriptor 0
      to be filled by HW.
      
      Solution is fill next pointer and eop flag even for packets with FCS error.
      
      Fixes: bab6de8f
      
       ("net: ethernet: aquantia: Atlantic A0 and B0 specific functions.")
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDmitry Bogdanov <dmitry.bogdanov@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      197501af
    • Igor Russkikh's avatar
      net: aquantia: tx clean budget logic error · 388534d4
      Igor Russkikh authored
      [ Upstream commit 31bafc49 ]
      
      In case no other traffic happening on the ring, full tx cleanup
      may not be completed. That may cause socket buffer to overflow
      and tx traffic to stuck until next activity on the ring happens.
      
      This is due to logic error in budget variable decrementor.
      Variable is compared with zero, and then post decremented,
      causing it to become MAX_INT. Solution is remove decrementor
      from the `for` statement and rewrite it in a clear way.
      
      Fixes: b647d398
      
       ("net: aquantia: Add tx clean budget and valid budget handling logic")
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      388534d4
    • Lucas Stach's avatar
      drm/etnaviv: lock MMU while dumping core · b7ca3f33
      Lucas Stach authored
      [ Upstream commit 1396500d ]
      
      The devcoredump needs to operate on a stable state of the MMU while
      it is writing the MMU state to the coredump. The missing lock
      allowed both the userspace submit, as well as the GPU job finish
      paths to mutate the MMU state while a coredump is under way.
      
      Fixes: a8c21a54
      
       (drm/etnaviv: add initial etnaviv DRM driver)
      Reported-by: default avatarDavid Jander <david@protonic.nl>
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Tested-by: default avatarDavid Jander <david@protonic.nl>
      Reviewed-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b7ca3f33
    • Rafael J. Wysocki's avatar
      ACPI/PCI: PM: Add missing wakeup.flags.valid checks · ee61fb4d
      Rafael J. Wysocki authored
      [ Upstream commit 9a51c6b1
      
       ]
      
      Both acpi_pci_need_resume() and acpi_dev_needs_resume() check if the
      current ACPI wakeup configuration of the device matches what is
      expected as far as system wakeup from sleep states is concerned, as
      reflected by the device_may_wakeup() return value for the device.
      
      However, they only should do that if wakeup.flags.valid is set for
      the device's ACPI companion, because otherwise the wakeup.prepare_count
      value for it is meaningless.
      
      Add the missing wakeup.flags.valid checks to these functions.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ee61fb4d
    • Kees Cook's avatar
      net: tulip: de4x5: Drop redundant MODULE_DEVICE_TABLE() · bc19b50b
      Kees Cook authored
      [ Upstream commit 3e66b7cc ]
      
      Building with Clang reports the redundant use of MODULE_DEVICE_TABLE():
      
      drivers/net/ethernet/dec/tulip/de4x5.c:2110:1: error: redefinition of '__mod_eisa__de4x5_eisa_ids_device_table'
      MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
      ^
      ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
      extern typeof(name) __mod_##type##__##name##_device_table               \
                          ^
      <scratch space>:90:1: note: expanded from here
      __mod_eisa__de4x5_eisa_ids_device_table
      ^
      drivers/net/ethernet/dec/tulip/de4x5.c:2100:1: note: previous definition is here
      MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
      ^
      ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
      extern typeof(name) __mod_##type##__##name##_device_table               \
                          ^
      <scratch space>:85:1: note: expanded from here
      __mod_eisa__de4x5_eisa_ids_device_table
      ^
      
      This drops the one further from the table definition to match the common
      use of MODULE_DEVICE_TABLE().
      
      Fixes: 07563c71
      
       ("EISA bus MODALIAS attributes support")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bc19b50b
    • Biao Huang's avatar
      net: stmmac: update rx tail pointer register to fix rx dma hang issue. · 9a3208b6
      Biao Huang authored
      [ Upstream commit 4523a561 ]
      
      Currently we will not update the receive descriptor tail pointer in
      stmmac_rx_refill. Rx dma will think no available descriptors and stop
      once received packets exceed DMA_RX_SIZE, so that the rx only test will fail.
      
      Update the receive tail pointer in stmmac_rx_refill to add more descriptors
      to the rx channel, so packets can be received continually
      
      Fixes: 54139cf3
      
       ("net: stmmac: adding multiple buffers for rx")
      Signed-off-by: default avatarBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9a3208b6
    • Randy Dunlap's avatar
      gpio: fix gpio-adp5588 build errors · 3fbcef33
      Randy Dunlap authored
      [ Upstream commit e9646f0f ]
      
      The gpio-adp5588 driver uses interfaces that are provided by
      GPIOLIB_IRQCHIP, so select that symbol in its Kconfig entry.
      
      Fixes these build errors:
      
      ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_handler’:
      ../drivers/gpio/gpio-adp5588.c:266:26: error: ‘struct gpio_chip’ has no member named ‘irq’
                  dev->gpio_chip.irq.domain, gpio));
                                ^
      ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_setup’:
      ../drivers/gpio/gpio-adp5588.c:298:2: error: implicit declaration of function ‘gpiochip_irqchip_add_nested’ [-Werror=implicit-function-declaration]
        ret = gpiochip_irqchip_add_nested(&dev->gpio_chip,
        ^
      ../drivers/gpio/gpio-adp5588.c:307:2: error: implicit declaration of function ‘gpiochip_set_nested_irqchip’ [-Werror=implicit-function-declaration]
        gpiochip_set_nested_irqchip(&dev->gpio_chip,
        ^
      
      Fixes: 459773ae
      
       ("gpio: adp5588-gpio: support interrupt controller")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: linux-gpio@vger.kernel.org
      Reviewed-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Acked-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3fbcef33
    • Peter Zijlstra's avatar
      perf/ring-buffer: Always use {READ,WRITE}_ONCE() for rb->user_page data · 991ea848
      Peter Zijlstra authored
      [ Upstream commit 4d839dd9
      
       ]
      
      We must use {READ,WRITE}_ONCE() on rb->user_page data such that
      concurrent usage will see whole values. A few key sites were missing
      this.
      Suggested-by: default avatarYabin Cui <yabinc@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: acme@kernel.org
      Cc: mark.rutland@arm.com
      Cc: namhyung@kernel.org
      Fixes: 7b732a75 ("perf_counter: new output ABI - part 1")
      Link: http://lkml.kernel.org/r/20190517115418.394192145@infradead.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      991ea848
    • Peter Zijlstra's avatar
      perf/ring_buffer: Add ordering to rb->nest increment · c133c9db
      Peter Zijlstra authored
      [ Upstream commit 3f9fbe9b
      
       ]
      
      Similar to how decrementing rb->next too early can cause data_head to
      (temporarily) be observed to go backward, so too can this happen when
      we increment too late.
      
      This barrier() ensures the rb->head load happens after the increment,
      both the one in the 'goto again' path, as the one from
      perf_output_get_handle() -- albeit very unlikely to matter for the
      latter.
      Suggested-by: default avatarYabin Cui <yabinc@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: acme@kernel.org
      Cc: mark.rutland@arm.com
      Cc: namhyung@kernel.org
      Fixes: ef60777c ("perf: Optimize the perf_output() path by removing IRQ-disables")
      Link: http://lkml.kernel.org/r/20190517115418.309516009@infradead.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c133c9db
    • Yabin Cui's avatar
      perf/ring_buffer: Fix exposing a temporarily decreased data_head · cca19ab2
      Yabin Cui authored
      [ Upstream commit 1b038c6e
      
       ]
      
      In perf_output_put_handle(), an IRQ/NMI can happen in below location and
      write records to the same ring buffer:
      
      	...
      	local_dec_and_test(&rb->nest)
      	...                          <-- an IRQ/NMI can happen here
      	rb->user_page->data_head = head;
      	...
      
      In this case, a value A is written to data_head in the IRQ, then a value
      B is written to data_head after the IRQ. And A > B. As a result,
      data_head is temporarily decreased from A to B. And a reader may see
      data_head < data_tail if it read the buffer frequently enough, which
      creates unexpected behaviors.
      
      This can be fixed by moving dec(&rb->nest) to after updating data_head,
      which prevents the IRQ/NMI above from updating data_head.
      
      [ Split up by peterz. ]
      Signed-off-by: default avatarYabin Cui <yabinc@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: mark.rutland@arm.com
      Fixes: ef60777c ("perf: Optimize the perf_output() path by removing IRQ-disables")
      Link: http://lkml.kernel.org/r/20190517115418.224478157@infradead.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cca19ab2
    • Frank van der Linden's avatar
      x86/CPU/AMD: Don't force the CPB cap when running under a hypervisor · a35e7822
      Frank van der Linden authored
      [ Upstream commit 2ac44ab6
      
       ]
      
      For F17h AMD CPUs, the CPB capability ('Core Performance Boost') is forcibly set,
      because some versions of that chip incorrectly report that they do not have it.
      
      However, a hypervisor may filter out the CPB capability, for good
      reasons. For example, KVM currently does not emulate setting the CPB
      bit in MSR_K7_HWCR, and unchecked MSR access errors will be thrown
      when trying to set it as a guest:
      
      	unchecked MSR access error: WRMSR to 0xc0010015 (tried to write 0x0000000001000011) at rIP: 0xffffffff890638f4 (native_write_msr+0x4/0x20)
      
      	Call Trace:
      	boost_set_msr+0x50/0x80 [acpi_cpufreq]
      	cpuhp_invoke_callback+0x86/0x560
      	sort_range+0x20/0x20
      	cpuhp_thread_fun+0xb0/0x110
      	smpboot_thread_fn+0xef/0x160
      	kthread+0x113/0x130
      	kthread_create_worker_on_cpu+0x70/0x70
      	ret_from_fork+0x35/0x40
      
      To avoid this issue, don't forcibly set the CPB capability for a CPU
      when running under a hypervisor.
      Signed-off-by: default avatarFrank van der Linden <fllinden@amazon.com>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: bp@alien8.de
      Cc: jiaxun.yang@flygoat.com
      Fixes: 02371991 ("x86/CPU/AMD: Set the CPB bit unconditionally on F17h")
      Link: http://lkml.kernel.org/r/20190522221745.GA15789@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com
      
      
      [ Minor edits to the changelog. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a35e7822
    • Dan Carpenter's avatar
      mISDN: make sure device name is NUL terminated · 8e5666cd
      Dan Carpenter authored
      [ Upstream commit ccfb62f2
      
       ]
      
      The user can change the device_name with the IMSETDEVNAME ioctl, but we
      need to ensure that the user's name is NUL terminated.  Otherwise it
      could result in a buffer overflow when we copy the name back to the user
      with IMGETDEVINFO ioctl.
      
      I also changed two strcpy() calls which handle the name to strscpy().
      Hopefully, there aren't any other ways to create a too long name, but
      it's nice to do this as a kernel hardening measure.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8e5666cd
    • Jia-Ju Bai's avatar
      usb: xhci: Fix a potential null pointer dereference in xhci_debugfs_create_endpoint() · f3885eec
      Jia-Ju Bai authored
      [ Upstream commit 5bce256f
      
       ]
      
      In xhci_debugfs_create_slot(), kzalloc() can fail and
      dev->debugfs_private will be NULL.
      In xhci_debugfs_create_endpoint(), dev->debugfs_private is used without
      any null-pointer check, and can cause a null pointer dereference.
      
      To fix this bug, a null-pointer check is added in
      xhci_debugfs_create_endpoint().
      
      This bug is found by a runtime fuzzing tool named FIZZER written by us.
      
      [subjet line change change, add potential -Mathais]
      Signed-off-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f3885eec
    • Anju T Sudhakar's avatar
      powerpc/powernv: Return for invalid IMC domain · 930d31a6
      Anju T Sudhakar authored
      [ Upstream commit b59bd352 ]
      
      Currently init_imc_pmu() can fail either because we try to register an
      IMC unit with an invalid domain (i.e an IMC node not supported by the
      kernel) or something went wrong while registering a valid IMC unit. In
      both the cases kernel provides a 'Register failed' error message.
      
      For example when trace-imc node is not supported by the kernel, but
      skiboot advertises a trace-imc node we print:
      
        IMC Unknown Device type
        IMC PMU (null) Register failed
      
      To avoid confusion just print the unknown device type message, before
      attempting PMU registration, so the second message isn't printed.
      
      Fixes: 8f95faaa
      
       ("powerpc/powernv: Detect and create IMC device")
      Reported-by: default avatarPavaman Subramaniyam <pavsubra@in.ibm.com>
      Signed-off-by: default avatarAnju T Sudhakar <anju@linux.vnet.ibm.com>
      Reviewed-by: default avatarMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      [mpe: Reword change log a bit]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      930d31a6
    • Tony Lindgren's avatar
      clk: ti: clkctrl: Fix clkdm_clk handling · 00ed897d
      Tony Lindgren authored
      [ Upstream commit 1cc54078 ]
      
      We need to always call clkdm_clk_enable() and clkdm_clk_disable() even
      the clkctrl clock(s) enabled for the domain do not have any gate register
      bits. Otherwise clockdomains may never get enabled except when devices get
      probed with the legacy "ti,hwmods" devicetree property.
      
      Fixes: 88a17252
      
       ("clk: ti: add support for clkctrl clocks")
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      00ed897d
    • Jeffrin Jose T's avatar
      selftests: netfilter: missing error check when setting up veth interface · ef4ffa0f
      Jeffrin Jose T authored
      [ Upstream commit 82ce6eb1
      
       ]
      
      A test for the basic NAT functionality uses ip command which needs veth
      device. There is a condition where the kernel support for veth is not
      compiled into the kernel and the test script breaks. This patch contains
      code for reasonable error display and correct code exit.
      Signed-off-by: default avatarJeffrin Jose T <jeffrin@rajagiritech.edu.in>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ef4ffa0f
    • YueHaibing's avatar
      ipvs: Fix use-after-free in ip_vs_in · 61c83de6
      YueHaibing authored
      [ Upstream commit 719c7d56
      
       ]
      
      BUG: KASAN: use-after-free in ip_vs_in.part.29+0xe8/0xd20 [ip_vs]
      Read of size 4 at addr ffff8881e9b26e2c by task sshd/5603
      
      CPU: 0 PID: 5603 Comm: sshd Not tainted 4.19.39+ #30
      Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      Call Trace:
       dump_stack+0x71/0xab
       print_address_description+0x6a/0x270
       kasan_report+0x179/0x2c0
       ip_vs_in.part.29+0xe8/0xd20 [ip_vs]
       ip_vs_in+0xd8/0x170 [ip_vs]
       nf_hook_slow+0x5f/0xe0
       __ip_local_out+0x1d5/0x250
       ip_local_out+0x19/0x60
       __tcp_transmit_skb+0xba1/0x14f0
       tcp_write_xmit+0x41f/0x1ed0
       ? _copy_from_iter_full+0xca/0x340
       __tcp_push_pending_frames+0x52/0x140
       tcp_sendmsg_locked+0x787/0x1600
       ? tcp_sendpage+0x60/0x60
       ? inet_sk_set_state+0xb0/0xb0
       tcp_sendmsg+0x27/0x40
       sock_sendmsg+0x6d/0x80
       sock_write_iter+0x121/0x1c0
       ? sock_sendmsg+0x80/0x80
       __vfs_write+0x23e/0x370
       vfs_write+0xe7/0x230
       ksys_write+0xa1/0x120
       ? __ia32_sys_read+0x50/0x50
       ? __audit_syscall_exit+0x3ce/0x450
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7ff6f6147c60
      Code: 73 01 c3 48 8b 0d 28 12 2d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 5d 73 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83
      RSP: 002b:00007ffd772ead18 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000034 RCX: 00007ff6f6147c60
      RDX: 0000000000000034 RSI: 000055df30a31270 RDI: 0000000000000003
      RBP: 000055df30a31270 R08: 0000000000000000 R09: 0000000000000000
      R10: 00007ffd772ead70 R11: 0000000000000246 R12: 00007ffd772ead74
      R13: 00007ffd772eae20 R14: 00007ffd772eae24 R15: 000055df2f12ddc0
      
      Allocated by task 6052:
       kasan_kmalloc+0xa0/0xd0
       __kmalloc+0x10a/0x220
       ops_init+0x97/0x190
       register_pernet_operations+0x1ac/0x360
       register_pernet_subsys+0x24/0x40
       0xffffffffc0ea016d
       do_one_initcall+0x8b/0x253
       do_init_module+0xe3/0x335
       load_module+0x2fc0/0x3890
       __do_sys_finit_module+0x192/0x1c0
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 6067:
       __kasan_slab_free+0x130/0x180
       kfree+0x90/0x1a0
       ops_free_list.part.7+0xa6/0xc0
       unregister_pernet_operations+0x18b/0x1f0
       unregister_pernet_subsys+0x1d/0x30
       ip_vs_cleanup+0x1d/0xd2f [ip_vs]
       __x64_sys_delete_module+0x20c/0x300
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The buggy address belongs to the object at ffff8881e9b26600 which belongs to the cache kmalloc-4096 of size 4096
      The buggy address is located 2092 bytes inside of 4096-byte region [ffff8881e9b26600, ffff8881e9b27600)
      The buggy address belongs to the page:
      page:ffffea0007a6c800 count:1 mapcount:0 mapping:ffff888107c0e600 index:0x0 compound_mapcount: 0
      flags: 0x17ffffc0008100(slab|head)
      raw: 0017ffffc0008100 dead000000000100 dead000000000200 ffff888107c0e600
      raw: 0000000000000000 0000000080070007 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      while unregistering ipvs module, ops_free_list calls
      __ip_vs_cleanup, then nf_unregister_net_hooks be called to
      do remove nf hook entries. It need a RCU period to finish,
      however net->ipvs is set to NULL immediately, which will
      trigger NULL pointer dereference when a packet is hooked
      and handled by ip_vs_in where net->ipvs is dereferenced.
      
      Another scene is ops_free_list call ops_free to free the
      net_generic directly while __ip_vs_cleanup finished, then
      calling ip_vs_in will triggers use-after-free.
      
      This patch moves nf_unregister_net_hooks from __ip_vs_cleanup()
      to __ip_vs_dev_cleanup(),  where rcu_barrier() is called by
      unregister_pernet_device -> unregister_pernet_operations,
      that will do the needed grace period.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: efe41606
      
       ("ipvs: convert to use pernet nf_hook api")
      Suggested-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      61c83de6
    • Jagdish Motwani's avatar
      netfilter: nf_queue: fix reinject verdict handling · 883ce78c
      Jagdish Motwani authored
      [ Upstream commit 946c0d8e ]
      
      This patch fixes netfilter hook traversal when there are more than 1 hooks
      returning NF_QUEUE verdict. When the first queue reinjects the packet,
      'nf_reinject' starts traversing hooks with a proper hook_index. However,
      if it again receives a NF_QUEUE verdict (by some other netfilter hook), it
      queues the packet with a wrong hook_index. So, when the second queue
      reinjects the packet, it re-executes hooks in between.
      
      Fixes: 960632ec
      
       ("netfilter: convert hook list to an array")
      Signed-off-by: default avatarJagdish Motwani <jagdish.motwani@sophos.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      883ce78c
    • Stephane Eranian's avatar
      perf/x86/intel/ds: Fix EVENT vs. UEVENT PEBS constraints · 5a9c29cc
      Stephane Eranian authored
      [ Upstream commit 23e3983a ]
      
      This patch fixes an bug revealed by the following commit:
      
        6b89d4c1
      
       ("perf/x86/intel: Fix INTEL_FLAGS_EVENT_CONSTRAINT* masking")
      
      That patch modified INTEL_FLAGS_EVENT_CONSTRAINT() to only look at the event code
      when matching a constraint. If code+umask were needed, then the
      INTEL_FLAGS_UEVENT_CONSTRAINT() macro was needed instead.
      This broke with some of the constraints for PEBS events.
      
      Several of them, including the one used for cycles:p, cycles:pp, cycles:ppp
      fell in that category and caused the event to be rejected in PEBS mode.
      In other words, on some platforms a cmdline such as:
      
        $ perf top -e cycles:pp
      
      would fail with -EINVAL.
      
      This patch fixes this bug by properly using INTEL_FLAGS_UEVENT_CONSTRAINT()
      when needed in the PEBS constraint tables.
      Reported-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: kan.liang@intel.com
      Link: http://lkml.kernel.org/r/20190521005246.423-1-eranian@google.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5a9c29cc