commit 7d80e1218adf6d1aa5270587192789e218fef706
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 4 09:32:04 2019 +0200

    Linux 4.14.136

commit b72fd569f5f7380a1f9fb50b3706e1dfc746fe1e
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Jun 17 21:34:13 2019 +0800

    ip_tunnel: allow not to count pkts on tstats by setting skb's dev to NULL
    
    commit 5684abf7020dfc5f0b6ba1d68eda3663871fce52 upstream.
    
    iptunnel_xmit() works as a common function, also used by a udp tunnel
    which doesn't have to have a tunnel device, like how TIPC works with
    udp media.
    
    In these cases, we should allow not to count pkts on dev's tstats, so
    that udp tunnel can work with no tunnel device safely.
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13d25588c4130b662183d014a6604511e3bae383
Author: Yan, Zheng <zyan@redhat.com>
Date:   Thu May 23 11:01:37 2019 +0800

    ceph: hold i_ceph_lock when removing caps for freeing inode
    
    commit d6e47819721ae2d9d090058ad5570a66f3c42e39 upstream.
    
    ceph_d_revalidate(, LOOKUP_RCU) may call __ceph_caps_issued_mask()
    on a freeing inode.
    
    Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b3c3f8860bc4d4c5307e91ed36ef07fe704a621
Author: Yoshinori Sato <ysato@users.sourceforge.jp>
Date:   Sun Apr 21 22:53:58 2019 +0900

    Fix allyesconfig output.
    
    commit 1b496469d0c020e09124e03e66a81421c21272a7 upstream.
    
    Conflict JCore-SoC and SolutionEngine 7619.
    
    Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 650febaf6365e7960f587b292dccc5270470d794
Author: Miroslav Lichvar <mlichvar@redhat.com>
Date:   Tue Jul 16 16:30:09 2019 -0700

    drivers/pps/pps.c: clear offset flags in PPS_SETPARAMS ioctl
    
    commit 5515e9a6273b8c02034466bcbd717ac9f53dab99 upstream.
    
    The PPS assert/clear offset corrections are set by the PPS_SETPARAMS
    ioctl in the pps_ktime structs, which also contain flags.  The flags are
    not initialized by applications (using the timepps.h header) and they
    are not used by the kernel for anything except returning them back in
    the PPS_GETPARAMS ioctl.
    
    Set the flags to zero to make it clear they are unused and avoid leaking
    uninitialized data of the PPS_SETPARAMS caller to other applications
    that have a read access to the PPS device.
    
    Link: http://lkml.kernel.org/r/20190702092251.24303-1-mlichvar@redhat.com
    Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Rodolfo Giometti <giometti@enneenne.com>
    Cc: Greg KH <greg@kroah.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0919216e468d5613cc8c53d4d0676026960fe39
