--- /dev/null
+From 2a3f7221acddfe1caa9ff09b3a8158c39b2fdeac Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 16 Apr 2019 17:06:33 +0200
+Subject: ALSA: core: Fix card races between register and disconnect
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 2a3f7221acddfe1caa9ff09b3a8158c39b2fdeac upstream.
+
+There is a small race window in the card disconnection code that
+allows the registration of another card with the very same card id.
+This leads to a warning in procfs creation as caught by syzkaller.
+
+The problem is that we delete snd_cards and snd_cards_lock entries at
+the very beginning of the disconnection procedure. This makes the
+slot available to be assigned for another card object while the
+disconnection procedure is being processed. Then it becomes possible
+to issue a procfs registration with the existing file name although we
+check the conflict beforehand.
+
+The fix is simply to move the snd_cards and snd_cards_lock clearances
+at the end of the disconnection procedure. The references to these
+entries are merely either from the global proc files like
+/proc/asound/cards or from the card registration / disconnection, so
+it should be fine to shift at the very end.
+
+Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/init.c | 18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+--- a/sound/core/init.c
++++ b/sound/core/init.c
+@@ -407,14 +407,7 @@ int snd_card_disconnect(struct snd_card
+ card->shutdown = 1;
+ spin_unlock(&card->files_lock);
+
+- /* phase 1: disable fops (user space) operations for ALSA API */
+- mutex_lock(&snd_card_mutex);
+- snd_cards[card->number] = NULL;
+- clear_bit(card->number, snd_cards_lock);
+- mutex_unlock(&snd_card_mutex);
+-
+- /* phase 2: replace file->f_op with special dummy operations */
+-
++ /* replace file->f_op with special dummy operations */
+ spin_lock(&card->files_lock);
+ list_for_each_entry(mfile, &card->files_list, list) {
+ /* it's critical part, use endless loop */
+@@ -430,7 +423,7 @@ int snd_card_disconnect(struct snd_card
+ }
+ spin_unlock(&card->files_lock);
+
+- /* phase 3: notify all connected devices about disconnection */
++ /* notify all connected devices about disconnection */
+ /* at this point, they cannot respond to any calls except release() */
+
+ #if IS_ENABLED(CONFIG_SND_MIXER_OSS)
+@@ -446,6 +439,13 @@ int snd_card_disconnect(struct snd_card
+ device_del(&card->card_dev);
+ card->registered = false;
+ }
++
++ /* disable fops (user space) operations for ALSA API */
++ mutex_lock(&snd_card_mutex);
++ snd_cards[card->number] = NULL;
++ clear_bit(card->number, snd_cards_lock);
++ mutex_unlock(&snd_card_mutex);
++
+ #ifdef CONFIG_PM
+ wake_up(&card->power_sleep);
+ #endif
--- /dev/null
+From b26e36b7ef36a8a3a147b1609b2505f8a4ecf511 Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Wed, 17 Apr 2019 16:10:32 +0800
+Subject: ALSA: hda/realtek - add two more pin configuration sets to quirk table
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit b26e36b7ef36a8a3a147b1609b2505f8a4ecf511 upstream.
+
+We have two Dell laptops which have the codec 10ec0236 and 10ec0256
+respectively, the headset mic on them can't work, need to apply the
+quirk of ALC255_FIXUP_DELL1_MIC_NO_PRESENCE. So adding their pin
+configurations in the pin quirk table.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -7170,6 +7170,8 @@ static const struct snd_hda_pin_quirk al
+ {0x12, 0x90a60140},
+ {0x14, 0x90170150},
+ {0x21, 0x02211020}),
++ SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
++ {0x21, 0x02211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL2_MIC_NO_PRESENCE,
+ {0x14, 0x90170110},
+ {0x21, 0x02211020}),
+@@ -7280,6 +7282,10 @@ static const struct snd_hda_pin_quirk al
+ {0x21, 0x0221101f}),
+ SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+ ALC256_STANDARD_PINS),
++ SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
++ {0x14, 0x90170110},
++ {0x1b, 0x01011020},
++ {0x21, 0x0221101f}),
+ SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS", ALC256_FIXUP_ASUS_MIC,
+ {0x14, 0x90170110},
+ {0x1b, 0x90a70130},
--- /dev/null
+From ff8acf929014b7f87315588e0daf8597c8aa9d1c Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <natechancellor@gmail.com>
+Date: Wed, 17 Apr 2019 00:21:21 -0700
+Subject: arm64: futex: Restore oldval initialization to work around buggy compilers
+
+From: Nathan Chancellor <natechancellor@gmail.com>
+
+commit ff8acf929014b7f87315588e0daf8597c8aa9d1c upstream.
+
+Commit 045afc24124d ("arm64: futex: Fix FUTEX_WAKE_OP atomic ops with
+non-zero result value") removed oldval's zero initialization in
+arch_futex_atomic_op_inuser because it is not necessary. Unfortunately,
+Android's arm64 GCC 4.9.4 [1] does not agree:
+
+../kernel/futex.c: In function 'do_futex':
+../kernel/futex.c:1658:17: warning: 'oldval' may be used uninitialized
+in this function [-Wmaybe-uninitialized]
+ return oldval == cmparg;
+ ^
+In file included from ../kernel/futex.c:73:0:
+../arch/arm64/include/asm/futex.h:53:6: note: 'oldval' was declared here
+ int oldval, ret, tmp;
+ ^
+
+GCC fails to follow that when ret is non-zero, futex_atomic_op_inuser
+returns right away, avoiding the uninitialized use that it claims.
+Restoring the zero initialization works around this issue.
+
+[1]: https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
+
+Cc: stable@vger.kernel.org
+Fixes: 045afc24124d ("arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value")
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/futex.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/include/asm/futex.h
++++ b/arch/arm64/include/asm/futex.h
+@@ -50,7 +50,7 @@ do { \
+ static inline int
+ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *_uaddr)
+ {
+- int oldval, ret, tmp;
++ int oldval = 0, ret, tmp;
+ u32 __user *uaddr = __uaccess_mask_ptr(_uaddr);
+
+ pagefault_disable();
--- /dev/null
+From e6d0fb7b34f264f72c33053558a360a6a734905e Mon Sep 17 00:00:00 2001
+From: Ronnie Sahlberg <lsahlber@redhat.com>
+Date: Wed, 10 Apr 2019 07:47:22 +1000
+Subject: cifs: fix handle leak in smb2_query_symlink()
+
+From: Ronnie Sahlberg <lsahlber@redhat.com>
+
+commit e6d0fb7b34f264f72c33053558a360a6a734905e upstream.
+
+If we enter smb2_query_symlink() for something that is not a symlink
+and where the SMB2_open() would succeed we would never end up
+closing this handle and would thus leak a handle on the server.
+
+Fix this by immediately calling SMB2_close() on successfull open.
+
+Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/smb2ops.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/cifs/smb2ops.c
++++ b/fs/cifs/smb2ops.c
+@@ -1906,6 +1906,8 @@ smb2_query_symlink(const unsigned int xi
+
+ rc = SMB2_open(xid, &oparms, utf16_path, &oplock, NULL, &err_iov,
+ &resp_buftype);
++ if (!rc)
++ SMB2_close(xid, tcon, fid.persistent_fid, fid.volatile_fid);
+ if (!rc || !err_iov.iov_base) {
+ rc = -ENOENT;
+ goto free_path;
--- /dev/null
+From 088aaf17aa79300cab14dbee2569c58cfafd7d6e Mon Sep 17 00:00:00 2001
+From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
+Date: Sat, 6 Apr 2019 15:47:39 +0800
+Subject: cifs: Fix use-after-free in SMB2_read
+
+From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
+
+commit 088aaf17aa79300cab14dbee2569c58cfafd7d6e upstream.
+
+There is a KASAN use-after-free:
+BUG: KASAN: use-after-free in SMB2_read+0x1136/0x1190
+Read of size 8 at addr ffff8880b4e45e50 by task ln/1009
+
+Should not release the 'req' because it will use in the trace.
+
+Fixes: eccb4422cf97 ("smb3: Add ftrace tracepoints for improved SMB3 debugging")
+
+Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+CC: Stable <stable@vger.kernel.org> 4.18+
+Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/smb2pdu.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/cifs/smb2pdu.c
++++ b/fs/cifs/smb2pdu.c
+@@ -3273,8 +3273,6 @@ SMB2_read(const unsigned int xid, struct
+ rqst.rq_nvec = 1;
+
+ rc = cifs_send_recv(xid, ses, &rqst, &resp_buftype, flags, &rsp_iov);
+- cifs_small_buf_release(req);
+-
+ rsp = (struct smb2_read_rsp *)rsp_iov.iov_base;
+
+ if (rc) {
+@@ -3293,6 +3291,8 @@ SMB2_read(const unsigned int xid, struct
+ io_parms->tcon->tid, ses->Suid,
+ io_parms->offset, io_parms->length);
+
++ cifs_small_buf_release(req);
++
+ *nbytes = le32_to_cpu(rsp->DataLength);
+ if ((*nbytes > CIFS_MAX_MSGSIZE) ||
+ (*nbytes > io_parms->length)) {
--- /dev/null
+From 6a3eb3360667170988f8a6477f6686242061488a Mon Sep 17 00:00:00 2001
+From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
+Date: Sat, 6 Apr 2019 15:47:38 +0800
+Subject: cifs: Fix use-after-free in SMB2_write
+
+From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
+
+commit 6a3eb3360667170988f8a6477f6686242061488a upstream.
+
+There is a KASAN use-after-free:
+BUG: KASAN: use-after-free in SMB2_write+0x1342/0x1580
+Read of size 8 at addr ffff8880b6a8e450 by task ln/4196
+
+Should not release the 'req' because it will use in the trace.
+
+Fixes: eccb4422cf97 ("smb3: Add ftrace tracepoints for improved SMB3 debugging")
+
+Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+CC: Stable <stable@vger.kernel.org> 4.18+
+Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/smb2pdu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/cifs/smb2pdu.c
++++ b/fs/cifs/smb2pdu.c
+@@ -3591,7 +3591,6 @@ SMB2_write(const unsigned int xid, struc
+
+ rc = cifs_send_recv(xid, io_parms->tcon->ses, &rqst,
+ &resp_buftype, flags, &rsp_iov);
+- cifs_small_buf_release(req);
+ rsp = (struct smb2_write_rsp *)rsp_iov.iov_base;
+
+ if (rc) {
+@@ -3609,6 +3608,7 @@ SMB2_write(const unsigned int xid, struc
+ io_parms->offset, *nbytes);
+ }
+
++ cifs_small_buf_release(req);
+ free_rsp_buf(resp_buftype, rsp);
+ return rc;
+ }
--- /dev/null
+From b98749cac4a695f084a5ff076f4510b23e353ecd Mon Sep 17 00:00:00 2001
+From: Aurelien Aptel <aaptel@suse.com>
+Date: Fri, 29 Mar 2019 10:49:12 +0100
+Subject: CIFS: keep FileInfo handle live during oplock break
+
+From: Aurelien Aptel <aaptel@suse.com>
+
+commit b98749cac4a695f084a5ff076f4510b23e353ecd upstream.
+
+In the oplock break handler, writing pending changes from pages puts
+the FileInfo handle. If the refcount reaches zero it closes the handle
+and waits for any oplock break handler to return, thus causing a deadlock.
+
+To prevent this situation:
+
+* We add a wait flag to cifsFileInfo_put() to decide whether we should
+ wait for running/pending oplock break handlers
+
+* We keep an additionnal reference of the SMB FileInfo handle so that
+ for the rest of the handler putting the handle won't close it.
+ - The ref is bumped everytime we queue the handler via the
+ cifs_queue_oplock_break() helper.
+ - The ref is decremented at the end of the handler
+
+This bug was triggered by xfstest 464.
+
+Also important fix to address the various reports of
+oops in smb2_push_mandatory_locks
+
+Signed-off-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/cifsglob.h | 2 ++
+ fs/cifs/file.c | 30 +++++++++++++++++++++++++-----
+ fs/cifs/misc.c | 25 +++++++++++++++++++++++--
+ fs/cifs/smb2misc.c | 6 +++---
+ 4 files changed, 53 insertions(+), 10 deletions(-)
+
+--- a/fs/cifs/cifsglob.h
++++ b/fs/cifs/cifsglob.h
+@@ -1263,6 +1263,7 @@ cifsFileInfo_get_locked(struct cifsFileI
+ }
+
+ struct cifsFileInfo *cifsFileInfo_get(struct cifsFileInfo *cifs_file);
++void _cifsFileInfo_put(struct cifsFileInfo *cifs_file, bool wait_oplock_hdlr);
+ void cifsFileInfo_put(struct cifsFileInfo *cifs_file);
+
+ #define CIFS_CACHE_READ_FLG 1
+@@ -1763,6 +1764,7 @@ GLOBAL_EXTERN spinlock_t gidsidlock;
+ #endif /* CONFIG_CIFS_ACL */
+
+ void cifs_oplock_break(struct work_struct *work);
++void cifs_queue_oplock_break(struct cifsFileInfo *cfile);
+
+ extern const struct slow_work_ops cifs_oplock_break_ops;
+ extern struct workqueue_struct *cifsiod_wq;
+--- a/fs/cifs/file.c
++++ b/fs/cifs/file.c
+@@ -358,13 +358,31 @@ cifsFileInfo_get(struct cifsFileInfo *ci
+ return cifs_file;
+ }
+
+-/*
+- * Release a reference on the file private data. This may involve closing
+- * the filehandle out on the server. Must be called without holding
+- * tcon->open_file_lock and cifs_file->file_info_lock.
++/**
++ * cifsFileInfo_put - release a reference of file priv data
++ *
++ * Always potentially wait for oplock handler. See _cifsFileInfo_put().
+ */
+ void cifsFileInfo_put(struct cifsFileInfo *cifs_file)
+ {
++ _cifsFileInfo_put(cifs_file, true);
++}
++
++/**
++ * _cifsFileInfo_put - release a reference of file priv data
++ *
++ * This may involve closing the filehandle @cifs_file out on the
++ * server. Must be called without holding tcon->open_file_lock and
++ * cifs_file->file_info_lock.
++ *
++ * If @wait_for_oplock_handler is true and we are releasing the last
++ * reference, wait for any running oplock break handler of the file
++ * and cancel any pending one. If calling this function from the
++ * oplock break handler, you need to pass false.
++ *
++ */
++void _cifsFileInfo_put(struct cifsFileInfo *cifs_file, bool wait_oplock_handler)
++{
+ struct inode *inode = d_inode(cifs_file->dentry);
+ struct cifs_tcon *tcon = tlink_tcon(cifs_file->tlink);
+ struct TCP_Server_Info *server = tcon->ses->server;
+@@ -411,7 +429,8 @@ void cifsFileInfo_put(struct cifsFileInf
+
+ spin_unlock(&tcon->open_file_lock);
+
+- oplock_break_cancelled = cancel_work_sync(&cifs_file->oplock_break);
++ oplock_break_cancelled = wait_oplock_handler ?
++ cancel_work_sync(&cifs_file->oplock_break) : false;
+
+ if (!tcon->need_reconnect && !cifs_file->invalidHandle) {
+ struct TCP_Server_Info *server = tcon->ses->server;
+@@ -4170,6 +4189,7 @@ void cifs_oplock_break(struct work_struc
+ cinode);
+ cifs_dbg(FYI, "Oplock release rc = %d\n", rc);
+ }
++ _cifsFileInfo_put(cfile, false /* do not wait for ourself */);
+ cifs_done_oplock_break(cinode);
+ }
+
+--- a/fs/cifs/misc.c
++++ b/fs/cifs/misc.c
+@@ -490,8 +490,7 @@ is_valid_oplock_break(char *buffer, stru
+ CIFS_INODE_DOWNGRADE_OPLOCK_TO_L2,
+ &pCifsInode->flags);
+
+- queue_work(cifsoplockd_wq,
+- &netfile->oplock_break);
++ cifs_queue_oplock_break(netfile);
+ netfile->oplock_break_cancelled = false;
+
+ spin_unlock(&tcon->open_file_lock);
+@@ -588,6 +587,28 @@ void cifs_put_writer(struct cifsInodeInf
+ spin_unlock(&cinode->writers_lock);
+ }
+
++/**
++ * cifs_queue_oplock_break - queue the oplock break handler for cfile
++ *
++ * This function is called from the demultiplex thread when it
++ * receives an oplock break for @cfile.
++ *
++ * Assumes the tcon->open_file_lock is held.
++ * Assumes cfile->file_info_lock is NOT held.
++ */
++void cifs_queue_oplock_break(struct cifsFileInfo *cfile)
++{
++ /*
++ * Bump the handle refcount now while we hold the
++ * open_file_lock to enforce the validity of it for the oplock
++ * break handler. The matching put is done at the end of the
++ * handler.
++ */
++ cifsFileInfo_get(cfile);
++
++ queue_work(cifsoplockd_wq, &cfile->oplock_break);
++}
++
+ void cifs_done_oplock_break(struct cifsInodeInfo *cinode)
+ {
+ clear_bit(CIFS_INODE_PENDING_OPLOCK_BREAK, &cinode->flags);
+--- a/fs/cifs/smb2misc.c
++++ b/fs/cifs/smb2misc.c
+@@ -555,7 +555,7 @@ smb2_tcon_has_lease(struct cifs_tcon *tc
+ clear_bit(CIFS_INODE_DOWNGRADE_OPLOCK_TO_L2,
+ &cinode->flags);
+
+- queue_work(cifsoplockd_wq, &cfile->oplock_break);
++ cifs_queue_oplock_break(cfile);
+ kfree(lw);
+ return true;
+ }
+@@ -719,8 +719,8 @@ smb2_is_valid_oplock_break(char *buffer,
+ CIFS_INODE_DOWNGRADE_OPLOCK_TO_L2,
+ &cinode->flags);
+ spin_unlock(&cfile->file_info_lock);
+- queue_work(cifsoplockd_wq,
+- &cfile->oplock_break);
++
++ cifs_queue_oplock_break(cfile);
+
+ spin_unlock(&tcon->open_file_lock);
+ spin_unlock(&cifs_tcp_ses_lock);
--- /dev/null
+From 04f5866e41fb70690e28397487d8bd8eea7d712a Mon Sep 17 00:00:00 2001
+From: Andrea Arcangeli <aarcange@redhat.com>
+Date: Thu, 18 Apr 2019 17:50:52 -0700
+Subject: coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping
+
+From: Andrea Arcangeli <aarcange@redhat.com>
+
+commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream.
+
+The core dumping code has always run without holding the mmap_sem for
+writing, despite that is the only way to ensure that the entire vma
+layout will not change from under it. Only using some signal
+serialization on the processes belonging to the mm is not nearly enough.
+This was pointed out earlier. For example in Hugh's post from Jul 2017:
+
+ https://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils
+
+ "Not strictly relevant here, but a related note: I was very surprised
+ to discover, only quite recently, how handle_mm_fault() may be called
+ without down_read(mmap_sem) - when core dumping. That seems a
+ misguided optimization to me, which would also be nice to correct"
+
+In particular because the growsdown and growsup can move the
+vm_start/vm_end the various loops the core dump does around the vma will
+not be consistent if page faults can happen concurrently.
+
+Pretty much all users calling mmget_not_zero()/get_task_mm() and then
+taking the mmap_sem had the potential to introduce unexpected side
+effects in the core dumping code.
+
+Adding mmap_sem for writing around the ->core_dump invocation is a
+viable long term fix, but it requires removing all copy user and page
+faults and to replace them with get_dump_page() for all binary formats
+which is not suitable as a short term fix.
+
+For the time being this solution manually covers the places that can
+confuse the core dump either by altering the vma layout or the vma flags
+while it runs. Once ->core_dump runs under mmap_sem for writing the
+function mmget_still_valid() can be dropped.
+
+Allowing mmap_sem protected sections to run in parallel with the
+coredump provides some minor parallelism advantage to the swapoff code
+(which seems to be safe enough by never mangling any vma field and can
+keep doing swapins in parallel to the core dumping) and to some other
+corner case.
+
+In order to facilitate the backporting I added "Fixes: 86039bd3b4e6"
+however the side effect of this same race condition in /proc/pid/mem
+should be reproducible since before 2.6.12-rc2 so I couldn't add any
+other "Fixes:" because there's no hash beyond the git genesis commit.
+
+Because find_extend_vma() is the only location outside of the process
+context that could modify the "mm" structures under mmap_sem for
+reading, by adding the mmget_still_valid() check to it, all other cases
+that take the mmap_sem for reading don't need the new check after
+mmget_not_zero()/get_task_mm(). The expand_stack() in page fault
+context also doesn't need the new check, because all tasks under core
+dumping are frozen.
+
+Link: http://lkml.kernel.org/r/20190325224949.11068-1-aarcange@redhat.com
+Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization")
+Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
+Reported-by: Jann Horn <jannh@google.com>
+Suggested-by: Oleg Nesterov <oleg@redhat.com>
+Acked-by: Peter Xu <peterx@redhat.com>
+Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
+Reviewed-by: Oleg Nesterov <oleg@redhat.com>
+Reviewed-by: Jann Horn <jannh@google.com>
+Acked-by: Jason Gunthorpe <jgg@mellanox.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: <stable@vger.kernel.org>
+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>
+
+---
+ fs/proc/task_mmu.c | 18 ++++++++++++++++++
+ fs/userfaultfd.c | 9 +++++++++
+ include/linux/sched/mm.h | 21 +++++++++++++++++++++
+ mm/mmap.c | 7 ++++++-
+ 4 files changed, 54 insertions(+), 1 deletion(-)
+
+--- a/fs/proc/task_mmu.c
++++ b/fs/proc/task_mmu.c
+@@ -1138,6 +1138,24 @@ static ssize_t clear_refs_write(struct f
+ count = -EINTR;
+ goto out_mm;
+ }
++ /*
++ * Avoid to modify vma->vm_flags
++ * without locked ops while the
++ * coredump reads the vm_flags.
++ */
++ if (!mmget_still_valid(mm)) {
++ /*
++ * Silently return "count"
++ * like if get_task_mm()
++ * failed. FIXME: should this
++ * function have returned
++ * -ESRCH if get_task_mm()
++ * failed like if
++ * get_proc_task() fails?
++ */
++ up_write(&mm->mmap_sem);
++ goto out_mm;
++ }
+ for (vma = mm->mmap; vma; vma = vma->vm_next) {
+ vma->vm_flags &= ~VM_SOFTDIRTY;
+ vma_set_page_prot(vma);
+--- a/fs/userfaultfd.c
++++ b/fs/userfaultfd.c
+@@ -630,6 +630,8 @@ static void userfaultfd_event_wait_compl
+
+ /* the various vma->vm_userfaultfd_ctx still points to it */
+ down_write(&mm->mmap_sem);
++ /* no task can run (and in turn coredump) yet */
++ VM_WARN_ON(!mmget_still_valid(mm));
+ for (vma = mm->mmap; vma; vma = vma->vm_next)
+ if (vma->vm_userfaultfd_ctx.ctx == release_new_ctx) {
+ vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
+@@ -884,6 +886,8 @@ static int userfaultfd_release(struct in
+ * taking the mmap_sem for writing.
+ */
+ down_write(&mm->mmap_sem);
++ if (!mmget_still_valid(mm))
++ goto skip_mm;
+ prev = NULL;
+ for (vma = mm->mmap; vma; vma = vma->vm_next) {
+ cond_resched();
+@@ -906,6 +910,7 @@ static int userfaultfd_release(struct in
+ vma->vm_flags = new_flags;
+ vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
+ }
++skip_mm:
+ up_write(&mm->mmap_sem);
+ mmput(mm);
+ wakeup:
+@@ -1334,6 +1339,8 @@ static int userfaultfd_register(struct u
+ goto out;
+
+ down_write(&mm->mmap_sem);
++ if (!mmget_still_valid(mm))
++ goto out_unlock;
+ vma = find_vma_prev(mm, start, &prev);
+ if (!vma)
+ goto out_unlock;
+@@ -1521,6 +1528,8 @@ static int userfaultfd_unregister(struct
+ goto out;
+
+ down_write(&mm->mmap_sem);
++ if (!mmget_still_valid(mm))
++ goto out_unlock;
+ vma = find_vma_prev(mm, start, &prev);
+ if (!vma)
+ goto out_unlock;
+--- a/include/linux/sched/mm.h
++++ b/include/linux/sched/mm.h
+@@ -49,6 +49,27 @@ static inline void mmdrop(struct mm_stru
+ __mmdrop(mm);
+ }
+
++/*
++ * This has to be called after a get_task_mm()/mmget_not_zero()
++ * followed by taking the mmap_sem for writing before modifying the
++ * vmas or anything the coredump pretends not to change from under it.
++ *
++ * NOTE: find_extend_vma() called from GUP context is the only place
++ * that can modify the "mm" (notably the vm_start/end) under mmap_sem
++ * for reading and outside the context of the process, so it is also
++ * the only case that holds the mmap_sem for reading that must call
++ * this function. Generally if the mmap_sem is hold for reading
++ * there's no need of this check after get_task_mm()/mmget_not_zero().
++ *
++ * This function can be obsoleted and the check can be removed, after
++ * the coredump code will hold the mmap_sem for writing before
++ * invoking the ->core_dump methods.
++ */
++static inline bool mmget_still_valid(struct mm_struct *mm)
++{
++ return likely(!mm->core_state);
++}
++
+ /**
+ * mmget() - Pin the address space associated with a &struct mm_struct.
+ * @mm: The address space to pin.
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -45,6 +45,7 @@
+ #include <linux/moduleparam.h>
+ #include <linux/pkeys.h>
+ #include <linux/oom.h>
++#include <linux/sched/mm.h>
+
+ #include <linux/uaccess.h>
+ #include <asm/cacheflush.h>
+@@ -2491,7 +2492,8 @@ find_extend_vma(struct mm_struct *mm, un
+ vma = find_vma_prev(mm, addr, &prev);
+ if (vma && (vma->vm_start <= addr))
+ return vma;
+- if (!prev || expand_stack(prev, addr))
++ /* don't alter vm_end if the coredump is running */
++ if (!prev || !mmget_still_valid(mm) || expand_stack(prev, addr))
+ return NULL;
+ if (prev->vm_flags & VM_LOCKED)
+ populate_vma_page_range(prev, addr, prev->vm_end, NULL);
+@@ -2517,6 +2519,9 @@ find_extend_vma(struct mm_struct *mm, un
+ return vma;
+ if (!(vma->vm_flags & VM_GROWSDOWN))
+ return NULL;
++ /* don't alter vm_start if the coredump is running */
++ if (!mmget_still_valid(mm))
++ return NULL;
+ start = vma->vm_start;
+ if (expand_stack(vma, addr))
+ return NULL;
--- /dev/null
+From 678cce4019d746da6c680c48ba9e6d417803e127 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Sun, 31 Mar 2019 13:04:11 -0700
+Subject: crypto: x86/poly1305 - fix overflow during partial reduction
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 678cce4019d746da6c680c48ba9e6d417803e127 upstream.
+
+The x86_64 implementation of Poly1305 produces the wrong result on some
+inputs because poly1305_4block_avx2() incorrectly assumes that when
+partially reducing the accumulator, the bits carried from limb 'd4' to
+limb 'h0' fit in a 32-bit integer. This is true for poly1305-generic
+which processes only one block at a time. However, it's not true for
+the AVX2 implementation, which processes 4 blocks at a time and
+therefore can produce intermediate limbs about 4x larger.
+
+Fix it by making the relevant calculations use 64-bit arithmetic rather
+than 32-bit. Note that most of the carries already used 64-bit
+arithmetic, but the d4 -> h0 carry was different for some reason.
+
+To be safe I also made the same change to the corresponding SSE2 code,
+though that only operates on 1 or 2 blocks at a time. I don't think
+it's really needed for poly1305_block_sse2(), but it doesn't hurt
+because it's already x86_64 code. It *might* be needed for
+poly1305_2block_sse2(), but overflows aren't easy to reproduce there.
+
+This bug was originally detected by my patches that improve testmgr to
+fuzz algorithms against their generic implementation. But also add a
+test vector which reproduces it directly (in the AVX2 case).
+
+Fixes: b1ccc8f4b631 ("crypto: poly1305 - Add a four block AVX2 variant for x86_64")
+Fixes: c70f4abef07a ("crypto: poly1305 - Add a SSE2 SIMD variant for x86_64")
+Cc: <stable@vger.kernel.org> # v4.3+
+Cc: Martin Willi <martin@strongswan.org>
+Cc: Jason A. Donenfeld <Jason@zx2c4.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Reviewed-by: Martin Willi <martin@strongswan.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/crypto/poly1305-avx2-x86_64.S | 14 +++++++---
+ arch/x86/crypto/poly1305-sse2-x86_64.S | 22 ++++++++++------
+ crypto/testmgr.h | 44 ++++++++++++++++++++++++++++++++-
+ 3 files changed, 67 insertions(+), 13 deletions(-)
+
+--- a/arch/x86/crypto/poly1305-avx2-x86_64.S
++++ b/arch/x86/crypto/poly1305-avx2-x86_64.S
+@@ -323,6 +323,12 @@ ENTRY(poly1305_4block_avx2)
+ vpaddq t2,t1,t1
+ vmovq t1x,d4
+
++ # Now do a partial reduction mod (2^130)-5, carrying h0 -> h1 -> h2 ->
++ # h3 -> h4 -> h0 -> h1 to get h0,h2,h3,h4 < 2^26 and h1 < 2^26 + a small
++ # amount. Careful: we must not assume the carry bits 'd0 >> 26',
++ # 'd1 >> 26', 'd2 >> 26', 'd3 >> 26', and '(d4 >> 26) * 5' fit in 32-bit
++ # integers. It's true in a single-block implementation, but not here.
++
+ # d1 += d0 >> 26
+ mov d0,%rax
+ shr $26,%rax
+@@ -361,16 +367,16 @@ ENTRY(poly1305_4block_avx2)
+ # h0 += (d4 >> 26) * 5
+ mov d4,%rax
+ shr $26,%rax
+- lea (%eax,%eax,4),%eax
+- add %eax,%ebx
++ lea (%rax,%rax,4),%rax
++ add %rax,%rbx
+ # h4 = d4 & 0x3ffffff
+ mov d4,%rax
+ and $0x3ffffff,%eax
+ mov %eax,h4
+
+ # h1 += h0 >> 26
+- mov %ebx,%eax
+- shr $26,%eax
++ mov %rbx,%rax
++ shr $26,%rax
+ add %eax,h1
+ # h0 = h0 & 0x3ffffff
+ andl $0x3ffffff,%ebx
+--- a/arch/x86/crypto/poly1305-sse2-x86_64.S
++++ b/arch/x86/crypto/poly1305-sse2-x86_64.S
+@@ -253,16 +253,16 @@ ENTRY(poly1305_block_sse2)
+ # h0 += (d4 >> 26) * 5
+ mov d4,%rax
+ shr $26,%rax
+- lea (%eax,%eax,4),%eax
+- add %eax,%ebx
++ lea (%rax,%rax,4),%rax
++ add %rax,%rbx
+ # h4 = d4 & 0x3ffffff
+ mov d4,%rax
+ and $0x3ffffff,%eax
+ mov %eax,h4
+
+ # h1 += h0 >> 26
+- mov %ebx,%eax
+- shr $26,%eax
++ mov %rbx,%rax
++ shr $26,%rax
+ add %eax,h1
+ # h0 = h0 & 0x3ffffff
+ andl $0x3ffffff,%ebx
+@@ -520,6 +520,12 @@ ENTRY(poly1305_2block_sse2)
+ paddq t2,t1
+ movq t1,d4
+
++ # Now do a partial reduction mod (2^130)-5, carrying h0 -> h1 -> h2 ->
++ # h3 -> h4 -> h0 -> h1 to get h0,h2,h3,h4 < 2^26 and h1 < 2^26 + a small
++ # amount. Careful: we must not assume the carry bits 'd0 >> 26',
++ # 'd1 >> 26', 'd2 >> 26', 'd3 >> 26', and '(d4 >> 26) * 5' fit in 32-bit
++ # integers. It's true in a single-block implementation, but not here.
++
+ # d1 += d0 >> 26
+ mov d0,%rax
+ shr $26,%rax
+@@ -558,16 +564,16 @@ ENTRY(poly1305_2block_sse2)
+ # h0 += (d4 >> 26) * 5
+ mov d4,%rax
+ shr $26,%rax
+- lea (%eax,%eax,4),%eax
+- add %eax,%ebx
++ lea (%rax,%rax,4),%rax
++ add %rax,%rbx
+ # h4 = d4 & 0x3ffffff
+ mov d4,%rax
+ and $0x3ffffff,%eax
+ mov %eax,h4
+
+ # h1 += h0 >> 26
+- mov %ebx,%eax
+- shr $26,%eax
++ mov %rbx,%rax
++ shr $26,%rax
+ add %eax,h1
+ # h0 = h0 & 0x3ffffff
+ andl $0x3ffffff,%ebx
+--- a/crypto/testmgr.h
++++ b/crypto/testmgr.h
+@@ -5592,7 +5592,49 @@ static const struct hash_testvec poly130
+ .psize = 80,
+ .digest = "\x13\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x00",
+- },
++ }, { /* Regression test for overflow in AVX2 implementation */
++ .plaintext = "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff\xff\xff\xff\xff"
++ "\xff\xff\xff\xff",
++ .psize = 300,
++ .digest = "\xfb\x5e\x96\xd8\x61\xd5\xc7\xc8"
++ "\x78\xe5\x87\xcc\x2d\x5a\x22\xe1",
++ }
+ };
+
+ /*
--- /dev/null
+From 1925e7d3d4677e681cc2e878c2bdbeaee988c8e2 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 11 Apr 2019 14:54:40 -0500
+Subject: drm/amdgpu/gmc9: fix VM_L2_CNTL3 programming
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 1925e7d3d4677e681cc2e878c2bdbeaee988c8e2 upstream.
+
+Got accidently dropped when 2+1 level support was added.
+
+Fixes: 6a42fd6fbf534096 ("drm/amdgpu: implement 2+1 PD support for Raven v3")
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
+@@ -164,6 +164,7 @@ static void mmhub_v1_0_init_cache_regs(s
+ tmp = REG_SET_FIELD(tmp, VM_L2_CNTL3,
+ L2_CACHE_BIGK_FRAGMENT_SIZE, 6);
+ }
++ WREG32_SOC15(MMHUB, 0, mmVM_L2_CNTL3, tmp);
+
+ tmp = mmVM_L2_CNTL4_DEFAULT;
+ tmp = REG_SET_FIELD(tmp, VM_L2_CNTL4, VMC_TAP_PDE_REQUEST_PHYSICAL, 0);
--- /dev/null
+From a66477b0efe511d98dde3e4aaeb189790e6f0a39 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
+Date: Tue, 2 Apr 2019 09:26:52 +0200
+Subject: drm/ttm: fix out-of-bounds read in ttm_put_pages() v2
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Christian König <christian.koenig@amd.com>
+
+commit a66477b0efe511d98dde3e4aaeb189790e6f0a39 upstream.
+
+When ttm_put_pages() tries to figure out whether it's dealing with
+transparent hugepages, it just reads past the bounds of the pages array
+without a check.
+
+v2: simplify the test if enough pages are left in the array (Christian).
+
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Fixes: 5c42c64f7d54 ("drm/ttm: fix the fix for huge compound pages")
+Cc: stable@vger.kernel.org
+Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
+Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
+Reviewed-by: Huang Rui <ray.huang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
++++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
+@@ -730,7 +730,8 @@ static void ttm_put_pages(struct page **
+ }
+
+ #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+- if (!(flags & TTM_PAGE_FLAG_DMA32)) {
++ if (!(flags & TTM_PAGE_FLAG_DMA32) &&
++ (npages - i) >= HPAGE_PMD_NR) {
+ for (j = 0; j < HPAGE_PMD_NR; ++j)
+ if (p++ != pages[i + j])
+ break;
+@@ -759,7 +760,7 @@ static void ttm_put_pages(struct page **
+ unsigned max_size, n2free;
+
+ spin_lock_irqsave(&huge->lock, irq_flags);
+- while (i < npages) {
++ while ((npages - i) >= HPAGE_PMD_NR) {
+ struct page *p = pages[i];
+ unsigned j;
+
--- /dev/null
+From fccfb9ce70ed4ea7a145f77b86de62e38178517f Mon Sep 17 00:00:00 2001
+From: Dragos Bogdan <dragos.bogdan@analog.com>
+Date: Tue, 19 Mar 2019 12:47:00 +0200
+Subject: iio: ad_sigma_delta: select channel when reading register
+
+From: Dragos Bogdan <dragos.bogdan@analog.com>
+
+commit fccfb9ce70ed4ea7a145f77b86de62e38178517f upstream.
+
+The desired channel has to be selected in order to correctly fill the
+buffer with the corresponding data.
+The `ad_sd_write_reg()` already does this, but for the
+`ad_sd_read_reg_raw()` this was omitted.
+
+Fixes: af3008485ea03 ("iio:adc: Add common code for ADI Sigma Delta devices")
+Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
+Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/ad_sigma_delta.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/iio/adc/ad_sigma_delta.c
++++ b/drivers/iio/adc/ad_sigma_delta.c
+@@ -121,6 +121,7 @@ static int ad_sd_read_reg_raw(struct ad_
+ if (sigma_delta->info->has_registers) {
+ data[0] = reg << sigma_delta->info->addr_shift;
+ data[0] |= sigma_delta->info->read_mask;
++ data[0] |= sigma_delta->comm;
+ spi_message_add_tail(&t[0], &m);
+ }
+ spi_message_add_tail(&t[1], &m);
--- /dev/null
+From 09c6bdee51183a575bf7546890c8c137a75a2b44 Mon Sep 17 00:00:00 2001
+From: Georg Ottinger <g.ottinger@abatec.at>
+Date: Wed, 30 Jan 2019 14:42:02 +0100
+Subject: iio: adc: at91: disable adc channel interrupt in timeout case
+
+From: Georg Ottinger <g.ottinger@abatec.at>
+
+commit 09c6bdee51183a575bf7546890c8c137a75a2b44 upstream.
+
+Having a brief look at at91_adc_read_raw() it is obvious that in the case
+of a timeout the setting of AT91_ADC_CHDR and AT91_ADC_IDR registers is
+omitted. If 2 different channels are queried we can end up with a
+situation where two interrupts are enabled, but only one interrupt is
+cleared in the interrupt handler. Resulting in a interrupt loop and a
+system hang.
+
+Signed-off-by: Georg Ottinger <g.ottinger@abatec.at>
+Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/at91_adc.c | 28 +++++++++++++++++-----------
+ 1 file changed, 17 insertions(+), 11 deletions(-)
+
+--- a/drivers/iio/adc/at91_adc.c
++++ b/drivers/iio/adc/at91_adc.c
+@@ -704,23 +704,29 @@ static int at91_adc_read_raw(struct iio_
+ ret = wait_event_interruptible_timeout(st->wq_data_avail,
+ st->done,
+ msecs_to_jiffies(1000));
+- if (ret == 0)
+- ret = -ETIMEDOUT;
+- if (ret < 0) {
+- mutex_unlock(&st->lock);
+- return ret;
+- }
+-
+- *val = st->last_value;
+
++ /* Disable interrupts, regardless if adc conversion was
++ * successful or not
++ */
+ at91_adc_writel(st, AT91_ADC_CHDR,
+ AT91_ADC_CH(chan->channel));
+ at91_adc_writel(st, AT91_ADC_IDR, BIT(chan->channel));
+
+- st->last_value = 0;
+- st->done = false;
++ if (ret > 0) {
++ /* a valid conversion took place */
++ *val = st->last_value;
++ st->last_value = 0;
++ st->done = false;
++ ret = IIO_VAL_INT;
++ } else if (ret == 0) {
++ /* conversion timeout */
++ dev_err(&idev->dev, "ADC Channel %d timeout.\n",
++ chan->channel);
++ ret = -ETIMEDOUT;
++ }
++
+ mutex_unlock(&st->lock);
+- return IIO_VAL_INT;
++ return ret;
+
+ case IIO_CHAN_INFO_SCALE:
+ *val = st->vref_mv;
--- /dev/null
+From 9436f45dd53595e21566a8c6627411077dfdb776 Mon Sep 17 00:00:00 2001
+From: Mike Looijmans <mike.looijmans@topic.nl>
+Date: Wed, 6 Mar 2019 08:31:47 +0100
+Subject: iio:chemical:bme680: Fix, report temperature in millidegrees
+
+From: Mike Looijmans <mike.looijmans@topic.nl>
+
+commit 9436f45dd53595e21566a8c6627411077dfdb776 upstream.
+
+The standard unit for temperature is millidegrees Celcius. Adapt the
+driver to report in millidegrees instead of degrees.
+
+Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
+Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor");
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/chemical/bme680_core.c | 16 +++++++---------
+ 1 file changed, 7 insertions(+), 9 deletions(-)
+
+--- a/drivers/iio/chemical/bme680_core.c
++++ b/drivers/iio/chemical/bme680_core.c
+@@ -591,8 +591,7 @@ static int bme680_gas_config(struct bme6
+ return ret;
+ }
+
+-static int bme680_read_temp(struct bme680_data *data,
+- int *val, int *val2)
++static int bme680_read_temp(struct bme680_data *data, int *val)
+ {
+ struct device *dev = regmap_get_device(data->regmap);
+ int ret;
+@@ -625,10 +624,9 @@ static int bme680_read_temp(struct bme68
+ * compensate_press/compensate_humid to get compensated
+ * pressure/humidity readings.
+ */
+- if (val && val2) {
+- *val = comp_temp;
+- *val2 = 100;
+- return IIO_VAL_FRACTIONAL;
++ if (val) {
++ *val = comp_temp * 10; /* Centidegrees to millidegrees */
++ return IIO_VAL_INT;
+ }
+
+ return ret;
+@@ -643,7 +641,7 @@ static int bme680_read_press(struct bme6
+ s32 adc_press;
+
+ /* Read and compensate temperature to get a reading of t_fine */
+- ret = bme680_read_temp(data, NULL, NULL);
++ ret = bme680_read_temp(data, NULL);
+ if (ret < 0)
+ return ret;
+
+@@ -676,7 +674,7 @@ static int bme680_read_humid(struct bme6
+ u32 comp_humidity;
+
+ /* Read and compensate temperature to get a reading of t_fine */
+- ret = bme680_read_temp(data, NULL, NULL);
++ ret = bme680_read_temp(data, NULL);
+ if (ret < 0)
+ return ret;
+
+@@ -769,7 +767,7 @@ static int bme680_read_raw(struct iio_de
+ case IIO_CHAN_INFO_PROCESSED:
+ switch (chan->type) {
+ case IIO_TEMP:
+- return bme680_read_temp(data, val, val2);
++ return bme680_read_temp(data, val);
+ case IIO_PRESSURE:
+ return bme680_read_press(data, val, val2);
+ case IIO_HUMIDITYRELATIVE:
--- /dev/null
+From 73f3bc6da506711302bb67572440eb84b1ec4a2c Mon Sep 17 00:00:00 2001
+From: Mike Looijmans <mike.looijmans@topic.nl>
+Date: Wed, 6 Mar 2019 08:31:48 +0100
+Subject: iio:chemical:bme680: Fix SPI read interface
+
+From: Mike Looijmans <mike.looijmans@topic.nl>
+
+commit 73f3bc6da506711302bb67572440eb84b1ec4a2c upstream.
+
+The SPI interface implementation was completely broken.
+
+When using the SPI interface, there are only 7 address bits, the upper bit
+is controlled by a page select register. The core needs access to both
+ranges, so implement register read/write for both regions. The regmap
+paging functionality didn't agree with a register that needs to be read
+and modified, so I implemented a custom paging algorithm.
+
+This fixes that the device wouldn't even probe in SPI mode.
+
+The SPI interface then isn't different from I2C, merged them into the core,
+and the I2C/SPI named registers are no longer needed.
+
+Implemented register value caching for the registers to reduce the I2C/SPI
+data transfers considerably.
+
+The calibration set reads as all zeroes until some undefined point in time,
+and I couldn't determine what makes it valid. The datasheet mentions these
+registers but does not provide any hints on when they become valid, and they
+aren't even enumerated in the memory map. So check the calibration and
+retry reading it from the device after each measurement until it provides
+something valid.
+
+Despite the size this is suitable for a stable backport given that
+it seems the SPI support never worked.
+
+Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
+Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor");
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/chemical/bme680.h | 6 -
+ drivers/iio/chemical/bme680_core.c | 38 ++++++++++++
+ drivers/iio/chemical/bme680_i2c.c | 21 ------
+ drivers/iio/chemical/bme680_spi.c | 115 +++++++++++++++++++++++++------------
+ 4 files changed, 118 insertions(+), 62 deletions(-)
+
+--- a/drivers/iio/chemical/bme680.h
++++ b/drivers/iio/chemical/bme680.h
+@@ -2,11 +2,9 @@
+ #ifndef BME680_H_
+ #define BME680_H_
+
+-#define BME680_REG_CHIP_I2C_ID 0xD0
+-#define BME680_REG_CHIP_SPI_ID 0x50
++#define BME680_REG_CHIP_ID 0xD0
+ #define BME680_CHIP_ID_VAL 0x61
+-#define BME680_REG_SOFT_RESET_I2C 0xE0
+-#define BME680_REG_SOFT_RESET_SPI 0x60
++#define BME680_REG_SOFT_RESET 0xE0
+ #define BME680_CMD_SOFTRESET 0xB6
+ #define BME680_REG_STATUS 0x73
+ #define BME680_SPI_MEM_PAGE_BIT BIT(4)
+--- a/drivers/iio/chemical/bme680_core.c
++++ b/drivers/iio/chemical/bme680_core.c
+@@ -63,9 +63,23 @@ struct bme680_data {
+ s32 t_fine;
+ };
+
++static const struct regmap_range bme680_volatile_ranges[] = {
++ regmap_reg_range(BME680_REG_MEAS_STAT_0, BME680_REG_GAS_R_LSB),
++ regmap_reg_range(BME680_REG_STATUS, BME680_REG_STATUS),
++ regmap_reg_range(BME680_T2_LSB_REG, BME680_GH3_REG),
++};
++
++static const struct regmap_access_table bme680_volatile_table = {
++ .yes_ranges = bme680_volatile_ranges,
++ .n_yes_ranges = ARRAY_SIZE(bme680_volatile_ranges),
++};
++
+ const struct regmap_config bme680_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
++ .max_register = 0xef,
++ .volatile_table = &bme680_volatile_table,
++ .cache_type = REGCACHE_RBTREE,
+ };
+ EXPORT_SYMBOL(bme680_regmap_config);
+
+@@ -330,6 +344,10 @@ static s16 bme680_compensate_temp(struct
+ s64 var1, var2, var3;
+ s16 calc_temp;
+
++ /* If the calibration is invalid, attempt to reload it */
++ if (!calib->par_t2)
++ bme680_read_calib(data, calib);
++
+ var1 = (adc_temp >> 3) - (calib->par_t1 << 1);
+ var2 = (var1 * calib->par_t2) >> 11;
+ var3 = ((var1 >> 1) * (var1 >> 1)) >> 12;
+@@ -903,8 +921,28 @@ int bme680_core_probe(struct device *dev
+ {
+ struct iio_dev *indio_dev;
+ struct bme680_data *data;
++ unsigned int val;
+ int ret;
+
++ ret = regmap_write(regmap, BME680_REG_SOFT_RESET,
++ BME680_CMD_SOFTRESET);
++ if (ret < 0) {
++ dev_err(dev, "Failed to reset chip\n");
++ return ret;
++ }
++
++ ret = regmap_read(regmap, BME680_REG_CHIP_ID, &val);
++ if (ret < 0) {
++ dev_err(dev, "Error reading chip ID\n");
++ return ret;
++ }
++
++ if (val != BME680_CHIP_ID_VAL) {
++ dev_err(dev, "Wrong chip ID, got %x expected %x\n",
++ val, BME680_CHIP_ID_VAL);
++ return -ENODEV;
++ }
++
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
+ if (!indio_dev)
+ return -ENOMEM;
+--- a/drivers/iio/chemical/bme680_i2c.c
++++ b/drivers/iio/chemical/bme680_i2c.c
+@@ -23,8 +23,6 @@ static int bme680_i2c_probe(struct i2c_c
+ {
+ struct regmap *regmap;
+ const char *name = NULL;
+- unsigned int val;
+- int ret;
+
+ regmap = devm_regmap_init_i2c(client, &bme680_regmap_config);
+ if (IS_ERR(regmap)) {
+@@ -33,25 +31,6 @@ static int bme680_i2c_probe(struct i2c_c
+ return PTR_ERR(regmap);
+ }
+
+- ret = regmap_write(regmap, BME680_REG_SOFT_RESET_I2C,
+- BME680_CMD_SOFTRESET);
+- if (ret < 0) {
+- dev_err(&client->dev, "Failed to reset chip\n");
+- return ret;
+- }
+-
+- ret = regmap_read(regmap, BME680_REG_CHIP_I2C_ID, &val);
+- if (ret < 0) {
+- dev_err(&client->dev, "Error reading I2C chip ID\n");
+- return ret;
+- }
+-
+- if (val != BME680_CHIP_ID_VAL) {
+- dev_err(&client->dev, "Wrong chip ID, got %x expected %x\n",
+- val, BME680_CHIP_ID_VAL);
+- return -ENODEV;
+- }
+-
+ if (id)
+ name = id->name;
+
+--- a/drivers/iio/chemical/bme680_spi.c
++++ b/drivers/iio/chemical/bme680_spi.c
+@@ -11,28 +11,93 @@
+
+ #include "bme680.h"
+
++struct bme680_spi_bus_context {
++ struct spi_device *spi;
++ u8 current_page;
++};
++
++/*
++ * In SPI mode there are only 7 address bits, a "page" register determines
++ * which part of the 8-bit range is active. This function looks at the address
++ * and writes the page selection bit if needed
++ */
++static int bme680_regmap_spi_select_page(
++ struct bme680_spi_bus_context *ctx, u8 reg)
++{
++ struct spi_device *spi = ctx->spi;
++ int ret;
++ u8 buf[2];
++ u8 page = (reg & 0x80) ? 0 : 1; /* Page "1" is low range */
++
++ if (page == ctx->current_page)
++ return 0;
++
++ /*
++ * Data sheet claims we're only allowed to change bit 4, so we must do
++ * a read-modify-write on each and every page select
++ */
++ buf[0] = BME680_REG_STATUS;
++ ret = spi_write_then_read(spi, buf, 1, buf + 1, 1);
++ if (ret < 0) {
++ dev_err(&spi->dev, "failed to set page %u\n", page);
++ return ret;
++ }
++
++ buf[0] = BME680_REG_STATUS;
++ if (page)
++ buf[1] |= BME680_SPI_MEM_PAGE_BIT;
++ else
++ buf[1] &= ~BME680_SPI_MEM_PAGE_BIT;
++
++ ret = spi_write(spi, buf, 2);
++ if (ret < 0) {
++ dev_err(&spi->dev, "failed to set page %u\n", page);
++ return ret;
++ }
++
++ ctx->current_page = page;
++
++ return 0;
++}
++
+ static int bme680_regmap_spi_write(void *context, const void *data,
+ size_t count)
+ {
+- struct spi_device *spi = context;
++ struct bme680_spi_bus_context *ctx = context;
++ struct spi_device *spi = ctx->spi;
++ int ret;
+ u8 buf[2];
+
+ memcpy(buf, data, 2);
++
++ ret = bme680_regmap_spi_select_page(ctx, buf[0]);
++ if (ret)
++ return ret;
++
+ /*
+ * The SPI register address (= full register address without bit 7)
+ * and the write command (bit7 = RW = '0')
+ */
+ buf[0] &= ~0x80;
+
+- return spi_write_then_read(spi, buf, 2, NULL, 0);
++ return spi_write(spi, buf, 2);
+ }
+
+ static int bme680_regmap_spi_read(void *context, const void *reg,
+ size_t reg_size, void *val, size_t val_size)
+ {
+- struct spi_device *spi = context;
++ struct bme680_spi_bus_context *ctx = context;
++ struct spi_device *spi = ctx->spi;
++ int ret;
++ u8 addr = *(const u8 *)reg;
++
++ ret = bme680_regmap_spi_select_page(ctx, addr);
++ if (ret)
++ return ret;
++
++ addr |= 0x80; /* bit7 = RW = '1' */
+
+- return spi_write_then_read(spi, reg, reg_size, val, val_size);
++ return spi_write_then_read(spi, &addr, 1, val, val_size);
+ }
+
+ static struct regmap_bus bme680_regmap_bus = {
+@@ -45,8 +110,8 @@ static struct regmap_bus bme680_regmap_b
+ static int bme680_spi_probe(struct spi_device *spi)
+ {
+ const struct spi_device_id *id = spi_get_device_id(spi);
++ struct bme680_spi_bus_context *bus_context;
+ struct regmap *regmap;
+- unsigned int val;
+ int ret;
+
+ spi->bits_per_word = 8;
+@@ -56,45 +121,21 @@ static int bme680_spi_probe(struct spi_d
+ return ret;
+ }
+
++ bus_context = devm_kzalloc(&spi->dev, sizeof(*bus_context), GFP_KERNEL);
++ if (!bus_context)
++ return -ENOMEM;
++
++ bus_context->spi = spi;
++ bus_context->current_page = 0xff; /* Undefined on warm boot */
++
+ regmap = devm_regmap_init(&spi->dev, &bme680_regmap_bus,
+- &spi->dev, &bme680_regmap_config);
++ bus_context, &bme680_regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(&spi->dev, "Failed to register spi regmap %d\n",
+ (int)PTR_ERR(regmap));
+ return PTR_ERR(regmap);
+ }
+
+- ret = regmap_write(regmap, BME680_REG_SOFT_RESET_SPI,
+- BME680_CMD_SOFTRESET);
+- if (ret < 0) {
+- dev_err(&spi->dev, "Failed to reset chip\n");
+- return ret;
+- }
+-
+- /* after power-on reset, Page 0(0x80-0xFF) of spi_mem_page is active */
+- ret = regmap_read(regmap, BME680_REG_CHIP_SPI_ID, &val);
+- if (ret < 0) {
+- dev_err(&spi->dev, "Error reading SPI chip ID\n");
+- return ret;
+- }
+-
+- if (val != BME680_CHIP_ID_VAL) {
+- dev_err(&spi->dev, "Wrong chip ID, got %x expected %x\n",
+- val, BME680_CHIP_ID_VAL);
+- return -ENODEV;
+- }
+- /*
+- * select Page 1 of spi_mem_page to enable access to
+- * to registers from address 0x00 to 0x7F.
+- */
+- ret = regmap_write_bits(regmap, BME680_REG_STATUS,
+- BME680_SPI_MEM_PAGE_BIT,
+- BME680_SPI_MEM_PAGE_1_VAL);
+- if (ret < 0) {
+- dev_err(&spi->dev, "failed to set page 1 of spi_mem_page\n");
+- return ret;
+- }
+-
+ return bme680_core_probe(&spi->dev, regmap, id->name);
+ }
+
--- /dev/null
+From 7f75591fc5a123929a29636834d1bcb8b5c9fee3 Mon Sep 17 00:00:00 2001
+From: Fabrice Gasnier <fabrice.gasnier@st.com>
+Date: Mon, 25 Mar 2019 14:01:23 +0100
+Subject: iio: core: fix a possible circular locking dependency
+
+From: Fabrice Gasnier <fabrice.gasnier@st.com>
+
+commit 7f75591fc5a123929a29636834d1bcb8b5c9fee3 upstream.
+
+This fixes a possible circular locking dependency detected warning seen
+with:
+- CONFIG_PROVE_LOCKING=y
+- consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
+
+When using the IIO consumer interface, e.g. iio_channel_get(), the consumer
+device will likely call iio_read_channel_raw() or similar that rely on
+'info_exist_lock' mutex.
+
+typically:
+...
+ mutex_lock(&chan->indio_dev->info_exist_lock);
+ if (chan->indio_dev->info == NULL) {
+ ret = -ENODEV;
+ goto err_unlock;
+ }
+ ret = do_some_ops()
+err_unlock:
+ mutex_unlock(&chan->indio_dev->info_exist_lock);
+ return ret;
+...
+
+Same mutex is also hold in iio_device_unregister().
+
+The following deadlock warning happens when:
+- the consumer device has called an API like iio_read_channel_raw()
+ at least once.
+- the consumer driver is unregistered, removed (unbind from sysfs)
+
+======================================================
+WARNING: possible circular locking dependency detected
+4.19.24 #577 Not tainted
+------------------------------------------------------
+sh/372 is trying to acquire lock:
+(kn->count#30){++++}, at: kernfs_remove_by_name_ns+0x3c/0x84
+
+but task is already holding lock:
+(&dev->info_exist_lock){+.+.}, at: iio_device_unregister+0x18/0x60
+
+which lock already depends on the new lock.
+
+the existing dependency chain (in reverse order) is:
+
+-> #1 (&dev->info_exist_lock){+.+.}:
+ __mutex_lock+0x70/0xa3c
+ mutex_lock_nested+0x1c/0x24
+ iio_read_channel_raw+0x1c/0x60
+ iio_read_channel_info+0xa8/0xb0
+ dev_attr_show+0x1c/0x48
+ sysfs_kf_seq_show+0x84/0xec
+ seq_read+0x154/0x528
+ __vfs_read+0x2c/0x15c
+ vfs_read+0x8c/0x110
+ ksys_read+0x4c/0xac
+ ret_fast_syscall+0x0/0x28
+ 0xbedefb60
+
+-> #0 (kn->count#30){++++}:
+ lock_acquire+0xd8/0x268
+ __kernfs_remove+0x288/0x374
+ kernfs_remove_by_name_ns+0x3c/0x84
+ remove_files+0x34/0x78
+ sysfs_remove_group+0x40/0x9c
+ sysfs_remove_groups+0x24/0x34
+ device_remove_attrs+0x38/0x64
+ device_del+0x11c/0x360
+ cdev_device_del+0x14/0x2c
+ iio_device_unregister+0x24/0x60
+ release_nodes+0x1bc/0x200
+ device_release_driver_internal+0x1a0/0x230
+ unbind_store+0x80/0x130
+ kernfs_fop_write+0x100/0x1e4
+ __vfs_write+0x2c/0x160
+ vfs_write+0xa4/0x17c
+ ksys_write+0x4c/0xac
+ ret_fast_syscall+0x0/0x28
+ 0xbe906840
+
+other info that might help us debug this:
+
+ Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(&dev->info_exist_lock);
+ lock(kn->count#30);
+ lock(&dev->info_exist_lock);
+ lock(kn->count#30);
+
+ *** DEADLOCK ***
+...
+
+cdev_device_del() can be called without holding the lock. It should be safe
+as info_exist_lock prevents kernelspace consumers to use the exported
+routines during/after provider removal. cdev_device_del() is for userspace.
+
+Help to reproduce:
+See example: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
+sysv {
+ compatible = "voltage-divider";
+ io-channels = <&adc 0>;
+ output-ohms = <22>;
+ full-ohms = <222>;
+};
+
+First, go to iio:deviceX for the "voltage-divider", do one read:
+$ cd /sys/bus/iio/devices/iio:deviceX
+$ cat in_voltage0_raw
+
+Then, unbind the consumer driver. It triggers above deadlock warning.
+$ cd /sys/bus/platform/drivers/iio-rescale/
+$ echo sysv > unbind
+
+Note I don't actually expect stable will pick this up all the
+way back into IIO being in staging, but if's probably valid that
+far back.
+
+Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
+Fixes: ac917a81117c ("staging:iio:core set the iio_dev.info pointer to null on unregister")
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/industrialio-core.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/industrialio-core.c
++++ b/drivers/iio/industrialio-core.c
+@@ -1735,10 +1735,10 @@ EXPORT_SYMBOL(__iio_device_register);
+ **/
+ void iio_device_unregister(struct iio_dev *indio_dev)
+ {
+- mutex_lock(&indio_dev->info_exist_lock);
+-
+ cdev_device_del(&indio_dev->chrdev, &indio_dev->dev);
+
++ mutex_lock(&indio_dev->info_exist_lock);
++
+ iio_device_unregister_debugfs(indio_dev);
+
+ iio_disable_all_buffers(indio_dev);
--- /dev/null
+From 3d02d7082e5823598090530c3988a35f69689943 Mon Sep 17 00:00:00 2001
+From: Gwendal Grignou <gwendal@chromium.org>
+Date: Wed, 13 Mar 2019 12:40:02 +0100
+Subject: iio: cros_ec: Fix the maths for gyro scale calculation
+
+From: Gwendal Grignou <gwendal@chromium.org>
+
+commit 3d02d7082e5823598090530c3988a35f69689943 upstream.
+
+Calculation did not use IIO_DEGREE_TO_RAD and implemented a variant to
+avoid precision loss as we aim a nano value. The offset added to avoid
+rounding error, though, doesn't give us a close result to the expected
+value. E.g.
+
+For 1000dps, the result should be:
+
+ (1000 * pi ) / 180 >> 15 ~= 0.000532632218
+
+But with current calculation we get
+
+ $ cat scale
+ 0.000547890
+
+Fix the calculation by just doing the maths involved for a nano value
+
+ val * pi * 10e12 / (180 * 2^15)
+
+so we get a closer result.
+
+ $ cat scale
+ 0.000532632
+
+Fixes: c14dca07a31d ("iio: cros_ec_sensors: add ChromeOS EC Contiguous Sensors driver")
+Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
+Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
++++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
+@@ -103,9 +103,10 @@ static int cros_ec_sensors_read(struct i
+ * Do not use IIO_DEGREE_TO_RAD to avoid precision
+ * loss. Round to the nearest integer.
+ */
+- *val = div_s64(val64 * 314159 + 9000000ULL, 1000);
+- *val2 = 18000 << (CROS_EC_SENSOR_BITS - 1);
+- ret = IIO_VAL_FRACTIONAL;
++ *val = 0;
++ *val2 = div_s64(val64 * 3141592653ULL,
++ 180 << (CROS_EC_SENSOR_BITS - 1));
++ ret = IIO_VAL_INT_PLUS_NANO;
+ break;
+ case MOTIONSENSE_TYPE_MAG:
+ /*
--- /dev/null
+From 06003531502d06bc89d32528f6ec96bf978790f9 Mon Sep 17 00:00:00 2001
+From: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
+Date: Wed, 6 Mar 2019 15:56:06 -0500
+Subject: iio: dac: mcp4725: add missing powerdown bits in store eeprom
+
+From: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
+
+commit 06003531502d06bc89d32528f6ec96bf978790f9 upstream.
+
+When issuing the write DAC register and write eeprom command, the two
+powerdown bits (PD0 and PD1) are assumed by the chip to be present in
+the bytes sent. Leaving them at 0 implies "powerdown disabled" which is
+a different state that the current one. By adding the current state of
+the powerdown in the i2c write, the chip will correctly power-on exactly
+like as it is at the moment of store_eeprom call.
+
+This is documented in MCP4725's datasheet, FIGURE 6-2: "Write Commands
+for DAC Input Register and EEPROM" and MCP4726's datasheet, FIGURE 6-3:
+"Write All Memory Command".
+
+Signed-off-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
+Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/dac/mcp4725.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/iio/dac/mcp4725.c
++++ b/drivers/iio/dac/mcp4725.c
+@@ -98,6 +98,7 @@ static ssize_t mcp4725_store_eeprom(stru
+
+ inoutbuf[0] = 0x60; /* write EEPROM */
+ inoutbuf[0] |= data->ref_mode << 3;
++ inoutbuf[0] |= data->powerdown ? ((data->powerdown_mode + 1) << 1) : 0;
+ inoutbuf[1] = data->dac_value >> 4;
+ inoutbuf[2] = (data->dac_value & 0xf) << 4;
+
--- /dev/null
+From 20ea39ef9f2f911bd01c69519e7d69cfec79fde3 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Wed, 20 Feb 2019 17:11:32 +0200
+Subject: iio: Fix scan mask selection
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 20ea39ef9f2f911bd01c69519e7d69cfec79fde3 upstream.
+
+The trialmask is expected to have all bits set to 0 after allocation.
+Currently kmalloc_array() is used which does not zero the memory and so
+random bits are set. This results in random channels being enabled when
+they shouldn't. Replace kmalloc_array() with kcalloc() which has the same
+interface but zeros the memory.
+
+Note the fix is actually required earlier than the below fixes tag, but
+will require a manual backport due to move from kmalloc to kmalloc_array.
+
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Fixes commit 057ac1acdfc4 ("iio: Use kmalloc_array() in iio_scan_mask_set()").
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/industrialio-buffer.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/industrialio-buffer.c
++++ b/drivers/iio/industrialio-buffer.c
+@@ -320,9 +320,8 @@ static int iio_scan_mask_set(struct iio_
+ const unsigned long *mask;
+ unsigned long *trialmask;
+
+- trialmask = kmalloc_array(BITS_TO_LONGS(indio_dev->masklength),
+- sizeof(*trialmask),
+- GFP_KERNEL);
++ trialmask = kcalloc(BITS_TO_LONGS(indio_dev->masklength),
++ sizeof(*trialmask), GFP_KERNEL);
+ if (trialmask == NULL)
+ return -ENOMEM;
+ if (!indio_dev->masklength) {
--- /dev/null
+From 40a7198a4a01037003c7ca714f0d048a61e729ac Mon Sep 17 00:00:00 2001
+From: Mike Looijmans <mike.looijmans@topic.nl>
+Date: Wed, 13 Feb 2019 08:41:47 +0100
+Subject: iio/gyro/bmg160: Use millidegrees for temperature scale
+
+From: Mike Looijmans <mike.looijmans@topic.nl>
+
+commit 40a7198a4a01037003c7ca714f0d048a61e729ac upstream.
+
+Standard unit for temperature is millidegrees Celcius, whereas this driver
+was reporting in degrees. Fix the scale factor in the driver.
+
+Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/gyro/bmg160_core.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/gyro/bmg160_core.c
++++ b/drivers/iio/gyro/bmg160_core.c
+@@ -582,11 +582,10 @@ static int bmg160_read_raw(struct iio_de
+ case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
+ return bmg160_get_filter(data, val);
+ case IIO_CHAN_INFO_SCALE:
+- *val = 0;
+ switch (chan->type) {
+ case IIO_TEMP:
+- *val2 = 500000;
+- return IIO_VAL_INT_PLUS_MICRO;
++ *val = 500;
++ return IIO_VAL_INT;
+ case IIO_ANGL_VEL:
+ {
+ int i;
+@@ -594,6 +593,7 @@ static int bmg160_read_raw(struct iio_de
+ for (i = 0; i < ARRAY_SIZE(bmg160_scale_table); ++i) {
+ if (bmg160_scale_table[i].dps_range ==
+ data->dps_range) {
++ *val = 0;
+ *val2 = bmg160_scale_table[i].scale;
+ return IIO_VAL_INT_PLUS_MICRO;
+ }
--- /dev/null
+From 409a51e0a4a5f908763191fae2c29008632eb712 Mon Sep 17 00:00:00 2001
+From: Sergey Larin <cerg2010cerg2010@mail.ru>
+Date: Sat, 2 Mar 2019 19:54:55 +0300
+Subject: iio: gyro: mpu3050: fix chip ID reading
+
+From: Sergey Larin <cerg2010cerg2010@mail.ru>
+
+commit 409a51e0a4a5f908763191fae2c29008632eb712 upstream.
+
+According to the datasheet, the last bit of CHIP_ID register controls
+I2C bus, and the first one is unused. Handle this correctly.
+
+Note that there are chips out there that have a value such that
+the id check currently fails.
+
+Signed-off-by: Sergey Larin <cerg2010cerg2010@mail.ru>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/gyro/mpu3050-core.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/gyro/mpu3050-core.c
++++ b/drivers/iio/gyro/mpu3050-core.c
+@@ -29,7 +29,8 @@
+
+ #include "mpu3050.h"
+
+-#define MPU3050_CHIP_ID 0x69
++#define MPU3050_CHIP_ID 0x68
++#define MPU3050_CHIP_ID_MASK 0x7E
+
+ /*
+ * Register map: anything suffixed *_H is a big-endian high byte and always
+@@ -1176,8 +1177,9 @@ int mpu3050_common_probe(struct device *
+ goto err_power_down;
+ }
+
+- if (val != MPU3050_CHIP_ID) {
+- dev_err(dev, "unsupported chip id %02x\n", (u8)val);
++ if ((val & MPU3050_CHIP_ID_MASK) != MPU3050_CHIP_ID) {
++ dev_err(dev, "unsupported chip id %02x\n",
++ (u8)(val & MPU3050_CHIP_ID_MASK));
+ ret = -ENODEV;
+ goto err_power_down;
+ }
--- /dev/null
+From 738c06d0e4562e0acf9f2c7438a22b2d5afc67aa Mon Sep 17 00:00:00 2001
+From: KT Liao <kt.liao@emc.com.tw>
+Date: Tue, 26 Mar 2019 17:28:32 -0700
+Subject: Input: elan_i2c - add hardware ID for multiple Lenovo laptops
+
+From: KT Liao <kt.liao@emc.com.tw>
+
+commit 738c06d0e4562e0acf9f2c7438a22b2d5afc67aa upstream.
+
+There are many Lenovo laptops which need elan_i2c support, this patch adds
+relevant IDs to the Elan driver so that touchpads are recognized.
+
+Signed-off-by: KT Liao <kt.liao@emc.com.tw>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elan_i2c_core.c | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+--- a/drivers/input/mouse/elan_i2c_core.c
++++ b/drivers/input/mouse/elan_i2c_core.c
+@@ -1339,21 +1339,46 @@ static const struct acpi_device_id elan_
+ { "ELAN0600", 0 },
+ { "ELAN0601", 0 },
+ { "ELAN0602", 0 },
++ { "ELAN0603", 0 },
++ { "ELAN0604", 0 },
+ { "ELAN0605", 0 },
++ { "ELAN0606", 0 },
++ { "ELAN0607", 0 },
+ { "ELAN0608", 0 },
+ { "ELAN0609", 0 },
+ { "ELAN060B", 0 },
+ { "ELAN060C", 0 },
++ { "ELAN060F", 0 },
++ { "ELAN0610", 0 },
+ { "ELAN0611", 0 },
+ { "ELAN0612", 0 },
++ { "ELAN0615", 0 },
++ { "ELAN0616", 0 },
+ { "ELAN0617", 0 },
+ { "ELAN0618", 0 },
++ { "ELAN0619", 0 },
++ { "ELAN061A", 0 },
++ { "ELAN061B", 0 },
+ { "ELAN061C", 0 },
+ { "ELAN061D", 0 },
+ { "ELAN061E", 0 },
++ { "ELAN061F", 0 },
+ { "ELAN0620", 0 },
+ { "ELAN0621", 0 },
+ { "ELAN0622", 0 },
++ { "ELAN0623", 0 },
++ { "ELAN0624", 0 },
++ { "ELAN0625", 0 },
++ { "ELAN0626", 0 },
++ { "ELAN0627", 0 },
++ { "ELAN0628", 0 },
++ { "ELAN0629", 0 },
++ { "ELAN062A", 0 },
++ { "ELAN062B", 0 },
++ { "ELAN062C", 0 },
++ { "ELAN062D", 0 },
++ { "ELAN0631", 0 },
++ { "ELAN0632", 0 },
+ { "ELAN1000", 0 },
+ { }
+ };
--- /dev/null
+From fe2d3df639a7940a125a33d6460529b9689c5406 Mon Sep 17 00:00:00 2001
+From: "he, bo" <bo.he@intel.com>
+Date: Wed, 6 Mar 2019 10:32:20 +0800
+Subject: io: accel: kxcjk1013: restore the range after resume.
+
+From: he, bo <bo.he@intel.com>
+
+commit fe2d3df639a7940a125a33d6460529b9689c5406 upstream.
+
+On some laptops, kxcjk1013 is powered off when system enters S3. We need
+restore the range regiter during resume. Otherwise, the sensor doesn't
+work properly after S3.
+
+Signed-off-by: he, bo <bo.he@intel.com>
+Signed-off-by: Chen, Hu <hu1.chen@intel.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/accel/kxcjk-1013.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/iio/accel/kxcjk-1013.c
++++ b/drivers/iio/accel/kxcjk-1013.c
+@@ -1437,6 +1437,8 @@ static int kxcjk1013_resume(struct devic
+
+ mutex_lock(&data->mutex);
+ ret = kxcjk1013_set_mode(data, OPERATION);
++ if (ret == 0)
++ ret = kxcjk1013_set_range(data, data->range);
+ mutex_unlock(&data->mutex);
+
+ return ret;
--- /dev/null
+From 3b9a907223d7f6b9d1dadea29436842ae9bcd76d Mon Sep 17 00:00:00 2001
+From: Corey Minyard <cminyard@mvista.com>
+Date: Wed, 3 Apr 2019 15:58:16 -0500
+Subject: ipmi: fix sleep-in-atomic in free_user at cleanup SRCU user->release_barrier
+
+From: Corey Minyard <cminyard@mvista.com>
+
+commit 3b9a907223d7f6b9d1dadea29436842ae9bcd76d upstream.
+
+free_user() could be called in atomic context.
+
+This patch pushed the free operation off into a workqueue.
+
+Example:
+
+ BUG: sleeping function called from invalid context at kernel/workqueue.c:2856
+ in_atomic(): 1, irqs_disabled(): 0, pid: 177, name: ksoftirqd/27
+ CPU: 27 PID: 177 Comm: ksoftirqd/27 Not tainted 4.19.25-3 #1
+ Hardware name: AIC 1S-HV26-08/MB-DPSB04-06, BIOS IVYBV060 10/21/2015
+ Call Trace:
+ dump_stack+0x5c/0x7b
+ ___might_sleep+0xec/0x110
+ __flush_work+0x48/0x1f0
+ ? try_to_del_timer_sync+0x4d/0x80
+ _cleanup_srcu_struct+0x104/0x140
+ free_user+0x18/0x30 [ipmi_msghandler]
+ ipmi_free_recv_msg+0x3a/0x50 [ipmi_msghandler]
+ deliver_response+0xbd/0xd0 [ipmi_msghandler]
+ deliver_local_response+0xe/0x30 [ipmi_msghandler]
+ handle_one_recv_msg+0x163/0xc80 [ipmi_msghandler]
+ ? dequeue_entity+0xa0/0x960
+ handle_new_recv_msgs+0x15c/0x1f0 [ipmi_msghandler]
+ tasklet_action_common.isra.22+0x103/0x120
+ __do_softirq+0xf8/0x2d7
+ run_ksoftirqd+0x26/0x50
+ smpboot_thread_fn+0x11d/0x1e0
+ kthread+0x103/0x140
+ ? sort_range+0x20/0x20
+ ? kthread_destroy_worker+0x40/0x40
+ ret_from_fork+0x1f/0x40
+
+Fixes: 77f8269606bf ("ipmi: fix use-after-free of user->release_barrier.rda")
+
+Reported-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+Signed-off-by: Corey Minyard <cminyard@mvista.com>
+Cc: stable@vger.kernel.org # 5.0
+Cc: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/ipmi/ipmi_msghandler.c | 19 +++++++++++++++++--
+ 1 file changed, 17 insertions(+), 2 deletions(-)
+
+--- a/drivers/char/ipmi/ipmi_msghandler.c
++++ b/drivers/char/ipmi/ipmi_msghandler.c
+@@ -213,6 +213,9 @@ struct ipmi_user {
+
+ /* Does this interface receive IPMI events? */
+ bool gets_events;
++
++ /* Free must run in process context for RCU cleanup. */
++ struct work_struct remove_work;
+ };
+
+ static struct ipmi_user *acquire_ipmi_user(struct ipmi_user *user, int *index)
+@@ -1078,6 +1081,15 @@ static int intf_err_seq(struct ipmi_smi
+ }
+
+
++static void free_user_work(struct work_struct *work)
++{
++ struct ipmi_user *user = container_of(work, struct ipmi_user,
++ remove_work);
++
++ cleanup_srcu_struct(&user->release_barrier);
++ kfree(user);
++}
++
+ int ipmi_create_user(unsigned int if_num,
+ const struct ipmi_user_hndl *handler,
+ void *handler_data,
+@@ -1121,6 +1133,8 @@ int ipmi_create_user(unsigned int
+ goto out_kfree;
+
+ found:
++ INIT_WORK(&new_user->remove_work, free_user_work);
++
+ rv = init_srcu_struct(&new_user->release_barrier);
+ if (rv)
+ goto out_kfree;
+@@ -1183,8 +1197,9 @@ EXPORT_SYMBOL(ipmi_get_smi_info);
+ static void free_user(struct kref *ref)
+ {
+ struct ipmi_user *user = container_of(ref, struct ipmi_user, refcount);
+- cleanup_srcu_struct(&user->release_barrier);
+- kfree(user);
++
++ /* SRCU cleanup must happen in task context. */
++ schedule_work(&user->remove_work);
+ }
+
+ static void _ipmi_destroy_user(struct ipmi_user *user)
--- /dev/null
+From 5f843ed415581cfad4ef8fefe31c138a8346ca8a Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@kernel.org>
+Date: Mon, 15 Apr 2019 15:01:25 +0900
+Subject: kprobes: Fix error check when reusing optimized probes
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+commit 5f843ed415581cfad4ef8fefe31c138a8346ca8a upstream.
+
+The following commit introduced a bug in one of our error paths:
+
+ 819319fc9346 ("kprobes: Return error if we fail to reuse kprobe instead of BUG_ON()")
+
+it missed to handle the return value of kprobe_optready() as
+error-value. In reality, the kprobe_optready() returns a bool
+result, so "true" case must be passed instead of 0.
+
+This causes some errors on kprobe boot-time selftests on ARM:
+
+ [ ] Beginning kprobe tests...
+ [ ] Probe ARM code
+ [ ] kprobe
+ [ ] kretprobe
+ [ ] ARM instruction simulation
+ [ ] Check decoding tables
+ [ ] Run test cases
+ [ ] FAIL: test_case_handler not run
+ [ ] FAIL: Test andge r10, r11, r14, asr r7
+ [ ] FAIL: Scenario 11
+ ...
+ [ ] FAIL: Scenario 7
+ [ ] Total instruction simulation tests=1631, pass=1433 fail=198
+ [ ] kprobe tests failed
+
+This can happen if an optimized probe is unregistered and next
+kprobe is registered on same address until the previous probe
+is not reclaimed.
+
+If this happens, a hidden aggregated probe may be kept in memory,
+and no new kprobe can probe same address. Also, in that case
+register_kprobe() will return "1" instead of minus error value,
+which can mislead caller logic.
+
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
+Cc: David S . Miller <davem@davemloft.net>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Naveen N . Rao <naveen.n.rao@linux.vnet.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org # v5.0+
+Fixes: 819319fc9346 ("kprobes: Return error if we fail to reuse kprobe instead of BUG_ON()")
+Link: http://lkml.kernel.org/r/155530808559.32517.539898325433642204.stgit@devnote2
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/kprobes.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/kernel/kprobes.c
++++ b/kernel/kprobes.c
+@@ -703,7 +703,6 @@ static void unoptimize_kprobe(struct kpr
+ static int reuse_unused_kprobe(struct kprobe *ap)
+ {
+ struct optimized_kprobe *op;
+- int ret;
+
+ BUG_ON(!kprobe_unused(ap));
+ /*
+@@ -715,9 +714,8 @@ static int reuse_unused_kprobe(struct kp
+ /* Enable the probe again */
+ ap->flags &= ~KPROBE_FLAG_DISABLED;
+ /* Optimize it again (remove from op->list) */
+- ret = kprobe_optready(ap);
+- if (ret)
+- return ret;
++ if (!kprobe_optready(ap))
++ return -EINVAL;
+
+ optimize_kprobe(ap);
+ return 0;
--- /dev/null
+From fabe38ab6b2bd9418350284c63825f13b8a6abba Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@kernel.org>
+Date: Sun, 24 Feb 2019 01:50:20 +0900
+Subject: kprobes: Mark ftrace mcount handler functions nokprobe
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+commit fabe38ab6b2bd9418350284c63825f13b8a6abba upstream.
+
+Mark ftrace mcount handler functions nokprobe since
+probing on these functions with kretprobe pushes
+return address incorrectly on kretprobe shadow stack.
+
+Reported-by: Francis Deslauriers <francis.deslauriers@efficios.com>
+Tested-by: Andrea Righi <righi.andrea@gmail.com>
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Acked-by: Steven Rostedt <rostedt@goodmis.org>
+Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/155094062044.6137.6419622920568680640.stgit@devbox
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/ftrace.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -34,6 +34,7 @@
+ #include <linux/list.h>
+ #include <linux/hash.h>
+ #include <linux/rcupdate.h>
++#include <linux/kprobes.h>
+
+ #include <trace/events/sched.h>
+
+@@ -6250,7 +6251,7 @@ void ftrace_reset_array_ops(struct trace
+ tr->ops->func = ftrace_stub;
+ }
+
+-static inline void
++static nokprobe_inline void
+ __ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
+ struct ftrace_ops *ignored, struct pt_regs *regs)
+ {
+@@ -6310,11 +6311,13 @@ static void ftrace_ops_list_func(unsigne
+ {
+ __ftrace_ops_list_func(ip, parent_ip, NULL, regs);
+ }
++NOKPROBE_SYMBOL(ftrace_ops_list_func);
+ #else
+ static void ftrace_ops_no_ops(unsigned long ip, unsigned long parent_ip)
+ {
+ __ftrace_ops_list_func(ip, parent_ip, NULL, NULL);
+ }
++NOKPROBE_SYMBOL(ftrace_ops_no_ops);
+ #endif
+
+ /*
+@@ -6341,6 +6344,7 @@ static void ftrace_ops_assist_func(unsig
+ preempt_enable_notrace();
+ trace_clear_recursion(bit);
+ }
++NOKPROBE_SYMBOL(ftrace_ops_assist_func);
+
+ /**
+ * ftrace_ops_get_func - get the function a trampoline should call
--- /dev/null
+From 8f4dc2e77cdfaf7e644ef29693fa229db29ee1de Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Tue, 2 Apr 2019 08:10:47 -0700
+Subject: KVM: x86: Don't clear EFER during SMM transitions for 32-bit vCPU
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+commit 8f4dc2e77cdfaf7e644ef29693fa229db29ee1de upstream.
+
+Neither AMD nor Intel CPUs have an EFER field in the legacy SMRAM save
+state area, i.e. don't save/restore EFER across SMM transitions. KVM
+somewhat models this, e.g. doesn't clear EFER on entry to SMM if the
+guest doesn't support long mode. But during RSM, KVM unconditionally
+clears EFER so that it can get back to pure 32-bit mode in order to
+start loading CRs with their actual non-SMM values.
+
+Clear EFER only when it will be written when loading the non-SMM state
+so as to preserve bits that can theoretically be set on 32-bit vCPUs,
+e.g. KVM always emulates EFER_SCE.
+
+And because CR4.PAE is cleared only to play nice with EFER, wrap that
+code in the long mode check as well. Note, this may result in a
+compiler warning about cr4 being consumed uninitialized. Re-read CR4
+even though it's technically unnecessary, as doing so allows for more
+readable code and RSM emulation is not a performance critical path.
+
+Fixes: 660a5d517aaab ("KVM: x86: save/load state on SMM switch")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/emulate.c | 23 ++++++++++++-----------
+ 1 file changed, 12 insertions(+), 11 deletions(-)
+
+--- a/arch/x86/kvm/emulate.c
++++ b/arch/x86/kvm/emulate.c
+@@ -2575,15 +2575,13 @@ static int em_rsm(struct x86_emulate_ctx
+ * CR0/CR3/CR4/EFER. It's all a bit more complicated if the vCPU
+ * supports long mode.
+ */
+- cr4 = ctxt->ops->get_cr(ctxt, 4);
+ if (emulator_has_longmode(ctxt)) {
+ struct desc_struct cs_desc;
+
+ /* Zero CR4.PCIDE before CR0.PG. */
+- if (cr4 & X86_CR4_PCIDE) {
++ cr4 = ctxt->ops->get_cr(ctxt, 4);
++ if (cr4 & X86_CR4_PCIDE)
+ ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PCIDE);
+- cr4 &= ~X86_CR4_PCIDE;
+- }
+
+ /* A 32-bit code segment is required to clear EFER.LMA. */
+ memset(&cs_desc, 0, sizeof(cs_desc));
+@@ -2597,13 +2595,16 @@ static int em_rsm(struct x86_emulate_ctx
+ if (cr0 & X86_CR0_PE)
+ ctxt->ops->set_cr(ctxt, 0, cr0 & ~(X86_CR0_PG | X86_CR0_PE));
+
+- /* Now clear CR4.PAE (which must be done before clearing EFER.LME). */
+- if (cr4 & X86_CR4_PAE)
+- ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PAE);
+-
+- /* And finally go back to 32-bit mode. */
+- efer = 0;
+- ctxt->ops->set_msr(ctxt, MSR_EFER, efer);
++ if (emulator_has_longmode(ctxt)) {
++ /* Clear CR4.PAE before clearing EFER.LME. */
++ cr4 = ctxt->ops->get_cr(ctxt, 4);
++ if (cr4 & X86_CR4_PAE)
++ ctxt->ops->set_cr(ctxt, 4, cr4 & ~X86_CR4_PAE);
++
++ /* And finally go back to 32-bit mode. */
++ efer = 0;
++ ctxt->ops->set_msr(ctxt, MSR_EFER, efer);
++ }
+
+ smbase = ctxt->ops->get_smbase(ctxt);
+
--- /dev/null
+From 99c221796a810055974b54c02e8f53297e48d146 Mon Sep 17 00:00:00 2001
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+Date: Wed, 3 Apr 2019 16:06:42 +0200
+Subject: KVM: x86: svm: make sure NMI is injected after nmi_singlestep
+
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+
+commit 99c221796a810055974b54c02e8f53297e48d146 upstream.
+
+I noticed that apic test from kvm-unit-tests always hangs on my EPYC 7401P,
+the hanging test nmi-after-sti is trying to deliver 30000 NMIs and tracing
+shows that we're sometimes able to deliver a few but never all.
+
+When we're trying to inject an NMI we may fail to do so immediately for
+various reasons, however, we still need to inject it so enable_nmi_window()
+arms nmi_singlestep mode. #DB occurs as expected, but we're not checking
+for pending NMIs before entering the guest and unless there's a different
+event to process, the NMI will never get delivered.
+
+Make KVM_REQ_EVENT request on the vCPU from db_interception() to make sure
+pending NMIs are checked and possibly injected.
+
+Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/svm.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/x86/kvm/svm.c
++++ b/arch/x86/kvm/svm.c
+@@ -2679,6 +2679,7 @@ static int npf_interception(struct vcpu_
+ static int db_interception(struct vcpu_svm *svm)
+ {
+ struct kvm_run *kvm_run = svm->vcpu.run;
++ struct kvm_vcpu *vcpu = &svm->vcpu;
+
+ if (!(svm->vcpu.guest_debug &
+ (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP)) &&
+@@ -2689,6 +2690,8 @@ static int db_interception(struct vcpu_s
+
+ if (svm->nmi_singlestep) {
+ disable_nmi_singlestep(svm);
++ /* Make sure we check for pending NMIs upon entry */
++ kvm_make_request(KVM_REQ_EVENT, vcpu);
+ }
+
+ if (svm->vcpu.guest_debug &
--- /dev/null
+From 4856bfd230985e43e84c26473c91028ff0a533bd Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@nbd.name>
+Date: Fri, 1 Mar 2019 14:48:37 +0100
+Subject: mac80211: do not call driver wake_tx_queue op during reconfig
+
+From: Felix Fietkau <nbd@nbd.name>
+
+commit 4856bfd230985e43e84c26473c91028ff0a533bd upstream.
+
+There are several scenarios in which mac80211 can call drv_wake_tx_queue
+after ieee80211_restart_hw has been called and has not yet completed.
+Driver private structs are considered uninitialized until mac80211 has
+uploaded the vifs, stations and keys again, so using private tx queue
+data during that time is not safe.
+
+The driver can also not rely on drv_reconfig_complete to figure out when
+it is safe to accept drv_wake_tx_queue calls again, because it is only
+called after all tx queues are woken again.
+
+To fix this, bail out early in drv_wake_tx_queue if local->in_reconfig
+is set.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/driver-ops.h | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/mac80211/driver-ops.h
++++ b/net/mac80211/driver-ops.h
+@@ -1166,6 +1166,9 @@ static inline void drv_wake_tx_queue(str
+ {
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(txq->txq.vif);
+
++ if (local->in_reconfig)
++ return;
++
+ if (!check_sdata_in_driver(sdata))
+ return;
+
--- /dev/null
+From 3fe3331bb285700ab2253dbb07f8e478fcea2f1b Mon Sep 17 00:00:00 2001
+From: Kim Phillips <kim.phillips@amd.com>
+Date: Thu, 21 Mar 2019 21:15:22 +0000
+Subject: perf/x86/amd: Add event map for AMD Family 17h
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Kim Phillips <kim.phillips@amd.com>
+
+commit 3fe3331bb285700ab2253dbb07f8e478fcea2f1b upstream.
+
+Family 17h differs from prior families by:
+
+ - Does not support an L2 cache miss event
+ - It has re-enumerated PMC counters for:
+ - L2 cache references
+ - front & back end stalled cycles
+
+So we add a new amd_f17h_perfmon_event_map[] so that the generic
+perf event names will resolve to the correct h/w events on
+family 17h and above processors.
+
+Reference sections 2.1.13.3.3 (stalls) and 2.1.13.3.6 (L2):
+
+ https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
+
+Signed-off-by: Kim Phillips <kim.phillips@amd.com>
+Cc: <stable@vger.kernel.org> # v4.9+
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Martin Liška <mliska@suse.cz>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Pu Wen <puwen@hygon.cn>
+Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: linux-kernel@vger.kernel.org
+Fixes: e40ed1542dd7 ("perf/x86: Add perf support for AMD family-17h processors")
+[ Improved the formatting a bit. ]
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/events/amd/core.c | 35 ++++++++++++++++++++++++++---------
+ 1 file changed, 26 insertions(+), 9 deletions(-)
+
+--- a/arch/x86/events/amd/core.c
++++ b/arch/x86/events/amd/core.c
+@@ -117,22 +117,39 @@ static __initconst const u64 amd_hw_cach
+ };
+
+ /*
+- * AMD Performance Monitor K7 and later.
++ * AMD Performance Monitor K7 and later, up to and including Family 16h:
+ */
+ static const u64 amd_perfmon_event_map[PERF_COUNT_HW_MAX] =
+ {
+- [PERF_COUNT_HW_CPU_CYCLES] = 0x0076,
+- [PERF_COUNT_HW_INSTRUCTIONS] = 0x00c0,
+- [PERF_COUNT_HW_CACHE_REFERENCES] = 0x077d,
+- [PERF_COUNT_HW_CACHE_MISSES] = 0x077e,
+- [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x00c2,
+- [PERF_COUNT_HW_BRANCH_MISSES] = 0x00c3,
+- [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x00d0, /* "Decoder empty" event */
+- [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x00d1, /* "Dispatch stalls" event */
++ [PERF_COUNT_HW_CPU_CYCLES] = 0x0076,
++ [PERF_COUNT_HW_INSTRUCTIONS] = 0x00c0,
++ [PERF_COUNT_HW_CACHE_REFERENCES] = 0x077d,
++ [PERF_COUNT_HW_CACHE_MISSES] = 0x077e,
++ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x00c2,
++ [PERF_COUNT_HW_BRANCH_MISSES] = 0x00c3,
++ [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x00d0, /* "Decoder empty" event */
++ [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x00d1, /* "Dispatch stalls" event */
++};
++
++/*
++ * AMD Performance Monitor Family 17h and later:
++ */
++static const u64 amd_f17h_perfmon_event_map[PERF_COUNT_HW_MAX] =
++{
++ [PERF_COUNT_HW_CPU_CYCLES] = 0x0076,
++ [PERF_COUNT_HW_INSTRUCTIONS] = 0x00c0,
++ [PERF_COUNT_HW_CACHE_REFERENCES] = 0xff60,
++ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x00c2,
++ [PERF_COUNT_HW_BRANCH_MISSES] = 0x00c3,
++ [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x0287,
++ [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x0187,
+ };
+
+ static u64 amd_pmu_event_map(int hw_event)
+ {
++ if (boot_cpu_data.x86 >= 0x17)
++ return amd_f17h_perfmon_event_map[hw_event];
++
+ return amd_perfmon_event_map[hw_event];
+ }
+
--- /dev/null
+From 9d5dcc93a6ddfc78124f006ccd3637ce070ef2fc Mon Sep 17 00:00:00 2001
+From: Kan Liang <kan.liang@linux.intel.com>
+Date: Tue, 2 Apr 2019 12:44:58 -0700
+Subject: perf/x86: Fix incorrect PEBS_REGS
+
+From: Kan Liang <kan.liang@linux.intel.com>
+
+commit 9d5dcc93a6ddfc78124f006ccd3637ce070ef2fc upstream.
+
+PEBS_REGS used as mask for the supported registers for large PEBS.
+However, the mask cannot filter the sample_regs_user/sample_regs_intr
+correctly.
+
+(1ULL << PERF_REG_X86_*) should be used to replace PERF_REG_X86_*, which
+is only the index.
+
+Rename PEBS_REGS to PEBS_GP_REGS, because the mask is only for general
+purpose registers.
+
+Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: <stable@vger.kernel.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: jolsa@kernel.org
+Fixes: 2fe1bc1f501d ("perf/x86: Enable free running PEBS for REGS_USER/INTR")
+Link: https://lkml.kernel.org/r/20190402194509.2832-2-kan.liang@linux.intel.com
+[ Renamed it to PEBS_GP_REGS - as 'GPRS' is used elsewhere ;-) ]
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/events/intel/core.c | 2 +-
+ arch/x86/events/perf_event.h | 38 +++++++++++++++++++-------------------
+ 2 files changed, 20 insertions(+), 20 deletions(-)
+
+--- a/arch/x86/events/intel/core.c
++++ b/arch/x86/events/intel/core.c
+@@ -3014,7 +3014,7 @@ static unsigned long intel_pmu_large_peb
+ flags &= ~PERF_SAMPLE_TIME;
+ if (!event->attr.exclude_kernel)
+ flags &= ~PERF_SAMPLE_REGS_USER;
+- if (event->attr.sample_regs_user & ~PEBS_REGS)
++ if (event->attr.sample_regs_user & ~PEBS_GP_REGS)
+ flags &= ~(PERF_SAMPLE_REGS_USER | PERF_SAMPLE_REGS_INTR);
+ return flags;
+ }
+--- a/arch/x86/events/perf_event.h
++++ b/arch/x86/events/perf_event.h
+@@ -96,25 +96,25 @@ struct amd_nb {
+ PERF_SAMPLE_REGS_INTR | PERF_SAMPLE_REGS_USER | \
+ PERF_SAMPLE_PERIOD)
+
+-#define PEBS_REGS \
+- (PERF_REG_X86_AX | \
+- PERF_REG_X86_BX | \
+- PERF_REG_X86_CX | \
+- PERF_REG_X86_DX | \
+- PERF_REG_X86_DI | \
+- PERF_REG_X86_SI | \
+- PERF_REG_X86_SP | \
+- PERF_REG_X86_BP | \
+- PERF_REG_X86_IP | \
+- PERF_REG_X86_FLAGS | \
+- PERF_REG_X86_R8 | \
+- PERF_REG_X86_R9 | \
+- PERF_REG_X86_R10 | \
+- PERF_REG_X86_R11 | \
+- PERF_REG_X86_R12 | \
+- PERF_REG_X86_R13 | \
+- PERF_REG_X86_R14 | \
+- PERF_REG_X86_R15)
++#define PEBS_GP_REGS \
++ ((1ULL << PERF_REG_X86_AX) | \
++ (1ULL << PERF_REG_X86_BX) | \
++ (1ULL << PERF_REG_X86_CX) | \
++ (1ULL << PERF_REG_X86_DX) | \
++ (1ULL << PERF_REG_X86_DI) | \
++ (1ULL << PERF_REG_X86_SI) | \
++ (1ULL << PERF_REG_X86_SP) | \
++ (1ULL << PERF_REG_X86_BP) | \
++ (1ULL << PERF_REG_X86_IP) | \
++ (1ULL << PERF_REG_X86_FLAGS) | \
++ (1ULL << PERF_REG_X86_R8) | \
++ (1ULL << PERF_REG_X86_R9) | \
++ (1ULL << PERF_REG_X86_R10) | \
++ (1ULL << PERF_REG_X86_R11) | \
++ (1ULL << PERF_REG_X86_R12) | \
++ (1ULL << PERF_REG_X86_R13) | \
++ (1ULL << PERF_REG_X86_R14) | \
++ (1ULL << PERF_REG_X86_R15))
+
+ /*
+ * Per register state.
--- /dev/null
+From 0228034d8e5915b98c33db35a98f5e909e848ae9 Mon Sep 17 00:00:00 2001
+From: Saurav Kashyap <skashyap@marvell.com>
+Date: Thu, 18 Apr 2019 03:40:12 -0700
+Subject: Revert "scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO"
+
+From: Saurav Kashyap <skashyap@marvell.com>
+
+commit 0228034d8e5915b98c33db35a98f5e909e848ae9 upstream.
+
+This patch clears FC_RP_STARTED flag during logoff, because of this
+re-login(flogi) didn't happen to the switch.
+
+This reverts commit 1550ec458e0cf1a40a170ab1f4c46e3f52860f65.
+
+Fixes: 1550ec458e0c ("scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO")
+Cc: <stable@vger.kernel.org> # v4.18+
+Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
+Reviewed-by: Hannes Reinecke <hare@#suse.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/libfc/fc_rport.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/scsi/libfc/fc_rport.c
++++ b/drivers/scsi/libfc/fc_rport.c
+@@ -2153,7 +2153,6 @@ static void fc_rport_recv_logo_req(struc
+ FC_RPORT_DBG(rdata, "Received LOGO request while in state %s\n",
+ fc_rport_state(rdata));
+
+- rdata->flags &= ~FC_RP_STARTED;
+ fc_rport_enter_delete(rdata, RPORT_EV_STOP);
+ mutex_unlock(&rdata->rp_mutex);
+ kref_put(&rdata->kref, fc_rport_destroy);
--- /dev/null
+From 4a58038b9e420276157785afa0a0bbb4b9bc2265 Mon Sep 17 00:00:00 2001
+From: "Suthikulpanit, Suravee" <Suravee.Suthikulpanit@amd.com>
+Date: Wed, 20 Mar 2019 08:12:28 +0000
+Subject: Revert "svm: Fix AVIC incomplete IPI emulation"
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Suthikulpanit, Suravee <Suravee.Suthikulpanit@amd.com>
+
+commit 4a58038b9e420276157785afa0a0bbb4b9bc2265 upstream.
+
+This reverts commit bb218fbcfaaa3b115d4cd7a43c0ca164f3a96e57.
+
+As Oren Twaig pointed out the old discussion:
+
+ https://patchwork.kernel.org/patch/8292231/
+
+that the change coud potentially cause an extra IPI to be sent to
+the destination vcpu because the AVIC hardware already set the IRR bit
+before the incomplete IPI #VMEXIT with id=1 (target vcpu is not running).
+Since writting to ICR and ICR2 will also set the IRR. If something triggers
+the destination vcpu to get scheduled before the emulation finishes, then
+this could result in an additional IPI.
+
+Also, the issue mentioned in the commit bb218fbcfaaa was misdiagnosed.
+
+Cc: Radim Krčmář <rkrcmar@redhat.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Reported-by: Oren Twaig <oren@scalemp.com>
+Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/svm.c | 19 +++++++++++++++----
+ 1 file changed, 15 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/kvm/svm.c
++++ b/arch/x86/kvm/svm.c
+@@ -4496,14 +4496,25 @@ static int avic_incomplete_ipi_intercept
+ kvm_lapic_reg_write(apic, APIC_ICR, icrl);
+ break;
+ case AVIC_IPI_FAILURE_TARGET_NOT_RUNNING: {
++ int i;
++ struct kvm_vcpu *vcpu;
++ struct kvm *kvm = svm->vcpu.kvm;
+ struct kvm_lapic *apic = svm->vcpu.arch.apic;
+
+ /*
+- * Update ICR high and low, then emulate sending IPI,
+- * which is handled when writing APIC_ICR.
++ * At this point, we expect that the AVIC HW has already
++ * set the appropriate IRR bits on the valid target
++ * vcpus. So, we just need to kick the appropriate vcpu.
+ */
+- kvm_lapic_reg_write(apic, APIC_ICR2, icrh);
+- kvm_lapic_reg_write(apic, APIC_ICR, icrl);
++ kvm_for_each_vcpu(i, vcpu, kvm) {
++ bool m = kvm_apic_match_dest(vcpu, apic,
++ icrl & KVM_APIC_SHORT_MASK,
++ GET_APIC_DEST_FIELD(icrh),
++ icrl & KVM_APIC_DEST_MASK);
++
++ if (m && !avic_vcpu_is_running(vcpu))
++ kvm_vcpu_wake_up(vcpu);
++ }
+ break;
+ }
+ case AVIC_IPI_FAILURE_INVALID_TARGET:
--- /dev/null
+From 746ba11f170603bf1eaade817553a6c2e9135bbe Mon Sep 17 00:00:00 2001
+From: Vijayakumar Durai <vijayakumar.durai1@vivint.com>
+Date: Wed, 27 Mar 2019 11:03:17 +0100
+Subject: rt2x00: do not increment sequence number while re-transmitting
+
+From: Vijayakumar Durai <vijayakumar.durai1@vivint.com>
+
+commit 746ba11f170603bf1eaade817553a6c2e9135bbe upstream.
+
+Currently rt2x00 devices retransmit the management frames with
+incremented sequence number if hardware is assigning the sequence.
+
+This is HW bug fixed already for non-QOS data frames, but it should
+be fixed for management frames except beacon.
+
+Without fix retransmitted frames have wrong SN:
+
+ AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1648, FN=0, Flags=........C Frame is not being retransmitted 1648 1
+ AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1649, FN=0, Flags=....R...C Frame is being retransmitted 1649 1
+ AlphaNet_e8:fb:36 Vivotek_52:31:51 Authentication, SN=1650, FN=0, Flags=....R...C Frame is being retransmitted 1650 1
+
+With the fix SN stays correctly the same:
+
+ 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=........C
+ 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C
+ 88:6a:e3:e8:f9:a2 8c:f5:a3:88:76:87 Authentication, SN=1450, FN=0, Flags=....R...C
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Vijayakumar Durai <vijayakumar.durai1@vivint.com>
+[sgruszka: simplify code, change comments and changelog]
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/ralink/rt2x00/rt2x00.h | 1 -
+ drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 10 ----------
+ drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 15 +++++++++------
+ 3 files changed, 9 insertions(+), 17 deletions(-)
+
+--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
++++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+@@ -672,7 +672,6 @@ enum rt2x00_state_flags {
+ CONFIG_CHANNEL_HT40,
+ CONFIG_POWERSAVING,
+ CONFIG_HT_DISABLED,
+- CONFIG_QOS_DISABLED,
+ CONFIG_MONITORING,
+
+ /*
+--- a/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
++++ b/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
+@@ -642,19 +642,9 @@ void rt2x00mac_bss_info_changed(struct i
+ rt2x00dev->intf_associated--;
+
+ rt2x00leds_led_assoc(rt2x00dev, !!rt2x00dev->intf_associated);
+-
+- clear_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags);
+ }
+
+ /*
+- * Check for access point which do not support 802.11e . We have to
+- * generate data frames sequence number in S/W for such AP, because
+- * of H/W bug.
+- */
+- if (changes & BSS_CHANGED_QOS && !bss_conf->qos)
+- set_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags);
+-
+- /*
+ * When the erp information has changed, we should perform
+ * additional configuration steps. For all other changes we are done.
+ */
+--- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
++++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
+@@ -200,15 +200,18 @@ static void rt2x00queue_create_tx_descri
+ if (!rt2x00_has_cap_flag(rt2x00dev, REQUIRE_SW_SEQNO)) {
+ /*
+ * rt2800 has a H/W (or F/W) bug, device incorrectly increase
+- * seqno on retransmited data (non-QOS) frames. To workaround
+- * the problem let's generate seqno in software if QOS is
+- * disabled.
++ * seqno on retransmitted data (non-QOS) and management frames.
++ * To workaround the problem let's generate seqno in software.
++ * Except for beacons which are transmitted periodically by H/W
++ * hence hardware has to assign seqno for them.
+ */
+- if (test_bit(CONFIG_QOS_DISABLED, &rt2x00dev->flags))
+- __clear_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags);
+- else
++ if (ieee80211_is_beacon(hdr->frame_control)) {
++ __set_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags);
+ /* H/W will generate sequence number */
+ return;
++ }
++
++ __clear_bit(ENTRY_TXD_GENERATE_SEQ, &txdesc->flags);
+ }
+
+ /*
--- /dev/null
+From be549d49115422f846b6d96ee8fd7173a5f7ceb0 Mon Sep 17 00:00:00 2001
+From: Jaesoo Lee <jalee@purestorage.com>
+Date: Tue, 9 Apr 2019 17:02:22 -0700
+Subject: scsi: core: set result when the command cannot be dispatched
+
+From: Jaesoo Lee <jalee@purestorage.com>
+
+commit be549d49115422f846b6d96ee8fd7173a5f7ceb0 upstream.
+
+When SCSI blk-mq is enabled, there is a bug in handling errors in
+scsi_queue_rq. Specifically, the bug is not setting result field of
+scsi_request correctly when the dispatch of the command has been
+failed. Since the upper layer code including the sg_io ioctl expects to
+receive any error status from result field of scsi_request, the error is
+silently ignored and this could cause data corruptions for some
+applications.
+
+Fixes: d285203cf647 ("scsi: add support for a blk-mq based I/O path.")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jaesoo Lee <jalee@purestorage.com>
+Reviewed-by: Hannes Reinecke <hare@suse.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/scsi_lib.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/scsi_lib.c
++++ b/drivers/scsi/scsi_lib.c
+@@ -2149,8 +2149,12 @@ out_put_budget:
+ ret = BLK_STS_DEV_RESOURCE;
+ break;
+ default:
++ if (unlikely(!scsi_device_online(sdev)))
++ scsi_req(req)->result = DID_NO_CONNECT << 16;
++ else
++ scsi_req(req)->result = DID_ERROR << 16;
+ /*
+- * Make sure to release all allocated ressources when
++ * Make sure to release all allocated resources when
+ * we hit an error, as we will never see this command
+ * again.
+ */
--- /dev/null
+From 6b87784b53592a90d21576be8eff688b56d93cce Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Fri, 29 Mar 2019 10:10:26 +0100
+Subject: serial: sh-sci: Fix HSCIF RX sampling point adjustment
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit 6b87784b53592a90d21576be8eff688b56d93cce upstream.
+
+The calculation of the sampling point has min() and max() exchanged.
+Fix this by using the clamp() helper instead.
+
+Fixes: 63ba1e00f178a448 ("serial: sh-sci: Support for HSCIF RX sampling point adjustment")
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
+Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
+Cc: stable <stable@vger.kernel.org>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/sh-sci.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/sh-sci.c
++++ b/drivers/tty/serial/sh-sci.c
+@@ -2504,7 +2504,7 @@ done:
+ * last stop bit; we can increase the error
+ * margin by shifting the sampling point.
+ */
+- int shift = min(-8, max(7, deviation / 2));
++ int shift = clamp(deviation / 2, -8, 7);
+
+ hssrr |= (shift << HSCIF_SRHP_SHIFT) &
+ HSCIF_SRHP_MASK;
--- /dev/null
+From ace965696da2611af759f0284e26342b7b6cec89 Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Mon, 1 Apr 2019 13:25:10 +0200
+Subject: serial: sh-sci: Fix HSCIF RX sampling point calculation
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit ace965696da2611af759f0284e26342b7b6cec89 upstream.
+
+There are several issues with the formula used for calculating the
+deviation from the intended rate:
+ 1. While min_err and last_stop are signed, srr and baud are unsigned.
+ Hence the signed values are promoted to unsigned, which will lead
+ to a bogus value of deviation if min_err is negative,
+ 2. Srr is the register field value, which is one less than the actual
+ sampling rate factor,
+ 3. The divisions do not use rounding.
+
+Fix this by casting unsigned variables to int, adding one to srr, and
+using a single DIV_ROUND_CLOSEST().
+
+Fixes: 63ba1e00f178a448 ("serial: sh-sci: Support for HSCIF RX sampling point adjustment")
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
+Cc: stable <stable@vger.kernel.org>
+Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/sh-sci.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/sh-sci.c
++++ b/drivers/tty/serial/sh-sci.c
+@@ -2497,7 +2497,9 @@ done:
+ * center of the last stop bit in sampling clocks.
+ */
+ int last_stop = bits * 2 - 1;
+- int deviation = min_err * srr * last_stop / 2 / baud;
++ int deviation = DIV_ROUND_CLOSEST(min_err * last_stop *
++ (int)(srr + 1),
++ 2 * (int)baud);
+
+ if (abs(deviation) >= 2) {
+ /* At least two sampling clocks off at the
net-ip-defrag-encapsulate-rbtree-defrag-code-into-ca.patch
net-ip6-defrag-use-rbtrees-for-ipv6-defrag.patch
net-ip6-defrag-use-rbtrees-in-nf_conntrack_reasm.c.patch
+cifs-keep-fileinfo-handle-live-during-oplock-break.patch
+cifs-fix-use-after-free-in-smb2_write.patch
+cifs-fix-use-after-free-in-smb2_read.patch
+cifs-fix-handle-leak-in-smb2_query_symlink.patch
+kvm-x86-don-t-clear-efer-during-smm-transitions-for-32-bit-vcpu.patch
+kvm-x86-svm-make-sure-nmi-is-injected-after-nmi_singlestep.patch
+staging-iio-meter-fixed-typo.patch
+staging-iio-ad7192-fix-ad7193-channel-address.patch
+iio-gyro-mpu3050-fix-chip-id-reading.patch
+iio-gyro-bmg160-use-millidegrees-for-temperature-scale.patch
+iio-chemical-bme680-fix-report-temperature-in-millidegrees.patch
+iio-chemical-bme680-fix-spi-read-interface.patch
+iio-cros_ec-fix-the-maths-for-gyro-scale-calculation.patch
+iio-ad_sigma_delta-select-channel-when-reading-register.patch
+iio-dac-mcp4725-add-missing-powerdown-bits-in-store-eeprom.patch
+iio-fix-scan-mask-selection.patch
+iio-adc-at91-disable-adc-channel-interrupt-in-timeout-case.patch
+iio-core-fix-a-possible-circular-locking-dependency.patch
+io-accel-kxcjk1013-restore-the-range-after-resume.patch
+staging-most-core-use-device-description-as-name.patch
+staging-comedi-vmk80xx-fix-use-of-uninitialized-semaphore.patch
+staging-comedi-vmk80xx-fix-possible-double-free-of-usb_rx_buf.patch
+staging-comedi-ni_usb6501-fix-use-of-uninitialized-mutex.patch
+staging-comedi-ni_usb6501-fix-possible-double-free-of-usb_rx_buf.patch
+alsa-hda-realtek-add-two-more-pin-configuration-sets-to-quirk-table.patch
+alsa-core-fix-card-races-between-register-and-disconnect.patch
+input-elan_i2c-add-hardware-id-for-multiple-lenovo-laptops.patch
+serial-sh-sci-fix-hscif-rx-sampling-point-adjustment.patch
+serial-sh-sci-fix-hscif-rx-sampling-point-calculation.patch
+vt-fix-cursor-when-clearing-the-screen.patch
+scsi-core-set-result-when-the-command-cannot-be-dispatched.patch
+revert-scsi-fcoe-clear-fc_rp_started-flags-when-receiving-a-logo.patch
+revert-svm-fix-avic-incomplete-ipi-emulation.patch
+coredump-fix-race-condition-between-mmget_not_zero-get_task_mm-and-core-dumping.patch
+ipmi-fix-sleep-in-atomic-in-free_user-at-cleanup-srcu-user-release_barrier.patch
+crypto-x86-poly1305-fix-overflow-during-partial-reduction.patch
+drm-ttm-fix-out-of-bounds-read-in-ttm_put_pages-v2.patch
+arm64-futex-restore-oldval-initialization-to-work-around-buggy-compilers.patch
+x86-kprobes-verify-stack-frame-on-kretprobe.patch
+kprobes-mark-ftrace-mcount-handler-functions-nokprobe.patch
+kprobes-fix-error-check-when-reusing-optimized-probes.patch
+rt2x00-do-not-increment-sequence-number-while-re-transmitting.patch
+mac80211-do-not-call-driver-wake_tx_queue-op-during-reconfig.patch
+drm-amdgpu-gmc9-fix-vm_l2_cntl3-programming.patch
+perf-x86-amd-add-event-map-for-amd-family-17h.patch
+x86-cpu-bugs-use-__initconst-for-const-init-data.patch
+perf-x86-fix-incorrect-pebs_regs.patch
+x86-speculation-prevent-deadlock-on-ssb_state-lock.patch
+timers-sched_clock-prevent-generic-sched_clock-wrap-caused-by-tick_freeze.patch
nfit-ars-remove-ars_start_flags.patch
nfit-ars-introduce-scrub_flags.patch
nfit-ars-allow-root-to-busy-poll-the-ars-state-machi.patch
--- /dev/null
+From af4b54a2e5ba18259ff9aac445bf546dd60d037e Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Mon, 15 Apr 2019 12:43:02 +0100
+Subject: staging: comedi: ni_usb6501: Fix possible double-free of ->usb_rx_buf
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit af4b54a2e5ba18259ff9aac445bf546dd60d037e upstream.
+
+`ni6501_alloc_usb_buffers()` is called from `ni6501_auto_attach()` to
+allocate RX and TX buffers for USB transfers. It allocates
+`devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`. If the
+allocation of `devpriv->usb_tx_buf` fails, it frees
+`devpriv->usb_rx_buf`, leaving the pointer set dangling, and returns an
+error. Later, `ni6501_detach()` will be called from the core comedi
+module code to clean up. `ni6501_detach()` also frees both
+`devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
+`devpriv->usb_rx_buf` may have already beed freed, leading to a
+double-free error. Fix it bu removing the call to
+`kfree(devpriv->usb_rx_buf)` from `ni6501_alloc_usb_buffers()`, relying
+on `ni6501_detach()` to free the memory.
+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/ni_usb6501.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/ni_usb6501.c
++++ b/drivers/staging/comedi/drivers/ni_usb6501.c
+@@ -463,10 +463,8 @@ static int ni6501_alloc_usb_buffers(stru
+
+ size = usb_endpoint_maxp(devpriv->ep_tx);
+ devpriv->usb_tx_buf = kzalloc(size, GFP_KERNEL);
+- if (!devpriv->usb_tx_buf) {
+- kfree(devpriv->usb_rx_buf);
++ if (!devpriv->usb_tx_buf)
+ return -ENOMEM;
+- }
+
+ return 0;
+ }
--- /dev/null
+From 660cf4ce9d0f3497cc7456eaa6d74c8b71d6282c Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Mon, 15 Apr 2019 12:43:01 +0100
+Subject: staging: comedi: ni_usb6501: Fix use of uninitialized mutex
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 660cf4ce9d0f3497cc7456eaa6d74c8b71d6282c upstream.
+
+If `ni6501_auto_attach()` returns an error, the core comedi module code
+will call `ni6501_detach()` to clean up. If `ni6501_auto_attach()`
+successfully allocated the comedi device private data, `ni6501_detach()`
+assumes that a `struct mutex mut` contained in the private data has been
+initialized and uses it. Unfortunately, there are a couple of places
+where `ni6501_auto_attach()` can return an error after allocating the
+device private data but before initializing the mutex, so this
+assumption is invalid. Fix it by initializing the mutex just after
+allocating the private data in `ni6501_auto_attach()` before any other
+errors can be retturned. Also move the call to `usb_set_intfdata()`
+just to keep the code a bit neater (either position for the call is
+fine).
+
+I believe this was the cause of the following syzbot crash report
+<https://syzkaller.appspot.com/bug?extid=cf4f2b6c24aff0a3edf6>:
+
+usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
+usb 1-1: config 0 descriptor??
+usb 1-1: string descriptor 0 read error: -71
+comedi comedi0: Wrong number of endpoints
+ni6501 1-1:0.233: driver 'ni6501' failed to auto-configure device.
+INFO: trying to register non-static key.
+the code is fine but needs lockdep annotation.
+turning off the locking correctness validator.
+CPU: 0 PID: 585 Comm: kworker/0:3 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+Workqueue: usb_hub_wq hub_event
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0xe8/0x16e lib/dump_stack.c:113
+ assign_lock_key kernel/locking/lockdep.c:786 [inline]
+ register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
+ __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
+ lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
+ __mutex_lock_common kernel/locking/mutex.c:925 [inline]
+ __mutex_lock+0xfe/0x12b0 kernel/locking/mutex.c:1072
+ ni6501_detach+0x5b/0x110 drivers/staging/comedi/drivers/ni_usb6501.c:567
+ comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
+ comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
+ comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
+ comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
+ comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
+ comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
+ comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
+ usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
+ really_probe+0x2da/0xb10 drivers/base/dd.c:509
+ driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
+ __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
+ bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
+ __device_attach+0x223/0x3a0 drivers/base/dd.c:844
+ bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
+ device_add+0xad2/0x16e0 drivers/base/core.c:2106
+ usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
+ generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
+ usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
+ really_probe+0x2da/0xb10 drivers/base/dd.c:509
+ driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
+ __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
+ bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
+ __device_attach+0x223/0x3a0 drivers/base/dd.c:844
+ bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
+ device_add+0xad2/0x16e0 drivers/base/core.c:2106
+ usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
+ hub_port_connect drivers/usb/core/hub.c:5089 [inline]
+ hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
+ port_event drivers/usb/core/hub.c:5350 [inline]
+ hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
+ process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
+ worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
+ kthread+0x313/0x420 kernel/kthread.c:253
+ ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
+
+Reported-by: syzbot+cf4f2b6c24aff0a3edf6@syzkaller.appspotmail.com
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/ni_usb6501.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/ni_usb6501.c
++++ b/drivers/staging/comedi/drivers/ni_usb6501.c
+@@ -518,6 +518,9 @@ static int ni6501_auto_attach(struct com
+ if (!devpriv)
+ return -ENOMEM;
+
++ mutex_init(&devpriv->mut);
++ usb_set_intfdata(intf, devpriv);
++
+ ret = ni6501_find_endpoints(dev);
+ if (ret)
+ return ret;
+@@ -526,9 +529,6 @@ static int ni6501_auto_attach(struct com
+ if (ret)
+ return ret;
+
+- mutex_init(&devpriv->mut);
+- usb_set_intfdata(intf, devpriv);
+-
+ ret = comedi_alloc_subdevices(dev, 2);
+ if (ret)
+ return ret;
--- /dev/null
+From 663d294b4768bfd89e529e069bffa544a830b5bf Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Mon, 15 Apr 2019 12:52:30 +0100
+Subject: staging: comedi: vmk80xx: Fix possible double-free of ->usb_rx_buf
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 663d294b4768bfd89e529e069bffa544a830b5bf upstream.
+
+`vmk80xx_alloc_usb_buffers()` is called from `vmk80xx_auto_attach()` to
+allocate RX and TX buffers for USB transfers. It allocates
+`devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`. If the
+allocation of `devpriv->usb_tx_buf` fails, it frees
+`devpriv->usb_rx_buf`, leaving the pointer set dangling, and returns an
+error. Later, `vmk80xx_detach()` will be called from the core comedi
+module code to clean up. `vmk80xx_detach()` also frees both
+`devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
+`devpriv->usb_rx_buf` may have already been freed, leading to a
+double-free error. Fix it by removing the call to
+`kfree(devpriv->usb_rx_buf)` from `vmk80xx_alloc_usb_buffers()`, relying
+on `vmk80xx_detach()` to free the memory.
+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/vmk80xx.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/vmk80xx.c
++++ b/drivers/staging/comedi/drivers/vmk80xx.c
+@@ -682,10 +682,8 @@ static int vmk80xx_alloc_usb_buffers(str
+
+ size = usb_endpoint_maxp(devpriv->ep_tx);
+ devpriv->usb_tx_buf = kzalloc(size, GFP_KERNEL);
+- if (!devpriv->usb_tx_buf) {
+- kfree(devpriv->usb_rx_buf);
++ if (!devpriv->usb_tx_buf)
+ return -ENOMEM;
+- }
+
+ return 0;
+ }
--- /dev/null
+From 08b7c2f9208f0e2a32159e4e7a4831b7adb10a3e Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Mon, 15 Apr 2019 12:10:14 +0100
+Subject: staging: comedi: vmk80xx: Fix use of uninitialized semaphore
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 08b7c2f9208f0e2a32159e4e7a4831b7adb10a3e upstream.
+
+If `vmk80xx_auto_attach()` returns an error, the core comedi module code
+will call `vmk80xx_detach()` to clean up. If `vmk80xx_auto_attach()`
+successfully allocated the comedi device private data,
+`vmk80xx_detach()` assumes that a `struct semaphore limit_sem` contained
+in the private data has been initialized and uses it. Unfortunately,
+there are a couple of places where `vmk80xx_auto_attach()` can return an
+error after allocating the device private data but before initializing
+the semaphore, so this assumption is invalid. Fix it by initializing
+the semaphore just after allocating the private data in
+`vmk80xx_auto_attach()` before any other errors can be returned.
+
+I believe this was the cause of the following syzbot crash report
+<https://syzkaller.appspot.com/bug?extid=54c2f58f15fe6876b6ad>:
+
+usb 1-1: config 0 has no interface number 0
+usb 1-1: New USB device found, idVendor=10cf, idProduct=8068, bcdDevice=e6.8d
+usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
+usb 1-1: config 0 descriptor??
+vmk80xx 1-1:0.117: driver 'vmk80xx' failed to auto-configure device.
+INFO: trying to register non-static key.
+the code is fine but needs lockdep annotation.
+turning off the locking correctness validator.
+CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+Workqueue: usb_hub_wq hub_event
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0xe8/0x16e lib/dump_stack.c:113
+ assign_lock_key kernel/locking/lockdep.c:786 [inline]
+ register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
+ __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
+ lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
+ __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
+ _raw_spin_lock_irqsave+0x44/0x60 kernel/locking/spinlock.c:152
+ down+0x12/0x80 kernel/locking/semaphore.c:58
+ vmk80xx_detach+0x59/0x100 drivers/staging/comedi/drivers/vmk80xx.c:829
+ comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
+ comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
+ comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
+ comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
+ comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
+ comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
+ comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
+ usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
+ really_probe+0x2da/0xb10 drivers/base/dd.c:509
+ driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
+ __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
+ bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
+ __device_attach+0x223/0x3a0 drivers/base/dd.c:844
+ bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
+ device_add+0xad2/0x16e0 drivers/base/core.c:2106
+ usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
+ generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
+ usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
+ really_probe+0x2da/0xb10 drivers/base/dd.c:509
+ driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
+ __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
+ bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
+ __device_attach+0x223/0x3a0 drivers/base/dd.c:844
+ bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
+ device_add+0xad2/0x16e0 drivers/base/core.c:2106
+ usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
+ hub_port_connect drivers/usb/core/hub.c:5089 [inline]
+ hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
+ port_event drivers/usb/core/hub.c:5350 [inline]
+ hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
+ process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
+ worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
+ kthread+0x313/0x420 kernel/kthread.c:253
+ ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
+
+Reported-by: syzbot+54c2f58f15fe6876b6ad@syzkaller.appspotmail.com
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/vmk80xx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/vmk80xx.c
++++ b/drivers/staging/comedi/drivers/vmk80xx.c
+@@ -800,6 +800,8 @@ static int vmk80xx_auto_attach(struct co
+
+ devpriv->model = board->model;
+
++ sema_init(&devpriv->limit_sem, 8);
++
+ ret = vmk80xx_find_usb_endpoints(dev);
+ if (ret)
+ return ret;
+@@ -808,8 +810,6 @@ static int vmk80xx_auto_attach(struct co
+ if (ret)
+ return ret;
+
+- sema_init(&devpriv->limit_sem, 8);
+-
+ usb_set_intfdata(intf, devpriv);
+
+ if (devpriv->model == VMK8055_MODEL)
--- /dev/null
+From 7ce0f216221856a17fc4934b39284678a5fef2e9 Mon Sep 17 00:00:00 2001
+From: Mircea Caprioru <mircea.caprioru@analog.com>
+Date: Wed, 20 Feb 2019 13:08:20 +0200
+Subject: staging: iio: ad7192: Fix ad7193 channel address
+
+From: Mircea Caprioru <mircea.caprioru@analog.com>
+
+commit 7ce0f216221856a17fc4934b39284678a5fef2e9 upstream.
+
+This patch fixes the differential channels addresses for the ad7193.
+
+Signed-off-by: Mircea Caprioru <mircea.caprioru@analog.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/iio/adc/ad7192.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/staging/iio/adc/ad7192.c
++++ b/drivers/staging/iio/adc/ad7192.c
+@@ -109,10 +109,10 @@
+ #define AD7192_CH_AIN3 BIT(6) /* AIN3 - AINCOM */
+ #define AD7192_CH_AIN4 BIT(7) /* AIN4 - AINCOM */
+
+-#define AD7193_CH_AIN1P_AIN2M 0x000 /* AIN1(+) - AIN2(-) */
+-#define AD7193_CH_AIN3P_AIN4M 0x001 /* AIN3(+) - AIN4(-) */
+-#define AD7193_CH_AIN5P_AIN6M 0x002 /* AIN5(+) - AIN6(-) */
+-#define AD7193_CH_AIN7P_AIN8M 0x004 /* AIN7(+) - AIN8(-) */
++#define AD7193_CH_AIN1P_AIN2M 0x001 /* AIN1(+) - AIN2(-) */
++#define AD7193_CH_AIN3P_AIN4M 0x002 /* AIN3(+) - AIN4(-) */
++#define AD7193_CH_AIN5P_AIN6M 0x004 /* AIN5(+) - AIN6(-) */
++#define AD7193_CH_AIN7P_AIN8M 0x008 /* AIN7(+) - AIN8(-) */
+ #define AD7193_CH_TEMP 0x100 /* Temp senseor */
+ #define AD7193_CH_AIN2P_AIN2M 0x200 /* AIN2(+) - AIN2(-) */
+ #define AD7193_CH_AIN1 0x401 /* AIN1 - AINCOM */
--- /dev/null
+From 0a8a29be499cbb67df79370aaf5109085509feb8 Mon Sep 17 00:00:00 2001
+From: Leonard Pollak <leonardp@tr-host.de>
+Date: Wed, 13 Feb 2019 11:19:52 +0100
+Subject: Staging: iio: meter: fixed typo
+
+From: Leonard Pollak <leonardp@tr-host.de>
+
+commit 0a8a29be499cbb67df79370aaf5109085509feb8 upstream.
+
+This patch fixes an obvious typo, which will cause erroneously returning the Peak
+Voltage instead of the Peak Current.
+
+Signed-off-by: Leonard Pollak <leonardp@tr-host.de>
+Cc: <Stable@vger.kernel.org>
+Acked-by: Michael Hennerich <michael.hennerich@analog.com>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/iio/meter/ade7854.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/iio/meter/ade7854.c
++++ b/drivers/staging/iio/meter/ade7854.c
+@@ -269,7 +269,7 @@ static IIO_DEV_ATTR_VPEAK(0644,
+ static IIO_DEV_ATTR_IPEAK(0644,
+ ade7854_read_32bit,
+ ade7854_write_32bit,
+- ADE7854_VPEAK);
++ ADE7854_IPEAK);
+ static IIO_DEV_ATTR_APHCAL(0644,
+ ade7854_read_16bit,
+ ade7854_write_16bit,
--- /dev/null
+From 131ac62253dba79daf4a6d83ab12293d2b9863d3 Mon Sep 17 00:00:00 2001
+From: Christian Gromm <christian.gromm@microchip.com>
+Date: Tue, 2 Apr 2019 13:39:57 +0200
+Subject: staging: most: core: use device description as name
+
+From: Christian Gromm <christian.gromm@microchip.com>
+
+commit 131ac62253dba79daf4a6d83ab12293d2b9863d3 upstream.
+
+This patch uses the device description to clearly identity a device
+attached to the bus. It is needed as the currently useed mdevX
+notation is not sufficiant in case more than one network
+interface controller is being used at the same time.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/most/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/most/core.c
++++ b/drivers/staging/most/core.c
+@@ -1412,7 +1412,7 @@ int most_register_interface(struct most_
+
+ INIT_LIST_HEAD(&iface->p->channel_list);
+ iface->p->dev_id = id;
+- snprintf(iface->p->name, STRING_SIZE, "mdev%d", id);
++ strcpy(iface->p->name, iface->description);
+ iface->dev.init_name = iface->p->name;
+ iface->dev.bus = &mc.bus;
+ iface->dev.parent = &mc.dev;
--- /dev/null
+From 3f2552f7e9c5abef2775c53f7af66532f8bf65bc Mon Sep 17 00:00:00 2001
+From: Chang-An Chen <chang-an.chen@mediatek.com>
+Date: Fri, 29 Mar 2019 10:59:09 +0800
+Subject: timers/sched_clock: Prevent generic sched_clock wrap caused by tick_freeze()
+
+From: Chang-An Chen <chang-an.chen@mediatek.com>
+
+commit 3f2552f7e9c5abef2775c53f7af66532f8bf65bc upstream.
+
+tick_freeze() introduced by suspend-to-idle in commit 124cf9117c5f ("PM /
+sleep: Make it possible to quiesce timers during suspend-to-idle") uses
+timekeeping_suspend() instead of syscore_suspend() during
+suspend-to-idle. As a consequence generic sched_clock will keep going
+because sched_clock_suspend() and sched_clock_resume() are not invoked
+during suspend-to-idle which can result in a generic sched_clock wrap.
+
+On a ARM system with suspend-to-idle enabled, sched_clock is registered
+as "56 bits at 13MHz, resolution 76ns, wraps every 4398046511101ns", which
+means the real wrapping duration is 8796093022202ns.
+
+[ 134.551779] suspend-to-idle suspend (timekeeping_suspend())
+[ 1204.912239] suspend-to-idle resume (timekeeping_resume())
+......
+[ 1206.912239] suspend-to-idle suspend (timekeeping_suspend())
+[ 5880.502807] suspend-to-idle resume (timekeeping_resume())
+......
+[ 6000.403724] suspend-to-idle suspend (timekeeping_suspend())
+[ 8035.753167] suspend-to-idle resume (timekeeping_resume())
+......
+[ 8795.786684] (2)[321:charger_thread]......
+[ 8795.788387] (2)[321:charger_thread]......
+[ 0.057226] (0)[0:swapper/0]......
+[ 0.061447] (2)[0:swapper/2]......
+
+sched_clock was not stopped during suspend-to-idle, and sched_clock_poll
+hrtimer was not expired because timekeeping_suspend() was invoked during
+suspend-to-idle. It makes sched_clock wrap at kernel time 8796s.
+
+To prevent this, invoke sched_clock_suspend() and sched_clock_resume() in
+tick_freeze() together with timekeeping_suspend() and timekeeping_resume().
+
+Fixes: 124cf9117c5f (PM / sleep: Make it possible to quiesce timers during suspend-to-idle)
+Signed-off-by: Chang-An Chen <chang-an.chen@mediatek.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Frederic Weisbecker <fweisbec@gmail.com>
+Cc: Matthias Brugger <matthias.bgg@gmail.com>
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Corey Minyard <cminyard@mvista.com>
+Cc: <linux-mediatek@lists.infradead.org>
+Cc: <linux-arm-kernel@lists.infradead.org>
+Cc: Stanley Chu <stanley.chu@mediatek.com>
+Cc: <kuohong.wang@mediatek.com>
+Cc: <freddy.hsin@mediatek.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/1553828349-8914-1-git-send-email-chang-an.chen@mediatek.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/time/sched_clock.c | 4 ++--
+ kernel/time/tick-common.c | 2 ++
+ kernel/time/timekeeping.h | 7 +++++++
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+
+--- a/kernel/time/sched_clock.c
++++ b/kernel/time/sched_clock.c
+@@ -275,7 +275,7 @@ static u64 notrace suspended_sched_clock
+ return cd.read_data[seq & 1].epoch_cyc;
+ }
+
+-static int sched_clock_suspend(void)
++int sched_clock_suspend(void)
+ {
+ struct clock_read_data *rd = &cd.read_data[0];
+
+@@ -286,7 +286,7 @@ static int sched_clock_suspend(void)
+ return 0;
+ }
+
+-static void sched_clock_resume(void)
++void sched_clock_resume(void)
+ {
+ struct clock_read_data *rd = &cd.read_data[0];
+
+--- a/kernel/time/tick-common.c
++++ b/kernel/time/tick-common.c
+@@ -491,6 +491,7 @@ void tick_freeze(void)
+ trace_suspend_resume(TPS("timekeeping_freeze"),
+ smp_processor_id(), true);
+ system_state = SYSTEM_SUSPEND;
++ sched_clock_suspend();
+ timekeeping_suspend();
+ } else {
+ tick_suspend_local();
+@@ -514,6 +515,7 @@ void tick_unfreeze(void)
+
+ if (tick_freeze_depth == num_online_cpus()) {
+ timekeeping_resume();
++ sched_clock_resume();
+ system_state = SYSTEM_RUNNING;
+ trace_suspend_resume(TPS("timekeeping_freeze"),
+ smp_processor_id(), false);
+--- a/kernel/time/timekeeping.h
++++ b/kernel/time/timekeeping.h
+@@ -14,6 +14,13 @@ extern u64 timekeeping_max_deferment(voi
+ extern void timekeeping_warp_clock(void);
+ extern int timekeeping_suspend(void);
+ extern void timekeeping_resume(void);
++#ifdef CONFIG_GENERIC_SCHED_CLOCK
++extern int sched_clock_suspend(void);
++extern void sched_clock_resume(void);
++#else
++static inline int sched_clock_suspend(void) { return 0; }
++static inline void sched_clock_resume(void) { }
++#endif
+
+ extern void do_timer(unsigned long ticks);
+ extern void update_wall_time(void);
--- /dev/null
+From b2ecf00631362a83744e5ec249947620db5e240c Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Thu, 4 Apr 2019 20:53:28 -0400
+Subject: vt: fix cursor when clearing the screen
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit b2ecf00631362a83744e5ec249947620db5e240c upstream.
+
+The patch a6dbe4427559 ("vt: perform safe console erase in the right
+order") introduced a bug. The conditional do_update_region() was
+replaced by a call to update_region() that does contain the conditional
+already, but with unwanted extra side effects such as restoring the cursor
+drawing.
+
+In order to reproduce the bug:
+- use framebuffer console with the AMDGPU driver
+- type "links" to start the console www browser
+- press 'q' and space to exit links
+
+Now the cursor will be permanently visible in the center of the
+screen. It will stay there until something overwrites it.
+
+The bug goes away if we change update_region() back to the conditional
+do_update_region().
+
+[ nico: reworded changelog ]
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
+Cc: stable@vger.kernel.org
+Fixes: a6dbe4427559 ("vt: perform safe console erase in the right order")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/vt.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/vt/vt.c
++++ b/drivers/tty/vt/vt.c
+@@ -1521,7 +1521,8 @@ static void csi_J(struct vc_data *vc, in
+ return;
+ }
+ scr_memsetw(start, vc->vc_video_erase_char, 2 * count);
+- update_region(vc, (unsigned long) start, count);
++ if (con_should_update(vc))
++ do_update_region(vc, (unsigned long) start, count);
+ vc->vc_need_wrap = 0;
+ }
+
--- /dev/null
+From 1de7edbb59c8f1b46071f66c5c97b8a59569eb51 Mon Sep 17 00:00:00 2001
+From: Andi Kleen <ak@linux.intel.com>
+Date: Fri, 29 Mar 2019 17:47:43 -0700
+Subject: x86/cpu/bugs: Use __initconst for 'const' init data
+
+From: Andi Kleen <ak@linux.intel.com>
+
+commit 1de7edbb59c8f1b46071f66c5c97b8a59569eb51 upstream.
+
+Some of the recently added const tables use __initdata which causes section
+attribute conflicts.
+
+Use __initconst instead.
+
+Fixes: fa1202ef2243 ("x86/speculation: Add command line control")
+Signed-off-by: Andi Kleen <ak@linux.intel.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20190330004743.29541-9-andi@firstfloor.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/bugs.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/cpu/bugs.c
++++ b/arch/x86/kernel/cpu/bugs.c
+@@ -272,7 +272,7 @@ static const struct {
+ const char *option;
+ enum spectre_v2_user_cmd cmd;
+ bool secure;
+-} v2_user_options[] __initdata = {
++} v2_user_options[] __initconst = {
+ { "auto", SPECTRE_V2_USER_CMD_AUTO, false },
+ { "off", SPECTRE_V2_USER_CMD_NONE, false },
+ { "on", SPECTRE_V2_USER_CMD_FORCE, true },
+@@ -407,7 +407,7 @@ static const struct {
+ const char *option;
+ enum spectre_v2_mitigation_cmd cmd;
+ bool secure;
+-} mitigation_options[] __initdata = {
++} mitigation_options[] __initconst = {
+ { "off", SPECTRE_V2_CMD_NONE, false },
+ { "on", SPECTRE_V2_CMD_FORCE, true },
+ { "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
+@@ -643,7 +643,7 @@ static const char * const ssb_strings[]
+ static const struct {
+ const char *option;
+ enum ssb_mitigation_cmd cmd;
+-} ssb_mitigation_options[] __initdata = {
++} ssb_mitigation_options[] __initconst = {
+ { "auto", SPEC_STORE_BYPASS_CMD_AUTO }, /* Platform decides */
+ { "on", SPEC_STORE_BYPASS_CMD_ON }, /* Disable Speculative Store Bypass */
+ { "off", SPEC_STORE_BYPASS_CMD_NONE }, /* Don't touch Speculative Store Bypass */
--- /dev/null
+From 3ff9c075cc767b3060bdac12da72fc94dd7da1b8 Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@kernel.org>
+Date: Sun, 24 Feb 2019 01:49:52 +0900
+Subject: x86/kprobes: Verify stack frame on kretprobe
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+commit 3ff9c075cc767b3060bdac12da72fc94dd7da1b8 upstream.
+
+Verify the stack frame pointer on kretprobe trampoline handler,
+If the stack frame pointer does not match, it skips the wrong
+entry and tries to find correct one.
+
+This can happen if user puts the kretprobe on the function
+which can be used in the path of ftrace user-function call.
+Such functions should not be probed, so this adds a warning
+message that reports which function should be blacklisted.
+
+Tested-by: Andrea Righi <righi.andrea@gmail.com>
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Acked-by: Steven Rostedt <rostedt@goodmis.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/155094059185.6137.15527904013362842072.stgit@devbox
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/kprobes/core.c | 26 ++++++++++++++++++++++++++
+ include/linux/kprobes.h | 1 +
+ 2 files changed, 27 insertions(+)
+
+--- a/arch/x86/kernel/kprobes/core.c
++++ b/arch/x86/kernel/kprobes/core.c
+@@ -569,6 +569,7 @@ void arch_prepare_kretprobe(struct kretp
+ unsigned long *sara = stack_addr(regs);
+
+ ri->ret_addr = (kprobe_opcode_t *) *sara;
++ ri->fp = sara;
+
+ /* Replace the return addr with trampoline addr */
+ *sara = (unsigned long) &kretprobe_trampoline;
+@@ -759,15 +760,21 @@ __visible __used void *trampoline_handle
+ unsigned long flags, orig_ret_address = 0;
+ unsigned long trampoline_address = (unsigned long)&kretprobe_trampoline;
+ kprobe_opcode_t *correct_ret_addr = NULL;
++ void *frame_pointer;
++ bool skipped = false;
+
+ INIT_HLIST_HEAD(&empty_rp);
+ kretprobe_hash_lock(current, &head, &flags);
+ /* fixup registers */
+ #ifdef CONFIG_X86_64
+ regs->cs = __KERNEL_CS;
++ /* On x86-64, we use pt_regs->sp for return address holder. */
++ frame_pointer = ®s->sp;
+ #else
+ regs->cs = __KERNEL_CS | get_kernel_rpl();
+ regs->gs = 0;
++ /* On x86-32, we use pt_regs->flags for return address holder. */
++ frame_pointer = ®s->flags;
+ #endif
+ regs->ip = trampoline_address;
+ regs->orig_ax = ~0UL;
+@@ -789,8 +796,25 @@ __visible __used void *trampoline_handle
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
++ /*
++ * Return probes must be pushed on this hash list correct
++ * order (same as return order) so that it can be poped
++ * correctly. However, if we find it is pushed it incorrect
++ * order, this means we find a function which should not be
++ * probed, because the wrong order entry is pushed on the
++ * path of processing other kretprobe itself.
++ */
++ if (ri->fp != frame_pointer) {
++ if (!skipped)
++ pr_warn("kretprobe is stacked incorrectly. Trying to fixup.\n");
++ skipped = true;
++ continue;
++ }
+
+ orig_ret_address = (unsigned long)ri->ret_addr;
++ if (skipped)
++ pr_warn("%ps must be blacklisted because of incorrect kretprobe order\n",
++ ri->rp->kp.addr);
+
+ if (orig_ret_address != trampoline_address)
+ /*
+@@ -808,6 +832,8 @@ __visible __used void *trampoline_handle
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
++ if (ri->fp != frame_pointer)
++ continue;
+
+ orig_ret_address = (unsigned long)ri->ret_addr;
+ if (ri->rp && ri->rp->handler) {
+--- a/include/linux/kprobes.h
++++ b/include/linux/kprobes.h
+@@ -173,6 +173,7 @@ struct kretprobe_instance {
+ struct kretprobe *rp;
+ kprobe_opcode_t *ret_addr;
+ struct task_struct *task;
++ void *fp;
+ char data[0];
+ };
+
--- /dev/null
+From 2f5fb19341883bb6e37da351bc3700489d8506a7 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Sun, 14 Apr 2019 19:51:06 +0200
+Subject: x86/speculation: Prevent deadlock on ssb_state::lock
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 2f5fb19341883bb6e37da351bc3700489d8506a7 upstream.
+
+Mikhail reported a lockdep splat related to the AMD specific ssb_state
+lock:
+
+ CPU0 CPU1
+ lock(&st->lock);
+ local_irq_disable();
+ lock(&(&sighand->siglock)->rlock);
+ lock(&st->lock);
+ <Interrupt>
+ lock(&(&sighand->siglock)->rlock);
+
+ *** DEADLOCK ***
+
+The connection between sighand->siglock and st->lock comes through seccomp,
+which takes st->lock while holding sighand->siglock.
+
+Make sure interrupts are disabled when __speculation_ctrl_update() is
+invoked via prctl() -> speculation_ctrl_update(). Add a lockdep assert to
+catch future offenders.
+
+Fixes: 1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD")
+Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
+Cc: Thomas Lendacky <thomas.lendacky@amd.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1904141948200.4917@nanos.tec.linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/process.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/process.c
++++ b/arch/x86/kernel/process.c
+@@ -411,6 +411,8 @@ static __always_inline void __speculatio
+ u64 msr = x86_spec_ctrl_base;
+ bool updmsr = false;
+
++ lockdep_assert_irqs_disabled();
++
+ /*
+ * If TIF_SSBD is different, select the proper mitigation
+ * method. Note that if SSBD mitigation is disabled or permanentely
+@@ -462,10 +464,12 @@ static unsigned long speculation_ctrl_up
+
+ void speculation_ctrl_update(unsigned long tif)
+ {
++ unsigned long flags;
++
+ /* Forced update. Make sure all relevant TIF flags are different */
+- preempt_disable();
++ local_irq_save(flags);
+ __speculation_ctrl_update(~tif, tif);
+- preempt_enable();
++ local_irq_restore(flags);
+ }
+
+ /* Called from seccomp/prctl update */
projects / thirdparty / kernel / stable-queue.git / commitdiff
