--- /dev/null
+From 25962e1a7f1d522f1b57ead2f266fab570042a70 Mon Sep 17 00:00:00 2001
+From: Frieder Schrempf <frieder.schrempf@kontron.de>
+Date: Tue, 25 Feb 2020 08:23:20 +0000
+Subject: dmaengine: imx-sdma: Fix the event id check to include RX event for UART6
+
+From: Frieder Schrempf <frieder.schrempf@kontron.de>
+
+commit 25962e1a7f1d522f1b57ead2f266fab570042a70 upstream.
+
+On i.MX6UL/ULL and i.MX6SX the DMA event id for the RX channel of
+UART6 is '0'. To fix the broken DMA support for UART6, we change
+the check for event_id0 to include '0' as a valid id.
+
+Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
+Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200225082139.7646-1-frieder.schrempf@kontron.de
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
+index 332ca5034504..4d4477df4ede 100644
+--- a/drivers/dma/imx-sdma.c
++++ b/drivers/dma/imx-sdma.c
+@@ -1331,7 +1331,7 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
+
+ sdma_channel_synchronize(chan);
+
+- if (sdmac->event_id0)
++ if (sdmac->event_id0 >= 0)
+ sdma_event_disable(sdmac, sdmac->event_id0);
+ if (sdmac->event_id1)
+ sdma_event_disable(sdmac, sdmac->event_id1);
+@@ -1632,7 +1632,7 @@ static int sdma_config(struct dma_chan *chan,
+ memcpy(&sdmac->slave_config, dmaengine_cfg, sizeof(*dmaengine_cfg));
+
+ /* Set ENBLn earlier to make sure dma request triggered after that */
+- if (sdmac->event_id0) {
++ if (sdmac->event_id0 >= 0) {
+ if (sdmac->event_id0 >= sdmac->sdma->drvdata->num_events)
+ return -EINVAL;
+ sdma_event_enable(sdmac, sdmac->event_id0);
--- /dev/null
+From 316e730f1d8bb029fe6cec2468fb2a50424485b3 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Tue, 4 Feb 2020 19:13:06 +0100
+Subject: media: v4l2-mem2mem.c: fix broken links
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 316e730f1d8bb029fe6cec2468fb2a50424485b3 upstream.
+
+The topology that v4l2_m2m_register_media_controller() creates for a
+processing block actually created a source-to-source link and a sink-to-sink
+link instead of two source-to-sink links.
+
+Unfortunately v4l2-compliance never checked for such bad links, so this
+went unreported for quite some time.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Reported-by: Nicolas Dufresne <nicolas@ndufresne.ca>
+Cc: <stable@vger.kernel.org> # for v4.19 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/v4l2-core/v4l2-mem2mem.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
++++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
+@@ -787,12 +787,12 @@ int v4l2_m2m_register_media_controller(s
+ goto err_rel_entity1;
+
+ /* Connect the three entities */
+- ret = media_create_pad_link(m2m_dev->source, 0, &m2m_dev->proc, 1,
++ ret = media_create_pad_link(m2m_dev->source, 0, &m2m_dev->proc, 0,
+ MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ goto err_rel_entity2;
+
+- ret = media_create_pad_link(&m2m_dev->proc, 0, &m2m_dev->sink, 0,
++ ret = media_create_pad_link(&m2m_dev->proc, 1, &m2m_dev->sink, 0,
+ MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ goto err_rm_links0;
serial-8250_exar-add-support-for-acces-cards.patch
vt-selection-close-sel_buffer-race.patch
vt-selection-push-console-lock-down.patch
+vt-selection-push-sel_lock-up.patch
+media-v4l2-mem2mem.c-fix-broken-links.patch
+x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch
+dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch
--- /dev/null
+From e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Fri, 28 Feb 2020 12:54:06 +0100
+Subject: vt: selection, push sel_lock up
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 upstream.
+
+sel_lock cannot nest in the console lock. Thanks to syzkaller, the
+kernel states firmly:
+
+> WARNING: possible circular locking dependency detected
+> 5.6.0-rc3-syzkaller #0 Not tainted
+> ------------------------------------------------------
+> syz-executor.4/20336 is trying to acquire lock:
+> ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
+>
+> but task is already holding lock:
+> ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
+>
+> which lock already depends on the new lock.
+>
+> the existing dependency chain (in reverse order) is:
+>
+> -> #2 (sel_lock){+.+.}:
+> mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118
+> set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217
+> set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181
+> tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050
+> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
+
+This is ioctl(TIOCL_SETSEL).
+Locks held on the path: console_lock -> sel_lock
+
+> -> #1 (console_lock){+.+.}:
+> console_lock+0x46/0x70 kernel/printk/printk.c:2289
+> con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223
+> n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350
+> do_tty_write drivers/tty/tty_io.c:962 [inline]
+> tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046
+
+This is write().
+Locks held on the path: termios_rwsem -> console_lock
+
+> -> #0 (&tty->termios_rwsem){++++}:
+> down_write+0x57/0x140 kernel/locking/rwsem.c:1534
+> tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
+> mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902
+> tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465
+> paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389
+> tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055
+> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
+
+This is ioctl(TIOCL_PASTESEL).
+Locks held on the path: sel_lock -> termios_rwsem
+
+> other info that might help us debug this:
+>
+> Chain exists of:
+> &tty->termios_rwsem --> console_lock --> sel_lock
+
+Clearly. From the above, we have:
+ console_lock -> sel_lock
+ sel_lock -> termios_rwsem
+ termios_rwsem -> console_lock
+
+Fix this by reversing the console_lock -> sel_lock dependency in
+ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock.
+
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com
+Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race")
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.cz
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/selection.c | 16 +++++++---------
+ 1 file changed, 7 insertions(+), 9 deletions(-)
+
+--- a/drivers/tty/vt/selection.c
++++ b/drivers/tty/vt/selection.c
+@@ -202,7 +202,6 @@ static int __set_selection(const struct
+ if (ps > pe) /* make sel_start <= sel_end */
+ swap(ps, pe);
+
+- mutex_lock(&sel_lock);
+ if (sel_cons != vc_cons[fg_console].d) {
+ clear_selection();
+ sel_cons = vc_cons[fg_console].d;
+@@ -248,10 +247,9 @@ static int __set_selection(const struct
+ break;
+ case TIOCL_SELPOINTER:
+ highlight_pointer(pe);
+- goto unlock;
++ return 0;
+ default:
+- ret = -EINVAL;
+- goto unlock;
++ return -EINVAL;
+ }
+
+ /* remove the pointer */
+@@ -273,7 +271,7 @@ static int __set_selection(const struct
+ else if (new_sel_start == sel_start)
+ {
+ if (new_sel_end == sel_end) /* no action required */
+- goto unlock;
++ return 0;
+ else if (new_sel_end > sel_end) /* extend to right */
+ highlight(sel_end + 2, new_sel_end);
+ else /* contract from right */
+@@ -301,8 +299,7 @@ static int __set_selection(const struct
+ if (!bp) {
+ printk(KERN_WARNING "selection: kmalloc() failed\n");
+ clear_selection();
+- ret = -ENOMEM;
+- goto unlock;
++ return -ENOMEM;
+ }
+ kfree(sel_buffer);
+ sel_buffer = bp;
+@@ -327,8 +324,7 @@ static int __set_selection(const struct
+ }
+ }
+ sel_buffer_lth = bp - sel_buffer;
+-unlock:
+- mutex_unlock(&sel_lock);
++
+ return ret;
+ }
+
+@@ -336,9 +332,11 @@ int set_selection(const struct tiocl_sel
+ {
+ int ret;
+
++ mutex_lock(&sel_lock);
+ console_lock();
+ ret = __set_selection(v, tty);
+ console_unlock();
++ mutex_unlock(&sel_lock);
+
+ return ret;
+ }
--- /dev/null
+From 735a6dd02222d8d070c7bb748f25895239ca8c92 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Wed, 26 Feb 2020 15:16:15 -0800
+Subject: x86/pkeys: Manually set X86_FEATURE_OSPKE to preserve existing changes
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+commit 735a6dd02222d8d070c7bb748f25895239ca8c92 upstream.
+
+Explicitly set X86_FEATURE_OSPKE via set_cpu_cap() instead of calling
+get_cpu_cap() to pull the feature bit from CPUID after enabling CR4.PKE.
+Invoking get_cpu_cap() effectively wipes out any {set,clear}_cpu_cap()
+changes that were made between this_cpu->c_init() and setup_pku(), as
+all non-synthetic feature words are reinitialized from the CPU's CPUID
+values.
+
+Blasting away capability updates manifests most visibility when running
+on a VMX capable CPU, but with VMX disabled by BIOS. To indicate that
+VMX is disabled, init_ia32_feat_ctl() clears X86_FEATURE_VMX, using
+clear_cpu_cap() instead of setup_clear_cpu_cap() so that KVM can report
+which CPU is misconfigured (KVM needs to probe every CPU anyways).
+Restoring X86_FEATURE_VMX from CPUID causes KVM to think VMX is enabled,
+ultimately leading to an unexpected #GP when KVM attempts to do VMXON.
+
+Arguably, init_ia32_feat_ctl() should use setup_clear_cpu_cap() and let
+KVM figure out a different way to report the misconfigured CPU, but VMX
+is not the only feature bit that is affected, i.e. there is precedent
+that tweaking feature bits via {set,clear}_cpu_cap() after ->c_init()
+is expected to work. Most notably, x86_init_rdrand()'s clearing of
+X86_FEATURE_RDRAND when RDRAND malfunctions is also overwritten.
+
+Fixes: 0697694564c8 ("x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU")
+Reported-by: Jacob Keller <jacob.e.keller@intel.com>
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
+Tested-by: Jacob Keller <jacob.e.keller@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20200226231615.13664-1-sean.j.christopherson@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/common.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/cpu/common.c
++++ b/arch/x86/kernel/cpu/common.c
+@@ -387,7 +387,7 @@ static __always_inline void setup_pku(st
+ * cpuid bit to be set. We need to ensure that we
+ * update that bit in this CPU's "cpu_info".
+ */
+- get_cpu_cap(c);
++ set_cpu_cap(c, X86_FEATURE_OSPKE);
+ }
+
+ #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
projects / thirdparty / kernel / stable-queue.git / commitdiff