Author: Jann Horn <jannh@google.com>
Date:   Tue Jul 16 17:20:45 2019 +0200

    sched/fair: Don't free p->numa_faults with concurrent readers
    
    commit 16d51a590a8ce3befb1308e0e7ab77f3b661af33 upstream.
    
    When going through execve(), zero out the NUMA fault statistics instead of
    freeing them.
    
    During execve, the task is reachable through procfs and the scheduler. A
    concurrent /proc/*/sched reader can read data from a freed ->numa_faults
    allocation (confirmed by KASAN) and write it back to userspace.
    I believe that it would also be possible for a use-after-free read to occur
    through a race between a NUMA fault and execve(): task_numa_fault() can
    lead to task_numa_compare(), which invokes task_weight() on the currently
    running task of a different CPU.
    
    Another way to fix this would be to make ->numa_faults RCU-managed or add
    extra locking, but it seems easier to wipe the NUMA fault statistics on
    execve.
    
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Will Deacon <will@kernel.org>
    Fixes: 82727018b0d3 ("sched/numa: Call task_numa_free() from do_execve()")
    Link: https://lkml.kernel.org/r/20190716152047.14424-1-jannh@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69f9c2bc3f754ad1d610b30b940681d678c8e684
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Tue Jul 30 11:33:45 2019 +0200

    Bluetooth: hci_uart: check for missing tty operations
    
    commit b36a1552d7319bbfd5cf7f08726c23c5c66d4f73 upstream.
    
    Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset()
    functions which are called by the certain HCI UART protocols (hci_ath,
    hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control()
    or directly. This leads to an execution at NULL and can be triggered by
    an unprivileged user. Fix this by adding a helper function and a check
    for the missing tty operations in the protocols code.
    
    This fixes CVE-2019-10207. The Fixes: lines list commits where calls to
    tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART
    protocols.
    
    Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
    Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org # v2.6.36+
    Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial chip")
    Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions")
    Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate configuration support")
    Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support")
    Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Reviewed-by: Yu-Chen, Cho <acho@suse.com>
    Tested-by: Yu-Chen, Cho <acho@suse.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fbfe322db638d136af2d502d3b3069693a9bca10
Author: Sunil Muthuswamy <sunilmut@microsoft.com>
Date:   Wed May 15 00:56:05 2019 +0000

    hv_sock: Add support for delayed close
    
    commit a9eeb998c28d5506616426bd3a216bd5735a18b8 upstream.
    
    Currently, hvsock does not implement any delayed or background close
    logic. Whenever the hvsock socket is closed, a FIN is sent to the peer, and
    the last reference to the socket is dropped, which leads to a call to
    .destruct where the socket can hang indefinitely waiting for the peer to
    close it's side. The can cause the user application to hang in the close()
    call.
    
    This change implements proper STREAM(TCP) closing handshake mechanism by
    sending the FIN to the peer and the waiting for the peer's FIN to arrive
    for a given timeout. On timeout, it will try to terminate the connection
    (i.e. a RST). This is in-line with other socket providers such as virtio.
    
    This change does not address the hang in the vmbus_hvsock_device_unregister
    where it waits indefinitely for the host to rescind the channel. That
    should be taken up as a separate fix.
    
    Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 417084878e022072086d2de916347b93941bd829
Author: Joerg Roedel <jroedel@suse.de>
Date:   Tue Jul 23 09:51:00 2019 +0200

    iommu/iova: Fix compilation error with !CONFIG_IOMMU_IOVA
    
    commit 201c1db90cd643282185a00770f12f95da330eca upstream.
    
    The stub function for !CONFIG_IOMMU_IOVA needs to be
    'static inline'.
    
    Fixes: effa467870c76 ('iommu/vt-d: Don't queue_iova() if there is no flush queue')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc2ec1855e536950637b734b0c85caefcea7c3c6
Author: Dmitry Safonov <dima@arista.com>
Date:   Tue Jul 16 22:38:05 2019 +0100

    iommu/vt-d: Don't queue_iova() if there is no flush queue
    
    commit effa467870c7612012885df4e246bdb8ffd8e44c upstream.
    
    Intel VT-d driver was reworked to use common deferred flushing
    implementation. Previously there was one global per-cpu flush queue,
    afterwards - one per domain.
    
    Before deferring a flush, the queue should be allocated and initialized.
    
    Currently only domains with IOMMU_DOMAIN_DMA type initialize their flush
    queue. It's probably worth to init it for static or unmanaged domains
    too, but it may be arguable - I'm leaving it to iommu folks.
    
    Prevent queuing an iova flush if the domain doesn't have a queue.
    The defensive check seems to be worth to keep even if queue would be
    initialized for all kinds of domains. And is easy backportable.
    
    On 4.19.43 stable kernel it has a user-visible effect: previously for
    devices in si domain there were crashes, on sata devices:
    
     BUG: spinlock bad magic on CPU#6, swapper/0/1
      lock: 0xffff88844f582008, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
     CPU: 6 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #1
     Call Trace:
      <IRQ>
      dump_stack+0x61/0x7e
      spin_bug+0x9d/0xa3
      do_raw_spin_lock+0x22/0x8e
      _raw_spin_lock_irqsave+0x32/0x3a
      queue_iova+0x45/0x115
      intel_unmap+0x107/0x113
      intel_unmap_sg+0x6b/0x76
      __ata_qc_complete+0x7f/0x103
      ata_qc_complete+0x9b/0x26a
      ata_qc_complete_multiple+0xd0/0xe3
      ahci_handle_port_interrupt+0x3ee/0x48a
      ahci_handle_port_intr+0x73/0xa9
      ahci_single_level_irq_intr+0x40/0x60
      __handle_irq_event_percpu+0x7f/0x19a
      handle_irq_event_percpu+0x32/0x72
      handle_irq_event+0x38/0x56
      handle_edge_irq+0x102/0x121
      handle_irq+0x147/0x15c
      do_IRQ+0x66/0xf2
      common_interrupt+0xf/0xf
     RIP: 0010:__do_softirq+0x8c/0x2df
    
    The same for usb devices that use ehci-pci:
     BUG: spinlock bad magic on CPU#0, swapper/0/1
      lock: 0xffff88844f402008, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
     CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #4
     Call Trace:
      <IRQ>
      dump_stack+0x61/0x7e
      spin_bug+0x9d/0xa3
      do_raw_spin_lock+0x22/0x8e
      _raw_spin_lock_irqsave+0x32/0x3a
      queue_iova+0x77/0x145
      intel_unmap+0x107/0x113
      intel_unmap_page+0xe/0x10
      usb_hcd_unmap_urb_setup_for_dma+0x53/0x9d
      usb_hcd_unmap_urb_for_dma+0x17/0x100
      unmap_urb_for_dma+0x22/0x24
      __usb_hcd_giveback_urb+0x51/0xc3
      usb_giveback_urb_bh+0x97/0xde
      tasklet_action_common.isra.4+0x5f/0xa1
      tasklet_action+0x2d/0x30
      __do_softirq+0x138/0x2df
      irq_exit+0x7d/0x8b
      smp_apic_timer_interrupt+0x10f/0x151
      apic_timer_interrupt+0xf/0x20
      </IRQ>
     RIP: 0010:_raw_spin_unlock_irqrestore+0x17/0x39
    
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Lu Baolu <baolu.lu@linux.intel.com>
    Cc: iommu@lists.linux-foundation.org
    Cc: <stable@vger.kernel.org> # 4.14+
    Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing")
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    [v4.14-port notes:
    o minor conflict with untrusted IOMMU devices check under if-condition
    o setup_timer() near one chunk is timer_setup() in v5.3]
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4c213d9aadc85a2808b04d3676970ea5f90340e
Author: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Date:   Fri Jun 21 21:04:38 2019 -0400

    media: radio-raremono: change devm_k*alloc to k*alloc
    
    commit c666355e60ddb4748ead3bdd983e3f7f2224aaf0 upstream.
    
    Change devm_k*alloc to k*alloc to manually allocate memory
    
    The manual allocation and freeing of memory is necessary because when
    the USB radio is disconnected, the memory associated with devm_k*alloc
    is freed. Meaning if we still have unresolved references to the radio
    device, then we get use-after-free errors.
    
    This patch fixes this by manually allocating memory, and freeing it in
    the v4l2.release callback that gets called when the last radio device
    exits.
    
    Reported-and-tested-by: syzbot+a4387f5b6b799f6becbf@syzkaller.appspotmail.com
    
    Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    [hverkuil-cisco@xs4all.nl: cleaned up two small checkpatch.pl warnings]
    [hverkuil-cisco@xs4all.nl: prefix subject with driver name]
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f694fac720866747c5e794b797085b3189a8696
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Tue Jun 11 12:57:52 2019 -0400

    NFS: Cleanup if nfs_match_client is interrupted
    
    commit 9f7761cf0409465075dadb875d5d4b8ef2f890c8 upstream.
    
    Don't bail out before cleaning up a new allocation if the wait for
    searching for a matching nfs client is interrupted.  Memory leaks.
    
    Reported-by: syzbot+7fe11b49c1cc30e3fce2@syzkaller.appspotmail.com
    Fixes: 950a578c6128 ("NFS: make nfs_match_client killable")
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 171e75b33054d546c2cf9fadd0a3523a0b4bd932
Author: Andrey Konovalov <andreyknvl@google.com>
Date:   Thu May 2 12:09:26 2019 -0400

    media: pvrusb2: use a different format for warnings
    
    commit 1753c7c4367aa1201e1e5d0a601897ab33444af1 upstream.
    
    When the pvrusb2 driver detects that there's something wrong with the
    device, it prints a warning message. Right now those message are
    printed in two different formats:
    
    1. ***WARNING*** message here
    2. WARNING: message here
    
    There's an issue with the second format. Syzkaller recognizes it as a
    message produced by a WARN_ON(), which is used to indicate a bug in the
    kernel. However pvrusb2 prints those warnings to indicate an issue with
    the device, not the bug in the kernel.
    
    This patch changes the pvrusb2 driver to consistently use the first
    warning message format. This will unblock syzkaller testing of this
    driver.
    
    Reported-by: syzbot+af8f8d2ac0d39b0ed3a0@syzkaller.appspotmail.com
    Reported-by: syzbot+170a86bf206dd2c6217e@syzkaller.appspotmail.com
    Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3566a98e59b5cb19829d21bfe18cd396812ce15e
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu May 9 04:57:09 2019 -0400

    media: cpia2_usb: first wake up, then free in disconnect
    
    commit eff73de2b1600ad8230692f00bc0ab49b166512a upstream.
    
    Kasan reported a use after free in cpia2_usb_disconnect()
    It first freed everything and then woke up those waiting.
    The reverse order is correct.
    
    Fixes: 6c493f8b28c67 ("[media] cpia2: major overhaul to get it in a working state again")
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Reported-by: syzbot+0c90fc937c84f97d0aa6@syzkaller.appspotmail.com
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3abe1639de0b88ee4a78ea43b8fa1d98c302e647
Author: Fabio Estevam <festevam@gmail.com>
Date:   Thu May 9 09:15:00 2019 -0300

    ath10k: Change the warning message string
    
    commit 265df32eae5845212ad9f55f5ae6b6dcb68b187b upstream.
    
    The "WARNING" string confuses syzbot, which thinks it found
    a crash [1].
    
    Change the string to avoid such problem.
    
    [1] https://lkml.org/lkml/2019/5/9/243
    
    Reported-by: syzbot+c1b25598aa60dcd47e78@syzkaller.appspotmail.com
    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10c037432a71491fe350b6c9810a64323add78cb
Author: Sean Young <sean@mess.org>
Date:   Sun May 19 15:28:22 2019 -0400

    media: au0828: fix null dereference in error path
    
    commit 6d0d1ff9ff21fbb06b867c13a1d41ce8ddcd8230 upstream.
    
    au0828_usb_disconnect() gets the au0828_dev struct via usb_get_intfdata,
    so it needs to set up for the error paths.
    
    Reported-by: syzbot+357d86bcb4cca1a2f572@syzkaller.appspotmail.com
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b05c76bc8b92e72084718aa8bacdb6bba1303e2e
Author: Phong Tran <tranmanphong@gmail.com>
Date:   Mon Jul 15 22:08:14 2019 +0700

    ISDN: hfcsusb: checking idx of ep configuration
    
    commit f384e62a82ba5d85408405fdd6aeff89354deaa9 upstream.
    
    The syzbot test with random endpoint address which made the idx is
    overflow in the table of endpoint configuations.
    
    this adds the checking for fixing the error report from
    syzbot
    
    KASAN: stack-out-of-bounds Read in hfcsusb_probe [1]
    The patch tested by syzbot [2]
    
    Reported-by: syzbot+8750abbc3a46ef47d509@syzkaller.appspotmail.com
    
    [1]:
    https://syzkaller.appspot.com/bug?id=30a04378dac680c5d521304a00a86156bb913522
    [2]:
    https://groups.google.com/d/msg/syzkaller-bugs/_6HBdge8F3E/OJn7wVNpBAAJ
    
    Signed-off-by: Phong Tran <tranmanphong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4a3c070b8760f71c8311399fa9bfe67c8629bca
Author: Todd Kjos <tkjos@android.com>
Date:   Wed Jun 12 13:29:27 2019 -0700

    binder: fix possible UAF when freeing buffer
    
    commit a370003cc301d4361bae20c9ef615f89bf8d1e8a upstream.
    
    There is a race between the binder driver cleaning
    up a completed transaction via binder_free_transaction()
    and a user calling binder_ioctl(BC_FREE_BUFFER) to
    release a buffer. It doesn't matter which is first but
    they need to be protected against running concurrently
    which can result in a UAF.
    
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6932a1265022e9b1c18a5dea366839dfbf40212a
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Sep 5 15:34:43 2018 +0100

    arm64: compat: Provide definition for COMPAT_SIGMINSTKSZ
    
    commit 24951465cbd279f60b1fdc2421b3694405bcff42 upstream.
    
    arch/arm/ defines a SIGMINSTKSZ of 2k, so we should use the same value
    for compat tasks.
    
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Reviewed-by: Dave Martin <Dave.Martin@arm.com>
    Reported-by: Steve McIntyre <steve.mcintyre@arm.com>
    Tested-by: Steve McIntyre <93sam@debian.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8dc41ad60b6fcd99b9cd904342a1dfb738013deb
Author: Abhishek Sahu <absahu@codeaurora.org>
Date:   Mon Mar 12 18:44:51 2018 +0530

    i2c: qup: fixed releasing dma without flush operation completion
    
    commit 7239872fb3400b21a8f5547257f9f86455867bd6 upstream.
    
    The QUP BSLP BAM generates the following error sometimes if the
    current I2C DMA transfer fails and the flush operation has been
    scheduled
    
        “bam-dma-engine 7884000.dma: Cannot free busy channel”
    
    If any I2C error comes during BAM DMA transfer, then the QUP I2C
    interrupt will be generated and the flush operation will be
    carried out to make I2C consume all scheduled DMA transfer.
    Currently, the same completion structure is being used for BAM
    transfer which has already completed without reinit. It will make
    flush operation wait_for_completion_timeout completed immediately
    and will proceed for freeing the DMA resources where the
    descriptors are still in process.
    
    Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
    Acked-by: Sricharan R <sricharan@codeaurora.org>
    Reviewed-by: Austin Christ <austinwc@codeaurora.org>
    Reviewed-by: Andy Gross <andy.gross@linaro.org>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8604ac922424d5930a672f4d31eb858e82cd1111
Author: allen yan <yanwei@marvell.com>
Date:   Thu Sep 7 15:04:53 2017 +0200

    arm64: dts: marvell: Fix A37xx UART0 register size
    
    commit c737abc193d16e62e23e2fb585b8b7398ab380d8 upstream.
    
    Armada-37xx UART0 registers are 0x200 bytes wide. Right next to them are
    the UART1 registers that should not be declared in this node.
    
    Update the example in DT bindings document accordingly.
    
    Signed-off-by: allen yan <yanwei@marvell.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c78b265f2cdd63e41a3578c75d2c19d0b9552e3e
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Sep 28 12:42:51 2018 -0400

    NFSv4: Fix lookup revalidate of regular files
    
    commit c7944ebb9ce9461079659e9e6ec5baaf73724b3b upstream.
    
    If we're revalidating an existing dentry in order to open a file, we need
    to ensure that we check the directory has not changed before we optimise
    away the lookup.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Qian Lu <luqia@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df047f3ea5df185b50212a462fc651a90f77f854
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Sep 28 09:04:05 2018 -0400

    NFS: Refactor nfs_lookup_revalidate()
    
    commit 5ceb9d7fdaaf6d8ced6cd7861cf1deb9cd93fa47 upstream.
    
    Refactor the code in nfs_lookup_revalidate() as a stepping stone towards
    optimising and fixing nfs4_lookup_revalidate().
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Qian Lu <luqia@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0933aaa24890055cb8ee7afe1be8938f3dd62d85
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Thu Sep 27 17:12:33 2018 -0400

    NFS: Fix dentry revalidation on NFSv4 lookup
    
    commit be189f7e7f03de35887e5a85ddcf39b91b5d7fc1 upstream.
    
    We need to ensure that inode and dentry revalidation occurs correctly
    on reopen of a file that is already open. Currently, we can end up
    not revalidating either in the case of NFSv4.0, due to the 'cached open'
    path.
    Let's fix that by ensuring that we only do cached open for the special
    cases of open recovery and delegation return.
    
    Reported-by: Stan Hu <stanhu@gmail.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Qian Lu <luqia@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8cf9ddf9754c2a069ecac250b417f8bd328d1a11
Author: Sunil Muthuswamy <sunilmut@microsoft.com>
Date:   Thu Jun 13 03:52:27 2019 +0000

    vsock: correct removal of socket from the list
    
    commit d5afa82c977ea06f7119058fa0eb8519ea501031 upstream.
    
    The current vsock code for removal of socket from the list is both
    subject to race and inefficient. It takes the lock, checks whether
    the socket is in the list, drops the lock and if the socket was on the
    list, deletes it from the list. This is subject to race because as soon
    as the lock is dropped once it is checked for presence, that condition
    cannot be relied upon for any decision. It is also inefficient because
    if the socket is present in the list, it takes the lock twice.
    
    Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62c0c9d69b1f8f0efc0c292407fcc7a9d4d5c7b5
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date:   Thu Oct 5 16:46:52 2017 -0400

    VSOCK: use TCP state constants for sk_state
    
    commit 3b4477d2dcf2709d0be89e2a8dced3d0f4a017f2 upstream.
    
    There are two state fields: socket->state and sock->sk_state.  The
    socket->state field uses SS_UNCONNECTED, SS_CONNECTED, etc while the
    sock->sk_state typically uses values that match TCP state constants
    (TCP_CLOSE, TCP_ESTABLISHED).  AF_VSOCK does not follow this convention
    and instead uses SS_* constants for both fields.
    
    The sk_state field will be exposed to userspace through the vsock_diag
    interface for ss(8), netstat(8), and other programs.
    
    This patch switches sk_state to TCP state constants so that the meaning
    of this field is consistent with other address families.  Not just
    AF_INET and AF_INET6 use the TCP constants, AF_UNIX and others do too.
    
    The following mapping was used to convert the code:
    
      SS_FREE -> TCP_CLOSE
      SS_UNCONNECTED -> TCP_CLOSE
      SS_CONNECTING -> TCP_SYN_SENT
      SS_CONNECTED -> TCP_ESTABLISHED
      SS_DISCONNECTING -> TCP_CLOSING
      VSOCK_SS_LISTEN -> TCP_LISTEN
    
    In __vsock_create() the sk_state initialization was dropped because
    sock_init_data() already initializes sk_state to TCP_CLOSE.
    
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [Adjusted net/vmw_vsock/hyperv_transport.c since the commit
    b4562ca7925a ("hv_sock: add locking in the open/close/release code paths")
    and the commit
    c9d3fe9da094 ("VSOCK: fix outdated sk_state value in hvs_release()")
    were backported before 3b4477d2dcf2.]
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>