1. 13 Dec, 2019 17 commits
    • Xiaodong Xu's avatar
      xfrm: release device reference for invalid state · e31f97a0
      Xiaodong Xu authored
      [ Upstream commit 4944a4b1 ]
      
      An ESP packet could be decrypted in async mode if the input handler for
      this packet returns -EINPROGRESS in xfrm_input(). At this moment the device
      reference in skb is held. Later xfrm_input() will be invoked again to
      resume the processing.
      If the transform state is still valid it would continue to release the
      device reference and there won't be a problem; however if the transform
      state is not valid when async resumption happens, the packet will be
      dropped while the device reference is still being held.
      When the device is deleted for some reason and the reference to this
      device is not properly released, the kernel will keep logging like:
      
      unregister_netdevice: waiting for ppp2 to become free. Usage count = 1
      
      The issue is observed when running IPsec traffic over a PPPoE device based
      on a bridge interface. By terminating the PPPoE connection on the server
      end for multiple times, the PPPoE device on the client side will eventually
      get stuck on the above warning message.
      
      This patch will check the async mode first and continue to release device
      reference in async resumption, before it is dropped due to invalid state.
      
      v2: Do not assign address family from outer_mode in the transform if the
      state is invalid
      
      v3: Release device reference in the error path instead of jumping to resume
      
      Fixes: 4ce3dbe3 ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)")
      Signed-off-by: default avatarXiaodong Xu <stid.smth@gmail.com>
      Reported-by: default avatarBo Chen <chenborfc@163.com>
      Tested-by: default avatarBo Chen <chenborfc@163.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e31f97a0
    • Stephan Gerhold's avatar
      NFC: nxp-nci: Fix NULL pointer dereference after I2C communication error · 3c5f6ba0
      Stephan Gerhold authored
      [ Upstream commit a71a29f5 ]
      
      I2C communication errors (-EREMOTEIO) during the IRQ handler of nxp-nci
      result in a NULL pointer dereference at the moment:
      
          BUG: kernel NULL pointer dereference, address: 0000000000000000
          Oops: 0002 [#1] PREEMPT SMP NOPTI
          CPU: 1 PID: 355 Comm: irq/137-nxp-nci Not tainted 5.4.0-rc6 #1
          RIP: 0010:skb_queue_tail+0x25/0x50
          Call Trace:
           nci_recv_frame+0x36/0x90 [nci]
           nxp_nci_i2c_irq_thread_fn+0xd1/0x285 [nxp_nci_i2c]
           ? preempt_count_add+0x68/0xa0
           ? irq_forced_thread_fn+0x80/0x80
           irq_thread_fn+0x20/0x60
           irq_thread+0xee/0x180
           ? wake_threads_waitq+0x30/0x30
           kthread+0xfb/0x130
           ? irq_thread_check_affinity+0xd0/0xd0
           ? kthread_park+0x90/0x90
           ret_from_fork+0x1f/0x40
      
      Afterward the kernel must be rebooted to work properly again.
      
      This happens because it attempts to call nci_recv_frame() with skb == NULL.
      However, unlike nxp_nci_fw_recv_frame(), nci_recv_frame() does not have any
      NULL checks for skb, causing the NULL pointer dereference.
      
      Change the code to call only nxp_nci_fw_recv_frame() in case of an error.
      Make sure to log it so it is obvious that a communication error occurred.
      The error above then becomes:
      
          nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121
          nci: __nci_request: wait_for_completion_interruptible_timeout failed 0
          nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121
      
      Fixes: 6be88670 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
      Signed-off-by: default avatarStephan Gerhold <stephan@gerhold.net>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3c5f6ba0
    • Al Viro's avatar
      audit_get_nd(): don't unlock parent too early · 7fb6ef16
      Al Viro authored
      [ Upstream commit 69924b89 ]
      
      if the child has been negative and just went positive
      under us, we want coherent d_is_positive() and ->d_inode.
      Don't unlock the parent until we'd done that work...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7fb6ef16
    • Al Viro's avatar
      af17e1fc
    • Mordechay Goodstein's avatar
      iwlwifi: pcie: don't consider IV len in A-MSDU · dadd71d1
      Mordechay Goodstein authored
      [ Upstream commit cb1a4bad ]
      
      From gen2 PN is totally offloaded to hardware (also the space for the
      IV isn't part of the skb).  As you can see in mvm/mac80211.c:3545, the
      MAC for cipher types CCMP/GCMP doesn't set
      IEEE80211_KEY_FLAG_PUT_IV_SPACE for gen2 NICs.
      
      This causes all the AMSDU data to be corrupted with cipher enabled.
      Signed-off-by: default avatarMordechay Goodstein <mordechay.goodstein@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dadd71d1
    • Sirong Wang's avatar
      RDMA/hns: Correct the value of HNS_ROCE_HEM_CHUNK_LEN · 65e5e991
      Sirong Wang authored
      [ Upstream commit 531eb45b ]
      
      Size of pointer to buf field of struct hns_roce_hem_chunk should be
      considered when calculating HNS_ROCE_HEM_CHUNK_LEN, or sg table size will
      be larger than expected when allocating hem.
      
      Fixes: 9a443537 ("IB/hns: Add driver files for hns RoCE driver")
      Link: https://lore.kernel.org/r/1572575610-52530-2-git-send-email-liweihang@hisilicon.comSigned-off-by: default avatarSirong Wang <wangsirong@huawei.com>
      Signed-off-by: default avatarWeihang Li <liweihang@hisilicon.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      65e5e991
    • Al Viro's avatar
      autofs: fix a leak in autofs_expire_indirect() · d4bc855a
      Al Viro authored
      [ Upstream commit 03ad0d70 ]
      
      if the second call of should_expire() in there ends up
      grabbing and returning a new reference to dentry, we need
      to drop it before continuing.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d4bc855a
    • Chuhong Yuan's avatar
      serial: ifx6x60: add missed pm_runtime_disable · c44d21f8
      Chuhong Yuan authored
      commit 50b2b571 upstream.
      
      The driver forgets to call pm_runtime_disable in remove.
      Add the missed calls to fix it.
      Signed-off-by: default avatarChuhong Yuan <hslester96@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191118024833.21587-1-hslester96@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c44d21f8
    • Jiangfeng Xiao's avatar
      serial: serial_core: Perform NULL checks for break_ctl ops · bd95aea9
      Jiangfeng Xiao authored
      commit 7d73170e upstream.
      
      Doing fuzz test on sbsa uart device, causes a kernel crash
      due to NULL pointer dereference:
      
      ------------[ cut here ]------------
      Unable to handle kernel paging request at virtual address fffffffffffffffc
      pgd = ffffffe331723000
      [fffffffffffffffc] *pgd=0000002333595003, *pud=0000002333595003, *pmd=00000
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Modules linked in: ping(O) jffs2 rtos_snapshot(O) pramdisk(O) hisi_sfc(O)
      Drv_Nandc_K(O) Drv_SysCtl_K(O) Drv_SysClk_K(O) bsp_reg(O) hns3(O)
      hns3_uio_enet(O) hclgevf(O) hclge(O) hnae3(O) mdio_factory(O)
      mdio_registry(O) mdio_dev(O) mdio(O) hns3_info(O) rtos_kbox_panic(O)
      uart_suspend(O) rsm(O) stp llc tunnel4 xt_tcpudp ipt_REJECT nf_reject_ipv4
      iptable_filter ip_tables x_tables sd_mod xhci_plat_hcd xhci_pci xhci_hcd
      usbmon usbhid usb_storage ohci_platform ohci_pci ohci_hcd hid_generic hid
      ehci_platform ehci_pci ehci_hcd vfat fat usbcore usb_common scsi_mod
      yaffs2multi(O) ext4 jbd2 ext2 mbcache ofpart i2c_dev i2c_core uio ubi nand
      nand_ecc nand_ids cfi_cmdset_0002 cfi_cmdset_0001 cfi_probe gen_probe
      cmdlinepart chipreg mtdblock mtd_blkdevs mtd nfsd auth_rpcgss oid_registry
      nfsv3 nfs nfs_acl lockd sunrpc grace autofs4
      CPU: 2 PID: 2385 Comm: tty_fuzz_test Tainted: G           O    4.4.193 #1
      task: ffffffe32b23f110 task.stack: ffffffe32bda4000
      PC is at uart_break_ctl+0x44/0x84
      LR is at uart_break_ctl+0x34/0x84
      pc : [<ffffff8393196098>] lr : [<ffffff8393196088>] pstate: 80000005
      sp : ffffffe32bda7cc0
      x29: ffffffe32bda7cc0 x28: ffffffe32b23f110
      x27: ffffff8393402000 x26: 0000000000000000
      x25: ffffffe32b233f40 x24: ffffffc07a8ec680
      x23: 0000000000005425 x22: 00000000ffffffff
      x21: ffffffe33ed73c98 x20: 0000000000000000
      x19: ffffffe33ed94168 x18: 0000000000000004
      x17: 0000007f92ae9d30 x16: ffffff8392fa6064
      x15: 0000000000000010 x14: 0000000000000000
      x13: 0000000000000000 x12: 0000000000000000
      x11: 0000000000000020 x10: 0000007ffdac1708
      x9 : 0000000000000078 x8 : 000000000000001d
      x7 : 0000000052a64887 x6 : ffffffe32bda7e08
      x5 : ffffffe32b23c000 x4 : 0000005fbc5b0000
      x3 : ffffff83938d5018 x2 : 0000000000000080
      x1 : ffffffe32b23c040 x0 : ffffff83934428f8
      virtual start addr offset is 38ac00000
      module base offset is 2cd4cf1000
      linear region base offset is : 0
      Process tty_fuzz_test (pid: 2385, stack limit = 0xffffffe32bda4000)
      Stack: (0xffffffe32bda7cc0 to 0xffffffe32bda8000)
      7cc0: ffffffe32bda7cf0 ffffff8393177718 ffffffc07a8ec680 ffffff8393196054
      7ce0: 000000001739f2e0 0000007ffdac1978 ffffffe32bda7d20 ffffff8393179a1c
      7d00: 0000000000000000 ffffff8393c0a000 ffffffc07a8ec680 cb88537fdc8ba600
      7d20: ffffffe32bda7df0 ffffff8392fa5a40 ffffff8393c0a000 0000000000005425
      7d40: 0000007ffdac1978 ffffffe32b233f40 ffffff8393178dcc 0000000000000003
      7d60: 000000000000011d 000000000000001d ffffffe32b23f110 000000000000029e
      7d80: ffffffe34fe8d5d0 0000000000000000 ffffffe32bda7e14 cb88537fdc8ba600
      7da0: ffffffe32bda7e30 ffffff8393042cfc ffffff8393c41720 ffffff8393c46410
      7dc0: ffffff839304fa68 ffffffe32b233f40 0000000000005425 0000007ffdac1978
      7de0: 000000000000011d cb88537fdc8ba600 ffffffe32bda7e70 ffffff8392fa60cc
      7e00: 0000000000000000 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
      7e20: 0000000000005425 0000007ffdac1978 ffffffe32bda7e70 ffffff8392fa60b0
      7e40: 0000000000000280 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
      7e60: 0000000000005425 cb88537fdc8ba600 0000000000000000 ffffff8392e02e78
      7e80: 0000000000000280 0000005fbc5b0000 ffffffffffffffff 0000007f92ae9d3c
      7ea0: 0000000060000000 0000000000000015 0000000000000003 0000000000005425
      7ec0: 0000007ffdac1978 0000000000000000 00000000a54c910e 0000007f92b95014
      7ee0: 0000007f92b95090 0000000052a64887 000000000000001d 0000000000000078
      7f00: 0000007ffdac1708 0000000000000020 0000000000000000 0000000000000000
      7f20: 0000000000000000 0000000000000010 000000556acf0090 0000007f92ae9d30
      7f40: 0000000000000004 000000556acdef10 0000000000000000 000000556acdebd0
      7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      7f80: 0000000000000000 0000000000000000 0000000000000000 0000007ffdac1840
      7fa0: 000000556acdedcc 0000007ffdac1840 0000007f92ae9d3c 0000000060000000
      7fc0: 0000000000000000 0000000000000000 0000000000000003 000000000000001d
      7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      Call trace:
      Exception stack(0xffffffe32bda7ab0 to 0xffffffe32bda7bf0)
      7aa0:                                   0000000000001000 0000007fffffffff
      7ac0: ffffffe32bda7cc0 ffffff8393196098 0000000080000005 0000000000000025
      7ae0: ffffffe32b233f40 ffffff83930d777c ffffffe32bda7b30 ffffff83930d777c
      7b00: ffffffe32bda7be0 ffffff83938d5000 ffffffe32bda7be0 ffffffe32bda7c20
      7b20: ffffffe32bda7b60 ffffff83930d777c ffffffe32bda7c10 ffffff83938d5000
      7b40: ffffffe32bda7c10 ffffffe32bda7c50 ffffff8393c0a000 ffffffe32b23f110
      7b60: ffffffe32bda7b70 ffffff8392e09df4 ffffffe32bda7bb0 cb88537fdc8ba600
      7b80: ffffff83934428f8 ffffffe32b23c040 0000000000000080 ffffff83938d5018
      7ba0: 0000005fbc5b0000 ffffffe32b23c000 ffffffe32bda7e08 0000000052a64887
      7bc0: 000000000000001d 0000000000000078 0000007ffdac1708 0000000000000020
      7be0: 0000000000000000 0000000000000000
      [<ffffff8393196098>] uart_break_ctl+0x44/0x84
      [<ffffff8393177718>] send_break+0xa0/0x114
      [<ffffff8393179a1c>] tty_ioctl+0xc50/0xe84
      [<ffffff8392fa5a40>] do_vfs_ioctl+0xc4/0x6e8
      [<ffffff8392fa60cc>] SyS_ioctl+0x68/0x9c
      [<ffffff8392e02e78>] __sys_trace_return+0x0/0x4
      Code: b9410ea0 34000160 f9408aa0 f9402814 (b85fc280)
      ---[ end trace 8606094f1960c5e0 ]---
      Kernel panic - not syncing: Fatal exception
      
      Fix this problem by adding NULL checks prior to calling break_ctl ops.
      Signed-off-by: default avatarJiangfeng Xiao <xiaojiangfeng@huawei.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/1574263133-28259-1-git-send-email-xiaojiangfeng@huawei.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd95aea9
    • Vincent Whitchurch's avatar
      serial: pl011: Fix DMA ->flush_buffer() · 4fca5202
      Vincent Whitchurch authored
      commit f6a19647 upstream.
      
      PL011's ->flush_buffer() implementation releases and reacquires the port
      lock.  Due to a race condition here, data can end up being added to the
      circular buffer but neither being discarded nor being sent out.  This
      leads to, for example, tcdrain(2) waiting indefinitely.
      
      Process A                       Process B
      
      uart_flush_buffer()
       - acquire lock
       - circ_clear
       - pl011_flush_buffer()
       -- release lock
       -- dmaengine_terminate_all()
      
                                      uart_write()
                                      - acquire lock
                                      - add chars to circ buffer
                                      - start_tx()
                                      -- start DMA
                                      - release lock
      
       -- acquire lock
       -- turn off DMA
       -- release lock
      
                                      // Data in circ buffer but DMA is off
      
      According to the comment in the code, the releasing of the lock around
      dmaengine_terminate_all() is to avoid a deadlock with the DMA engine
      callback.  However, since the time this code was written, the DMA engine
      API documentation seems to have been clarified to say that
      dmaengine_terminate_all() (in the identically implemented but
      differently named dmaengine_terminate_async() variant) does not wait for
      any running complete callback to be completed and can even be called
      from a complete callback.  So there is no possibility of deadlock if the
      DMA engine driver implements this API correctly.
      
      So we should be able to just remove this release and reacquire of the
      lock to prevent the aforementioned race condition.
      Signed-off-by: default avatarVincent Whitchurch <vincent.whitchurch@axis.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191118092547.32135-1-vincent.whitchurch@axis.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fca5202
    • Jeffrey Hugo's avatar
      tty: serial: msm_serial: Fix flow control · 4f729489
      Jeffrey Hugo authored
      commit b027ce25 upstream.
      
      hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and
      Lenovo Miix 630 laptop.  As part of initializing the wcn3990, hci_qca
      disables flow, configures the uart baudrate, and then reenables flow - at
      which point an event is expected to be received over the uart from the
      wcn3990.  It is observed that this event comes after the baudrate change
      but before hci_qca re-enables flow. This is unexpected, and is a result of
      msm_reset() being broken.
      
      According to the uart_dm hardware documentation, it is recommended that
      automatic hardware flow control be enabled by setting RX_RDY_CTL.  Auto
      hw flow control will manage RFR based on the configured watermark.  When
      there is space to receive data, the hw will assert RFR.  When the watermark
      is hit, the hw will de-assert RFR.
      
      The hardware documentation indicates that RFR can me manually managed via
      CR when RX_RDY_CTL is not set.  SET_RFR asserts RFR, and RESET_RFR
      de-asserts RFR.
      
      msm_reset() is broken because after resetting the hardware, it
      unconditionally asserts RFR via SET_RFR.  This enables flow regardless of
      the current configuration, and would undo a previous flow disable
      operation.  It should instead de-assert RFR via RESET_RFR to block flow
      until the hardware is reconfigured.  msm_serial should rely on the client
      to specify that flow should be enabled, either via mctrl() or the termios
      structure, and only assert RFR in response to those triggers.
      
      Fixes: 04896a77 ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
      Signed-off-by: default avatarJeffrey Hugo <jeffrey.l.hugo@gmail.com>
      Reviewed-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarAndy Gross <agross@kernel.org>
      Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f729489
    • Peng Fan's avatar
      tty: serial: fsl_lpuart: use the sg count from dma_map_sg · 8f7600e2
      Peng Fan authored
      commit 487ee861 upstream.
      
      The dmaengine_prep_slave_sg needs to use sg count returned
      by dma_map_sg, not use sport->dma_tx_nents, because the return
      value of dma_map_sg is not always same with "nents".
      
      When enabling iommu for lpuart + edma, iommu framework may concatenate
      two sgs into one.
      
      Fixes: 6250cc30 ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarPeng Fan <peng.fan@nxp.com>
      Link: https://lore.kernel.org/r/1572932977-17866-1-git-send-email-peng.fan@nxp.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f7600e2
    • Michał Mirosław's avatar
      usb: gadget: u_serial: add missing port entry locking · c5a309dc
      Michał Mirosław authored
      commit daf82bd2 upstream.
      
      gserial_alloc_line() misses locking (for a release barrier) while
      resetting port entry on TTY allocation failure. Fix this.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: default avatarLadislav Michl <ladis@linux-mips.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5a309dc
    • Arnd Bergmann's avatar
      lp: fix sparc64 LPSETTIMEOUT ioctl · c35cac92
      Arnd Bergmann authored
      commit 45a2d646 upstream.
      
      The layout of struct timeval is different on sparc64 from
      anything else, and the patch I did long ago failed to take
      this into account.
      
      Change it now to handle sparc64 user space correctly again.
      
      Quite likely nobody cares about parallel ports on sparc64,
      but there is no reason not to fix it.
      
      Cc: stable@vger.kernel.org
      Fixes: 9a450484 ("lp: support 64-bit time_t user space")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20191108203435.112759-7-arnd@arndb.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c35cac92
    • Tuowen Zhao's avatar
      sparc64: implement ioremap_uc · a59c5bc7
      Tuowen Zhao authored
      commit 38e45d81 upstream.
      
      On sparc64, the whole physical IO address space is accessible using
      physically addressed loads and stores. *_uc does nothing like the
      others.
      
      Cc: <stable@vger.kernel.org> # v4.19+
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarTuowen Zhao <ztuowen@gmail.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a59c5bc7
    • Jon Hunter's avatar
      arm64: tegra: Fix 'active-low' warning for Jetson TX1 regulator · 2f5eb8d6
      Jon Hunter authored
      commit 1e5e929c upstream.
      
      Commit 34993594 ("arm64: tegra: Enable HDMI on Jetson TX1")
      added a regulator for HDMI on the Jetson TX1 platform. This regulator
      has an active high enable, but the GPIO specifier for enabling the
      regulator incorrectly defines it as active-low. This causes the
      following warning to occur on boot ...
      
       WARNING KERN regulator@10 GPIO handle specifies active low - ignored
      
      The fixed-regulator binding does not use the active-low flag from the
      gpio specifier and purely relies of the presence of the
      'enable-active-high' property to determine if it is active high or low
      (if this property is omitted). Fix this warning by setting the GPIO
      to active-high in the GPIO specifier which aligns with the presense of
      the 'enable-active-high' property.
      
      Fixes: 34993594 ("arm64: tegra: Enable HDMI on Jetson TX1")
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f5eb8d6
    • Navid Emamdoost's avatar
      rsi: release skb if rsi_prepare_beacon fails · 5da96cc3
      Navid Emamdoost authored
      commit d563131e upstream.
      
      In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should
      be released.
      Signed-off-by: default avatarNavid Emamdoost <navid.emamdoost@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5da96cc3
  2. 05 Dec, 2019 23 commits