--- /dev/null
+From 7fbd1753b64eafe21cf842348a40a691d0dee440 Mon Sep 17 00:00:00 2001
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Date: Mon, 1 Jul 2019 23:43:53 +0900
+Subject: ALSA: firewire-lib/fireworks: fix miss detection of received MIDI messages
+
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+
+commit 7fbd1753b64eafe21cf842348a40a691d0dee440 upstream.
+
+In IEC 61883-6, 8 MIDI data streams are multiplexed into single
+MIDI conformant data channel. The index of stream is calculated by
+modulo 8 of the value of data block counter.
+
+In fireworks, the value of data block counter in CIP header has a quirk
+with firmware version v5.0.0, v5.7.3 and v5.8.0. This brings ALSA
+IEC 61883-1/6 packet streaming engine to miss detection of MIDI
+messages.
+
+This commit fixes the miss detection to modify the value of data block
+counter for the modulo calculation.
+
+For maintainers, this bug exists since a commit 18f5ed365d3f ("ALSA:
+fireworks/firewire-lib: add support for recent firmware quirk") in Linux
+kernel v4.2. There're many changes since the commit. This fix can be
+backported to Linux kernel v4.4 or later. I tagged a base commit to the
+backport for your convenience.
+
+Besides, my work for Linux kernel v5.3 brings heavy code refactoring and
+some structure members are renamed in 'sound/firewire/amdtp-stream.h'.
+The content of this patch brings conflict when merging -rc tree with
+this patch and the latest tree. I request maintainers to solve the
+conflict to replace 'tx_first_dbc' with 'ctx_data.tx.first_dbc'.
+
+Fixes: df075feefbd3 ("ALSA: firewire-lib: complete AM824 data block processing layer")
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/firewire/amdtp-am824.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/firewire/amdtp-am824.c
++++ b/sound/firewire/amdtp-am824.c
+@@ -321,7 +321,7 @@ static void read_midi_messages(struct am
+ u8 *b;
+
+ for (f = 0; f < frames; f++) {
+- port = (s->data_block_counter + f) % 8;
++ port = (8 - s->tx_first_dbc + s->data_block_counter + f) % 8;
+ b = (u8 *)&buffer[p->midi_position];
+
+ len = b[0] - 0x80;
--- /dev/null
+From 503d90b30602a3295978e46d844ccc8167400fe6 Mon Sep 17 00:00:00 2001
+From: Richard Sailer <rs@tuxedocomputers.com>
+Date: Wed, 19 Jun 2019 13:33:11 +0200
+Subject: ALSA: hda/realtek: Add quirks for several Clevo notebook barebones
+
+From: Richard Sailer <rs@tuxedocomputers.com>
+
+commit 503d90b30602a3295978e46d844ccc8167400fe6 upstream.
+
+This adds 4 SND_PCI_QUIRK(...) lines for several barebone models of the ODM
+Clevo. The model names are written in regex syntax to describe/match all clevo
+models that are similar enough and use the same PCI SSID that this fixup works
+for them.
+
+Additionally the lines regarding SSID 0x96e1 and 0x97e1 didn't fix audio for the
+all our Clevo notebooks using these SSIDs (models Clevo P960* and P970*) since
+ALC1220_FIXP_CLEVO_PB51ED_PINS swapped pins that are not necesarry to be
+swapped. This patch initiates ALC1220_FIXUP_CLEVO_P950 instead for these model
+and fixes the audio.
+
+Fixes: 80690a276f44 ("ALSA: hda/realtek - Add quirk for Tuxedo XC 1509")
+Signed-off-by: Richard Sailer <rs@tuxedocomputers.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -2443,9 +2443,10 @@ static const struct snd_pci_quirk alc882
+ SND_PCI_QUIRK(0x1558, 0x9501, "Clevo P950HR", ALC1220_FIXUP_CLEVO_P950),
+ SND_PCI_QUIRK(0x1558, 0x95e1, "Clevo P95xER", ALC1220_FIXUP_CLEVO_P950),
+ SND_PCI_QUIRK(0x1558, 0x95e2, "Clevo P950ER", ALC1220_FIXUP_CLEVO_P950),
+- SND_PCI_QUIRK(0x1558, 0x96e1, "System76 Oryx Pro (oryp5)", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
+- SND_PCI_QUIRK(0x1558, 0x97e1, "System76 Oryx Pro (oryp5)", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
+- SND_PCI_QUIRK(0x1558, 0x65d1, "Tuxedo Book XC1509", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
++ SND_PCI_QUIRK(0x1558, 0x96e1, "Clevo P960[ER][CDFN]-K", ALC1220_FIXUP_CLEVO_P950),
++ SND_PCI_QUIRK(0x1558, 0x97e1, "Clevo P970[ER][CDFN]", ALC1220_FIXUP_CLEVO_P950),
++ SND_PCI_QUIRK(0x1558, 0x65d1, "Clevo PB51[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
++ SND_PCI_QUIRK(0x1558, 0x67d1, "Clevo PB71[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
+ SND_PCI_QUIRK_VENDOR(0x1558, "Clevo laptop", ALC882_FIXUP_EAPD),
+ SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_FIXUP_EAPD),
+ SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo Y530", ALC882_FIXUP_LENOVO_Y530),
--- /dev/null
+From bef33e19203dde434bcdf21c449e3fb4f06c2618 Mon Sep 17 00:00:00 2001
+From: Dennis Wassenberg <dennis.wassenberg@secunet.com>
+Date: Fri, 28 Jun 2019 10:54:53 +0200
+Subject: ALSA: hda/realtek - Change front mic location for Lenovo M710q
+
+From: Dennis Wassenberg <dennis.wassenberg@secunet.com>
+
+commit bef33e19203dde434bcdf21c449e3fb4f06c2618 upstream.
+
+On M710q Lenovo ThinkCentre machine, there are two front mics,
+we change the location for one of them to avoid conflicts.
+
+Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -7031,6 +7031,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY),
+ SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY),
+ SND_PCI_QUIRK(0x17aa, 0x310c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
++ SND_PCI_QUIRK(0x17aa, 0x3111, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
+ SND_PCI_QUIRK(0x17aa, 0x312a, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
+ SND_PCI_QUIRK(0x17aa, 0x312f, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
+ SND_PCI_QUIRK(0x17aa, 0x313c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
--- /dev/null
+From 3450121997ce872eb7f1248417225827ea249710 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 2 Jul 2019 20:07:21 +0200
+Subject: ALSA: line6: Fix write on zero-sized buffer
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 3450121997ce872eb7f1248417225827ea249710 upstream.
+
+LINE6 drivers allocate the buffers based on the value returned from
+usb_maxpacket() calls. The manipulated device may return zero for
+this, and this results in the kmalloc() with zero size (and it may
+succeed) while the other part of the driver code writes the packet
+data with the fixed size -- which eventually overwrites.
+
+This patch adds a simple sanity check for the invalid buffer size for
+avoiding that problem.
+
+Reported-by: syzbot+219f00fb49874dcaea17@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/usb/line6/pcm.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/sound/usb/line6/pcm.c
++++ b/sound/usb/line6/pcm.c
+@@ -560,6 +560,11 @@ int line6_init_pcm(struct usb_line6 *lin
+ line6pcm->max_packet_size_out =
+ usb_maxpacket(line6->usbdev,
+ usb_sndisocpipe(line6->usbdev, ep_write), 1);
++ if (!line6pcm->max_packet_size_in || !line6pcm->max_packet_size_out) {
++ dev_err(line6pcm->line6->ifcdev,
++ "cannot get proper max packet size\n");
++ return -EINVAL;
++ }
+
+ spin_lock_init(&line6pcm->out.lock);
+ spin_lock_init(&line6pcm->in.lock);
--- /dev/null
+From c3ea60c231446663afd6ea1054da6b7f830855ca Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@canonical.com>
+Date: Fri, 28 Jun 2019 10:54:29 +0100
+Subject: ALSA: seq: fix incorrect order of dest_client/dest_ports arguments
+
+From: Colin Ian King <colin.king@canonical.com>
+
+commit c3ea60c231446663afd6ea1054da6b7f830855ca upstream.
+
+There are two occurrances of a call to snd_seq_oss_fill_addr where
+the dest_client and dest_port arguments are in the wrong order. Fix
+this by swapping them around.
+
+Addresses-Coverity: ("Arguments in wrong order")
+Signed-off-by: Colin Ian King <colin.king@canonical.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/seq/oss/seq_oss_ioctl.c | 2 +-
+ sound/core/seq/oss/seq_oss_rw.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/core/seq/oss/seq_oss_ioctl.c
++++ b/sound/core/seq/oss/seq_oss_ioctl.c
+@@ -62,7 +62,7 @@ static int snd_seq_oss_oob_user(struct s
+ if (copy_from_user(ev, arg, 8))
+ return -EFAULT;
+ memset(&tmpev, 0, sizeof(tmpev));
+- snd_seq_oss_fill_addr(dp, &tmpev, dp->addr.port, dp->addr.client);
++ snd_seq_oss_fill_addr(dp, &tmpev, dp->addr.client, dp->addr.port);
+ tmpev.time.tick = 0;
+ if (! snd_seq_oss_process_event(dp, (union evrec *)ev, &tmpev)) {
+ snd_seq_oss_dispatch(dp, &tmpev, 0, 0);
+--- a/sound/core/seq/oss/seq_oss_rw.c
++++ b/sound/core/seq/oss/seq_oss_rw.c
+@@ -174,7 +174,7 @@ insert_queue(struct seq_oss_devinfo *dp,
+ memset(&event, 0, sizeof(event));
+ /* set dummy -- to be sure */
+ event.type = SNDRV_SEQ_EVENT_NOTEOFF;
+- snd_seq_oss_fill_addr(dp, &event, dp->addr.port, dp->addr.client);
++ snd_seq_oss_fill_addr(dp, &event, dp->addr.client, dp->addr.port);
+
+ if (snd_seq_oss_process_event(dp, rec, &event))
+ return 0; /* invalid event - no need to insert queue */
--- /dev/null
+From 2acf5a3e6e9371e63c9e4ff54d84d08f630467a0 Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@canonical.com>
+Date: Thu, 27 Jun 2019 17:43:08 +0100
+Subject: ALSA: usb-audio: fix sign unintended sign extension on left shifts
+
+From: Colin Ian King <colin.king@canonical.com>
+
+commit 2acf5a3e6e9371e63c9e4ff54d84d08f630467a0 upstream.
+
+There are a couple of left shifts of unsigned 8 bit values that
+first get promoted to signed ints and hence get sign extended
+on the shift if the top bit of the 8 bit values are set. Fix
+this by casting the 8 bit values to unsigned ints to stop the
+unintentional sign extension.
+
+Addresses-Coverity: ("Unintended sign extension")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/mixer_quirks.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/usb/mixer_quirks.c
++++ b/sound/usb/mixer_quirks.c
+@@ -754,7 +754,7 @@ static int snd_ni_control_init_val(struc
+ return err;
+ }
+
+- kctl->private_value |= (value << 24);
++ kctl->private_value |= ((unsigned int)value << 24);
+ return 0;
+ }
+
+@@ -915,7 +915,7 @@ static int snd_ftu_eff_switch_init(struc
+ if (err < 0)
+ return err;
+
+- kctl->private_value |= value[0] << 24;
++ kctl->private_value |= (unsigned int)value[0] << 24;
+ return 0;
+ }
+
--- /dev/null
+From 80031361747aec92163464f2ee08870fec33bcb0 Mon Sep 17 00:00:00 2001
+From: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
+Date: Wed, 26 Jun 2019 10:11:08 +1200
+Subject: ARM: dts: armada-xp-98dx3236: Switch to armada-38x-uart serial node
+
+From: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
+
+commit 80031361747aec92163464f2ee08870fec33bcb0 upstream.
+
+Switch to the "marvell,armada-38x-uart" driver variant to empty
+the UART buffer before writing to the UART_LCR register.
+
+Signed-off-by: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
+Tested-by: Andrew Lunn <andrew@lunn.ch>
+Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>.
+Cc: stable@vger.kernel.org
+Fixes: 43e28ba87708 ("ARM: dts: Use armada-370-xp as a base for armada-xp-98dx3236")
+Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
++++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+@@ -336,3 +336,11 @@
+ status = "disabled";
+ };
+
++&uart0 {
++ compatible = "marvell,armada-38x-uart";
++};
++
++&uart1 {
++ compatible = "marvell,armada-38x-uart";
++};
++
--- /dev/null
+From 6f496a555d93db7a11d4860b9220d904822f586a Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Date: Tue, 25 Jun 2019 19:08:54 +0200
+Subject: arm64: kaslr: keep modules inside module region when KASAN is enabled
+
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+
+commit 6f496a555d93db7a11d4860b9220d904822f586a upstream.
+
+When KASLR and KASAN are both enabled, we keep the modules where they
+are, and randomize the placement of the kernel so it is within 2 GB
+of the module region. The reason for this is that putting modules in
+the vmalloc region (like we normally do when KASLR is enabled) is not
+possible in this case, given that the entire vmalloc region is already
+backed by KASAN zero shadow pages, and so allocating dedicated KASAN
+shadow space as required by loaded modules is not possible.
+
+The default module allocation window is set to [_etext - 128MB, _etext]
+in kaslr.c, which is appropriate for KASLR kernels booted without a
+seed or with 'nokaslr' on the command line. However, as it turns out,
+it is not quite correct for the KASAN case, since it still intersects
+the vmalloc region at the top, where attempts to allocate shadow pages
+will collide with the KASAN zero shadow pages, causing a WARN() and all
+kinds of other trouble. So cap the top end to MODULES_END explicitly
+when running with KASAN.
+
+Cc: <stable@vger.kernel.org> # 4.9+
+Acked-by: Catalin Marinas <catalin.marinas@arm.com>
+Tested-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kernel/module.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/kernel/module.c
++++ b/arch/arm64/kernel/module.c
+@@ -32,6 +32,7 @@
+
+ void *module_alloc(unsigned long size)
+ {
++ u64 module_alloc_end = module_alloc_base + MODULES_VSIZE;
+ gfp_t gfp_mask = GFP_KERNEL;
+ void *p;
+
+@@ -39,9 +40,12 @@ void *module_alloc(unsigned long size)
+ if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
+ gfp_mask |= __GFP_NOWARN;
+
++ if (IS_ENABLED(CONFIG_KASAN))
++ /* don't exceed the static module region - see below */
++ module_alloc_end = MODULES_END;
++
+ p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
+- module_alloc_base + MODULES_VSIZE,
+- gfp_mask, PAGE_KERNEL_EXEC, 0,
++ module_alloc_end, gfp_mask, PAGE_KERNEL_EXEC, 0,
+ NUMA_NO_NODE, __builtin_return_address(0));
+
+ if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
--- /dev/null
+From 1a0fad630e0b7cff38e7691b28b0517cfbb0633f Mon Sep 17 00:00:00 2001
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+Date: Tue, 2 Jul 2019 09:53:25 +0200
+Subject: crypto: cryptd - Fix skcipher instance memory leak
+
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+
+commit 1a0fad630e0b7cff38e7691b28b0517cfbb0633f upstream.
+
+cryptd_skcipher_free() fails to free the struct skcipher_instance
+allocated in cryptd_create_skcipher(), leading to a memory leak. This
+is detected by kmemleak on bootup on ARM64 platforms:
+
+ unreferenced object 0xffff80003377b180 (size 1024):
+ comm "cryptomgr_probe", pid 822, jiffies 4294894830 (age 52.760s)
+ backtrace:
+ kmem_cache_alloc_trace+0x270/0x2d0
+ cryptd_create+0x990/0x124c
+ cryptomgr_probe+0x5c/0x1e8
+ kthread+0x258/0x318
+ ret_from_fork+0x10/0x1c
+
+Fixes: 4e0958d19bd8 ("crypto: cryptd - Add support for skcipher")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/cryptd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/crypto/cryptd.c
++++ b/crypto/cryptd.c
+@@ -586,6 +586,7 @@ static void cryptd_skcipher_free(struct
+ struct skcipherd_instance_ctx *ctx = skcipher_instance_ctx(inst);
+
+ crypto_drop_skcipher(&ctx->spawn);
++ kfree(inst);
+ }
+
+ static int cryptd_create_skcipher(struct crypto_template *tmpl,
--- /dev/null
+From 21d4120ec6f5b5992b01b96ac484701163917b63 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 2 Jul 2019 14:17:00 -0700
+Subject: crypto: user - prevent operating on larval algorithms
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 21d4120ec6f5b5992b01b96ac484701163917b63 upstream.
+
+Michal Suchanek reported [1] that running the pcrypt_aead01 test from
+LTP [2] in a loop and holding Ctrl-C causes a NULL dereference of
+alg->cra_users.next in crypto_remove_spawns(), via crypto_del_alg().
+The test repeatedly uses CRYPTO_MSG_NEWALG and CRYPTO_MSG_DELALG.
+
+The crash occurs when the instance that CRYPTO_MSG_DELALG is trying to
+unregister isn't a real registered algorithm, but rather is a "test
+larval", which is a special "algorithm" added to the algorithms list
+while the real algorithm is still being tested. Larvals don't have
+initialized cra_users, so that causes the crash. Normally pcrypt_aead01
+doesn't trigger this because CRYPTO_MSG_NEWALG waits for the algorithm
+to be tested; however, CRYPTO_MSG_NEWALG returns early when interrupted.
+
+Everything else in the "crypto user configuration" API has this same bug
+too, i.e. it inappropriately allows operating on larval algorithms
+(though it doesn't look like the other cases can cause a crash).
+
+Fix this by making crypto_alg_match() exclude larval algorithms.
+
+[1] https://lkml.kernel.org/r/20190625071624.27039-1-msuchanek@suse.de
+[2] https://github.com/linux-test-project/ltp/blob/20190517/testcases/kernel/crypto/pcrypt_aead01.c
+
+Reported-by: Michal Suchanek <msuchanek@suse.de>
+Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
+Cc: <stable@vger.kernel.org> # v3.2+
+Cc: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/crypto_user_base.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/crypto/crypto_user_base.c
++++ b/crypto/crypto_user_base.c
+@@ -56,6 +56,9 @@ struct crypto_alg *crypto_alg_match(stru
+ list_for_each_entry(q, &crypto_alg_list, cra_list) {
+ int match = 0;
+
++ if (crypto_is_larval(q))
++ continue;
++
+ if ((q->cra_flags ^ p->cru_type) & p->cru_mask)
+ continue;
+
--- /dev/null
+From 1571c029a2ff289683ddb0a32253850363bcb8a7 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Thu, 6 Jun 2019 11:10:28 +0200
+Subject: dax: Fix xarray entry association for mixed mappings
+
+From: Jan Kara <jack@suse.cz>
+
+commit 1571c029a2ff289683ddb0a32253850363bcb8a7 upstream.
+
+When inserting entry into xarray, we store mapping and index in
+corresponding struct pages for memory error handling. When it happened
+that one process was mapping file at PMD granularity while another
+process at PTE granularity, we could wrongly deassociate PMD range and
+then reassociate PTE range leaving the rest of struct pages in PMD range
+without mapping information which could later cause missed notifications
+about memory errors. Fix the problem by calling the association /
+deassociation code if and only if we are really going to update the
+xarray (deassociating and associating zero or empty entries is just
+no-op so there's no reason to complicate the code with trying to avoid
+the calls for these cases).
+
+Cc: <stable@vger.kernel.org>
+Fixes: d2c997c0f145 ("fs, dax: use page->mapping to warn if truncate...")
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/dax.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/fs/dax.c
++++ b/fs/dax.c
+@@ -728,12 +728,11 @@ static void *dax_insert_entry(struct xa_
+
+ xas_reset(xas);
+ xas_lock_irq(xas);
+- if (dax_entry_size(entry) != dax_entry_size(new_entry)) {
++ if (dax_is_zero_entry(entry) || dax_is_empty_entry(entry)) {
++ void *old;
++
+ dax_disassociate_entry(entry, mapping, false);
+ dax_associate_entry(new_entry, mapping, vmf->vma, vmf->address);
+- }
+-
+- if (dax_is_zero_entry(entry) || dax_is_empty_entry(entry)) {
+ /*
+ * Only swap our new entry into the page cache if the current
+ * entry is a zero page or an empty entry. If a normal PTE or
+@@ -742,7 +741,7 @@ static void *dax_insert_entry(struct xa_
+ * existing entry is a PMD, we will just leave the PMD in the
+ * tree and dirty it if necessary.
+ */
+- void *old = dax_lock_entry(xas, new_entry);
++ old = dax_lock_entry(xas, new_entry);
+ WARN_ON_ONCE(old != xa_mk_value(xa_to_value(entry) |
+ DAX_LOCKED));
+ entry = new_entry;
--- /dev/null
+From f78c581e22d4b33359ac3462e8d0504735df01f4 Mon Sep 17 00:00:00 2001
+From: Evan Quan <evan.quan@amd.com>
+Date: Thu, 27 Jun 2019 11:01:04 +0800
+Subject: drm/amd/powerplay: use hardware fan control if no powerplay fan table
+
+From: Evan Quan <evan.quan@amd.com>
+
+commit f78c581e22d4b33359ac3462e8d0504735df01f4 upstream.
+
+Otherwise, you may get divided-by-zero error or corrput the SMU fan
+control feature.
+
+Signed-off-by: Evan Quan <evan.quan@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Tested-by: Slava Abramov <slava.abramov@amd.com>
+Acked-by: Slava Abramov <slava.abramov@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/powerplay/hwmgr/process_pptables_v1_0.c | 4 +++-
+ drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 +
+ drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 4 ++++
+ 3 files changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
++++ b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
+@@ -916,8 +916,10 @@ static int init_thermal_controller(
+ PHM_PlatformCaps_ThermalController
+ );
+
+- if (0 == powerplay_table->usFanTableOffset)
++ if (0 == powerplay_table->usFanTableOffset) {
++ hwmgr->thermal_controller.use_hw_fan_control = 1;
+ return 0;
++ }
+
+ fan_table = (const PPTable_Generic_SubTable_Header *)
+ (((unsigned long)powerplay_table) +
+--- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
++++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
+@@ -694,6 +694,7 @@ struct pp_thermal_controller_info {
+ uint8_t ucType;
+ uint8_t ucI2cLine;
+ uint8_t ucI2cAddress;
++ uint8_t use_hw_fan_control;
+ struct pp_fan_info fanInfo;
+ struct pp_advance_fan_control_parameters advanceFanControlParameters;
+ };
+--- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
++++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
+@@ -2092,6 +2092,10 @@ static int polaris10_thermal_setup_fan_t
+ return 0;
+ }
+
++ /* use hardware fan control */
++ if (hwmgr->thermal_controller.use_hw_fan_control)
++ return 0;
++
+ tmp64 = hwmgr->thermal_controller.advanceFanControlParameters.
+ usPWMMin * duty100;
+ do_div(tmp64, 10000);
--- /dev/null
+From 688f3d1ebedffa310b6591bd1b63fa0770d945fe Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Thu, 20 Jun 2019 19:21:26 -0400
+Subject: drm/amdgpu: Don't skip display settings in hwmgr_resume()
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit 688f3d1ebedffa310b6591bd1b63fa0770d945fe upstream.
+
+I'm not entirely sure why this is, but for some reason:
+
+921935dc6404 ("drm/amd/powerplay: enforce display related settings only on needed")
+
+Breaks runtime PM resume on the Radeon PRO WX 3100 (Lexa) in one the
+pre-production laptops I have. The issue manifests as the following
+messages in dmesg:
+
+[drm] UVD and UVD ENC initialized successfully.
+amdgpu 0000:3b:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring vce1 test failed (-110)
+[drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <vce_v3_0> failed -110
+[drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed (-110).
+
+And happens after about 6-10 runtime PM suspend/resume cycles (sometimes
+sooner, if you're lucky!). Unfortunately I can't seem to pin down
+precisely which part in psm_adjust_power_state_dynamic that is causing
+the issue, but not skipping the display setting setup seems to fix it.
+Hopefully if there is a better fix for this, this patch will spark
+discussion around it.
+
+Fixes: 921935dc6404 ("drm/amd/powerplay: enforce display related settings only on needed")
+Cc: Evan Quan <evan.quan@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: Huang Rui <ray.huang@amd.com>
+Cc: Rex Zhu <Rex.Zhu@amd.com>
+Cc: Likun Gao <Likun.Gao@amd.com>
+Cc: <stable@vger.kernel.org> # v5.1+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
++++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+@@ -325,7 +325,7 @@ int hwmgr_resume(struct pp_hwmgr *hwmgr)
+ if (ret)
+ return ret;
+
+- ret = psm_adjust_power_state_dynamic(hwmgr, true, NULL);
++ ret = psm_adjust_power_state_dynamic(hwmgr, false, NULL);
+
+ return ret;
+ }
--- /dev/null
+From 25f09f858835b0e9a06213811031190a17d8ab78 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Mon, 1 Jul 2019 08:38:12 -0500
+Subject: drm/amdgpu/gfx9: use reset default for PA_SC_FIFO_SIZE
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 25f09f858835b0e9a06213811031190a17d8ab78 upstream.
+
+Recommended by the hw team.
+
+Reviewed-and-Tested-by: Huang Rui <ray.huang@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/gfx_v9_0.c | 19 -------------------
+ 1 file changed, 19 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+@@ -1899,25 +1899,6 @@ static void gfx_v9_0_constants_init(stru
+ mutex_unlock(&adev->srbm_mutex);
+
+ gfx_v9_0_init_compute_vmid(adev);
+-
+- mutex_lock(&adev->grbm_idx_mutex);
+- /*
+- * making sure that the following register writes will be broadcasted
+- * to all the shaders
+- */
+- gfx_v9_0_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
+-
+- WREG32_SOC15(GC, 0, mmPA_SC_FIFO_SIZE,
+- (adev->gfx.config.sc_prim_fifo_size_frontend <<
+- PA_SC_FIFO_SIZE__SC_FRONTEND_PRIM_FIFO_SIZE__SHIFT) |
+- (adev->gfx.config.sc_prim_fifo_size_backend <<
+- PA_SC_FIFO_SIZE__SC_BACKEND_PRIM_FIFO_SIZE__SHIFT) |
+- (adev->gfx.config.sc_hiz_tile_fifo_size <<
+- PA_SC_FIFO_SIZE__SC_HIZ_TILE_FIFO_SIZE__SHIFT) |
+- (adev->gfx.config.sc_earlyz_tile_fifo_size <<
+- PA_SC_FIFO_SIZE__SC_EARLYZ_TILE_FIFO_SIZE__SHIFT));
+- mutex_unlock(&adev->grbm_idx_mutex);
+-
+ }
+
+ static void gfx_v9_0_wait_for_rlc_serdes(struct amdgpu_device *adev)
--- /dev/null
+From be132e1375c1fffe48801296279079f8a59a9ed3 Mon Sep 17 00:00:00 2001
+From: Lucas Stach <l.stach@pengutronix.de>
+Date: Thu, 27 Jun 2019 16:42:00 +0200
+Subject: drm/etnaviv: add missing failure path to destroy suballoc
+
+From: Lucas Stach <l.stach@pengutronix.de>
+
+commit be132e1375c1fffe48801296279079f8a59a9ed3 upstream.
+
+When something goes wrong in the GPU init after the cmdbuf suballocator
+has been constructed, we fail to destroy it properly. This causes havok
+later when the GPU is unbound due to a module unload or similar.
+
+Fixes: e66774dd6f6a (drm/etnaviv: add cmdbuf suballocator)
+Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
+Tested-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
++++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+@@ -762,7 +762,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu
+ if (IS_ERR(gpu->cmdbuf_suballoc)) {
+ dev_err(gpu->dev, "Failed to create cmdbuf suballocator\n");
+ ret = PTR_ERR(gpu->cmdbuf_suballoc);
+- goto fail;
++ goto destroy_iommu;
+ }
+
+ /* Create buffer: */
+@@ -770,7 +770,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu
+ PAGE_SIZE);
+ if (ret) {
+ dev_err(gpu->dev, "could not create command buffer\n");
+- goto destroy_iommu;
++ goto destroy_suballoc;
+ }
+
+ if (gpu->mmu->version == ETNAVIV_IOMMU_V1 &&
+@@ -802,6 +802,9 @@ int etnaviv_gpu_init(struct etnaviv_gpu
+ free_buffer:
+ etnaviv_cmdbuf_free(&gpu->buffer);
+ gpu->buffer.suballoc = NULL;
++destroy_suballoc:
++ etnaviv_cmdbuf_suballoc_destroy(gpu->cmdbuf_suballoc);
++ gpu->cmdbuf_suballoc = NULL;
+ destroy_iommu:
+ etnaviv_iommu_destroy(gpu->mmu);
+ gpu->mmu = NULL;
--- /dev/null
+From c84c9029d782a3a0d2a7f0522ecb907314d43e2c Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Fri, 19 Apr 2019 12:17:47 +0100
+Subject: drm/i915/ringbuffer: EMIT_INVALIDATE *before* switch context
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit c84c9029d782a3a0d2a7f0522ecb907314d43e2c upstream.
+
+Despite what I think the prm recommends, commit f2253bd9859b
+("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
+to be a huge mistake when enabling Ironlake contexts as the GPU would
+hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
+MI_SET_CONTEXT of an active mesa context (more vanilla contexts, e.g.
+simple rendercopies with igt, do not suffer).
+
+Ville found the following clue,
+
+ "[DevCTG+]: For the invalidate operation of the pipe control, the
+ following pointers are affected. The
+ invalidate operation affects the restore of these packets. If the pipe
+ control invalidate operation is completed
+ before the context save, the indirect pointers will not be restored from
+ memory.
+ 1. Pipeline State Pointer
+ 2. Media State Pointer
+ 3. Constant Buffer Packet"
+
+which suggests by us emitting the INVALIDATE prior to the MI_SET_CONTEXT,
+we prevent the context-restore from chasing the dangling pointers within
+the image, and explains why this likely prevents the GPU hang.
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190419111749.3910-1-chris@chris-wilson.co.uk
+(cherry picked from commit 928f8f42310f244501a7c70daac82c196112c190 in drm-intel-next)
+Cc: stable@vger.kernel.org
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111014
+Fixes: f2253bd9859b ("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context")
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
++++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
+@@ -1957,12 +1957,12 @@ static int ring_request_alloc(struct i91
+ */
+ request->reserved_space += LEGACY_REQUEST_SIZE;
+
+- ret = switch_context(request);
++ /* Unconditionally invalidate GPU caches and TLBs. */
++ ret = request->engine->emit_flush(request, EMIT_INVALIDATE);
+ if (ret)
+ return ret;
+
+- /* Unconditionally invalidate GPU caches and TLBs. */
+- ret = request->engine->emit_flush(request, EMIT_INVALIDATE);
++ ret = switch_context(request);
+ if (ret)
+ return ret;
+
--- /dev/null
+From 78c68e8f5cd24bd32ba4ca1cdfb0c30cf0642685 Mon Sep 17 00:00:00 2001
+From: Robert Beckett <bob.beckett@collabora.com>
+Date: Tue, 25 Jun 2019 18:59:13 +0100
+Subject: drm/imx: notify drm core before sending event during crtc disable
+
+From: Robert Beckett <bob.beckett@collabora.com>
+
+commit 78c68e8f5cd24bd32ba4ca1cdfb0c30cf0642685 upstream.
+
+Notify drm core before sending pending events during crtc disable.
+This fixes the first event after disable having an old stale timestamp
+by having drm_crtc_vblank_off update the timestamp to now.
+
+This was seen while debugging weston log message:
+Warning: computed repaint delay is insane: -8212 msec
+
+This occurred due to:
+1. driver starts up
+2. fbcon comes along and restores fbdev, enabling vblank
+3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
+seq number and time set at current value
+(some time later)
+4. weston starts and does a modeset
+5. atomic commit disables crtc while it does the modeset
+6. ipu_crtc_atomic_disable sends vblank with old seq number and time
+
+Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")
+
+Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/imx/ipuv3-crtc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
++++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
+@@ -91,14 +91,14 @@ static void ipu_crtc_atomic_disable(stru
+ ipu_dc_disable(ipu);
+ ipu_prg_disable(ipu);
+
++ drm_crtc_vblank_off(crtc);
++
+ spin_lock_irq(&crtc->dev->event_lock);
+ if (crtc->state->event) {
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ crtc->state->event = NULL;
+ }
+ spin_unlock_irq(&crtc->dev->event_lock);
+-
+- drm_crtc_vblank_off(crtc);
+ }
+
+ static void imx_drm_crtc_reset(struct drm_crtc *crtc)
--- /dev/null
+From 5aeab2bfc9ffa72d3ca73416635cb3785dfc076f Mon Sep 17 00:00:00 2001
+From: Robert Beckett <bob.beckett@collabora.com>
+Date: Tue, 25 Jun 2019 18:59:15 +0100
+Subject: drm/imx: only send event on crtc disable if kept disabled
+
+From: Robert Beckett <bob.beckett@collabora.com>
+
+commit 5aeab2bfc9ffa72d3ca73416635cb3785dfc076f upstream.
+
+The event will be sent as part of the vblank enable during the modeset
+if the crtc is not being kept disabled.
+
+Fixes: 5f2f911578fb ("drm/imx: atomic phase 3 step 1: Use atomic configuration")
+
+Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
++++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
+@@ -94,7 +94,7 @@ static void ipu_crtc_atomic_disable(stru
+ drm_crtc_vblank_off(crtc);
+
+ spin_lock_irq(&crtc->dev->event_lock);
+- if (crtc->state->event) {
++ if (crtc->state->event && !crtc->state->active) {
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ crtc->state->event = NULL;
+ }
--- /dev/null
+From 41de4be6f6efa4132b29af51158cd672d93f2543 Mon Sep 17 00:00:00 2001
+From: Gerd Hoffmann <kraxel@redhat.com>
+Date: Fri, 5 Apr 2019 06:46:02 +0200
+Subject: drm/virtio: move drm_connector_update_edid_property() call
+
+From: Gerd Hoffmann <kraxel@redhat.com>
+
+commit 41de4be6f6efa4132b29af51158cd672d93f2543 upstream.
+
+drm_connector_update_edid_property can sleep, we must not
+call it while holding a spinlock. Move the callsite.
+
+Fixes: b4b01b4995fb ("drm/virtio: add edid support")
+Reported-by: Max Filippov <jcmvbkbc@gmail.com>
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Tested-by: Max Filippov <jcmvbkbc@gmail.com>
+Tested-by: Cornelia Huck <cohuck@redhat.com>
+Acked-by: Cornelia Huck <cohuck@redhat.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/20190405044602.2334-1-kraxel@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
++++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
+@@ -620,11 +620,11 @@ static void virtio_gpu_cmd_get_edid_cb(s
+ output = vgdev->outputs + scanout;
+
+ new_edid = drm_do_get_edid(&output->conn, virtio_get_edid_block, resp);
++ drm_connector_update_edid_property(&output->conn, new_edid);
+
+ spin_lock(&vgdev->display_info_lock);
+ old_edid = output->edid;
+ output->edid = new_edid;
+- drm_connector_update_edid_property(&output->conn, output->edid);
+ spin_unlock(&vgdev->display_info_lock);
+
+ kfree(old_edid);
--- /dev/null
+From cbcfa130a911c613a1d9d921af2eea171c414172 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Thu, 4 Jul 2019 15:14:39 -0700
+Subject: fs/userfaultfd.c: disable irqs for fault_pending and event locks
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit cbcfa130a911c613a1d9d921af2eea171c414172 upstream.
+
+When IOCB_CMD_POLL is used on a userfaultfd, aio_poll() disables IRQs
+and takes kioctx::ctx_lock, then userfaultfd_ctx::fd_wqh.lock.
+
+This may have to wait for userfaultfd_ctx::fd_wqh.lock to be released by
+userfaultfd_ctx_read(), which in turn can be waiting for
+userfaultfd_ctx::fault_pending_wqh.lock or
+userfaultfd_ctx::event_wqh.lock.
+
+But elsewhere the fault_pending_wqh and event_wqh locks are taken with
+IRQs enabled. Since the IRQ handler may take kioctx::ctx_lock, lockdep
+reports that a deadlock is possible.
+
+Fix it by always disabling IRQs when taking the fault_pending_wqh and
+event_wqh locks.
+
+Commit ae62c16e105a ("userfaultfd: disable irqs when taking the
+waitqueue lock") didn't fix this because it only accounted for the
+fd_wqh lock, not the other locks nested inside it.
+
+Link: http://lkml.kernel.org/r/20190627075004.21259-1-ebiggers@kernel.org
+Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Reported-by: syzbot+fab6de82892b6b9c6191@syzkaller.appspotmail.com
+Reported-by: syzbot+53c0b767f7ca0dc0c451@syzkaller.appspotmail.com
+Reported-by: syzbot+a3accb352f9c22041cfa@syzkaller.appspotmail.com
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: <stable@vger.kernel.org> [4.19+]
+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/userfaultfd.c | 42 ++++++++++++++++++++++++++----------------
+ 1 file changed, 26 insertions(+), 16 deletions(-)
+
+--- a/fs/userfaultfd.c
++++ b/fs/userfaultfd.c
+@@ -40,6 +40,16 @@ enum userfaultfd_state {
+ /*
+ * Start with fault_pending_wqh and fault_wqh so they're more likely
+ * to be in the same cacheline.
++ *
++ * Locking order:
++ * fd_wqh.lock
++ * fault_pending_wqh.lock
++ * fault_wqh.lock
++ * event_wqh.lock
++ *
++ * To avoid deadlocks, IRQs must be disabled when taking any of the above locks,
++ * since fd_wqh.lock is taken by aio_poll() while it's holding a lock that's
++ * also taken in IRQ context.
+ */
+ struct userfaultfd_ctx {
+ /* waitqueue head for the pending (i.e. not read) userfaults */
+@@ -458,7 +468,7 @@ vm_fault_t handle_userfault(struct vm_fa
+ blocking_state = return_to_userland ? TASK_INTERRUPTIBLE :
+ TASK_KILLABLE;
+
+- spin_lock(&ctx->fault_pending_wqh.lock);
++ spin_lock_irq(&ctx->fault_pending_wqh.lock);
+ /*
+ * After the __add_wait_queue the uwq is visible to userland
+ * through poll/read().
+@@ -470,7 +480,7 @@ vm_fault_t handle_userfault(struct vm_fa
+ * __add_wait_queue.
+ */
+ set_current_state(blocking_state);
+- spin_unlock(&ctx->fault_pending_wqh.lock);
++ spin_unlock_irq(&ctx->fault_pending_wqh.lock);
+
+ if (!is_vm_hugetlb_page(vmf->vma))
+ must_wait = userfaultfd_must_wait(ctx, vmf->address, vmf->flags,
+@@ -552,13 +562,13 @@ vm_fault_t handle_userfault(struct vm_fa
+ * kernel stack can be released after the list_del_init.
+ */
+ if (!list_empty_careful(&uwq.wq.entry)) {
+- spin_lock(&ctx->fault_pending_wqh.lock);
++ spin_lock_irq(&ctx->fault_pending_wqh.lock);
+ /*
+ * No need of list_del_init(), the uwq on the stack
+ * will be freed shortly anyway.
+ */
+ list_del(&uwq.wq.entry);
+- spin_unlock(&ctx->fault_pending_wqh.lock);
++ spin_unlock_irq(&ctx->fault_pending_wqh.lock);
+ }
+
+ /*
+@@ -583,7 +593,7 @@ static void userfaultfd_event_wait_compl
+ init_waitqueue_entry(&ewq->wq, current);
+ release_new_ctx = NULL;
+
+- spin_lock(&ctx->event_wqh.lock);
++ spin_lock_irq(&ctx->event_wqh.lock);
+ /*
+ * After the __add_wait_queue the uwq is visible to userland
+ * through poll/read().
+@@ -613,15 +623,15 @@ static void userfaultfd_event_wait_compl
+ break;
+ }
+
+- spin_unlock(&ctx->event_wqh.lock);
++ spin_unlock_irq(&ctx->event_wqh.lock);
+
+ wake_up_poll(&ctx->fd_wqh, EPOLLIN);
+ schedule();
+
+- spin_lock(&ctx->event_wqh.lock);
++ spin_lock_irq(&ctx->event_wqh.lock);
+ }
+ __set_current_state(TASK_RUNNING);
+- spin_unlock(&ctx->event_wqh.lock);
++ spin_unlock_irq(&ctx->event_wqh.lock);
+
+ if (release_new_ctx) {
+ struct vm_area_struct *vma;
+@@ -918,10 +928,10 @@ wakeup:
+ * the last page faults that may have been already waiting on
+ * the fault_*wqh.
+ */
+- spin_lock(&ctx->fault_pending_wqh.lock);
++ spin_lock_irq(&ctx->fault_pending_wqh.lock);
+ __wake_up_locked_key(&ctx->fault_pending_wqh, TASK_NORMAL, &range);
+ __wake_up(&ctx->fault_wqh, TASK_NORMAL, 1, &range);
+- spin_unlock(&ctx->fault_pending_wqh.lock);
++ spin_unlock_irq(&ctx->fault_pending_wqh.lock);
+
+ /* Flush pending events that may still wait on event_wqh */
+ wake_up_all(&ctx->event_wqh);
+@@ -1134,7 +1144,7 @@ static ssize_t userfaultfd_ctx_read(stru
+
+ if (!ret && msg->event == UFFD_EVENT_FORK) {
+ ret = resolve_userfault_fork(ctx, fork_nctx, msg);
+- spin_lock(&ctx->event_wqh.lock);
++ spin_lock_irq(&ctx->event_wqh.lock);
+ if (!list_empty(&fork_event)) {
+ /*
+ * The fork thread didn't abort, so we can
+@@ -1180,7 +1190,7 @@ static ssize_t userfaultfd_ctx_read(stru
+ if (ret)
+ userfaultfd_ctx_put(fork_nctx);
+ }
+- spin_unlock(&ctx->event_wqh.lock);
++ spin_unlock_irq(&ctx->event_wqh.lock);
+ }
+
+ return ret;
+@@ -1219,14 +1229,14 @@ static ssize_t userfaultfd_read(struct f
+ static void __wake_userfault(struct userfaultfd_ctx *ctx,
+ struct userfaultfd_wake_range *range)
+ {
+- spin_lock(&ctx->fault_pending_wqh.lock);
++ spin_lock_irq(&ctx->fault_pending_wqh.lock);
+ /* wake all in the range and autoremove */
+ if (waitqueue_active(&ctx->fault_pending_wqh))
+ __wake_up_locked_key(&ctx->fault_pending_wqh, TASK_NORMAL,
+ range);
+ if (waitqueue_active(&ctx->fault_wqh))
+ __wake_up(&ctx->fault_wqh, TASK_NORMAL, 1, range);
+- spin_unlock(&ctx->fault_pending_wqh.lock);
++ spin_unlock_irq(&ctx->fault_pending_wqh.lock);
+ }
+
+ static __always_inline void wake_userfault(struct userfaultfd_ctx *ctx,
+@@ -1881,7 +1891,7 @@ static void userfaultfd_show_fdinfo(stru
+ wait_queue_entry_t *wq;
+ unsigned long pending = 0, total = 0;
+
+- spin_lock(&ctx->fault_pending_wqh.lock);
++ spin_lock_irq(&ctx->fault_pending_wqh.lock);
+ list_for_each_entry(wq, &ctx->fault_pending_wqh.head, entry) {
+ pending++;
+ total++;
+@@ -1889,7 +1899,7 @@ static void userfaultfd_show_fdinfo(stru
+ list_for_each_entry(wq, &ctx->fault_wqh.head, entry) {
+ total++;
+ }
+- spin_unlock(&ctx->fault_pending_wqh.lock);
++ spin_unlock_irq(&ctx->fault_pending_wqh.lock);
+
+ /*
+ * If more protocols will be added, there will be all shown
--- /dev/null
+From d5b844a2cf507fc7642c9ae80a9d585db3065c28 Mon Sep 17 00:00:00 2001
+From: Petr Mladek <pmladek@suse.com>
+Date: Thu, 27 Jun 2019 10:13:34 +0200
+Subject: ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()
+
+From: Petr Mladek <pmladek@suse.com>
+
+commit d5b844a2cf507fc7642c9ae80a9d585db3065c28 upstream.
+
+The commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text
+permissions race") causes a possible deadlock between register_kprobe()
+and ftrace_run_update_code() when ftrace is using stop_machine().
+
+The existing dependency chain (in reverse order) is:
+
+-> #1 (text_mutex){+.+.}:
+ validate_chain.isra.21+0xb32/0xd70
+ __lock_acquire+0x4b8/0x928
+ lock_acquire+0x102/0x230
+ __mutex_lock+0x88/0x908
+ mutex_lock_nested+0x32/0x40
+ register_kprobe+0x254/0x658
+ init_kprobes+0x11a/0x168
+ do_one_initcall+0x70/0x318
+ kernel_init_freeable+0x456/0x508
+ kernel_init+0x22/0x150
+ ret_from_fork+0x30/0x34
+ kernel_thread_starter+0x0/0xc
+
+-> #0 (cpu_hotplug_lock.rw_sem){++++}:
+ check_prev_add+0x90c/0xde0
+ validate_chain.isra.21+0xb32/0xd70
+ __lock_acquire+0x4b8/0x928
+ lock_acquire+0x102/0x230
+ cpus_read_lock+0x62/0xd0
+ stop_machine+0x2e/0x60
+ arch_ftrace_update_code+0x2e/0x40
+ ftrace_run_update_code+0x40/0xa0
+ ftrace_startup+0xb2/0x168
+ register_ftrace_function+0x64/0x88
+ klp_patch_object+0x1a2/0x290
+ klp_enable_patch+0x554/0x980
+ do_one_initcall+0x70/0x318
+ do_init_module+0x6e/0x250
+ load_module+0x1782/0x1990
+ __s390x_sys_finit_module+0xaa/0xf0
+ system_call+0xd8/0x2d0
+
+ Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(text_mutex);
+ lock(cpu_hotplug_lock.rw_sem);
+ lock(text_mutex);
+ lock(cpu_hotplug_lock.rw_sem);
+
+It is similar problem that has been solved by the commit 2d1e38f56622b9b
+("kprobes: Cure hotplug lock ordering issues"). Many locks are involved.
+To be on the safe side, text_mutex must become a low level lock taken
+after cpu_hotplug_lock.rw_sem.
+
+This can't be achieved easily with the current ftrace design.
+For example, arm calls set_all_modules_text_rw() already in
+ftrace_arch_code_modify_prepare(), see arch/arm/kernel/ftrace.c.
+This functions is called:
+
+ + outside stop_machine() from ftrace_run_update_code()
+ + without stop_machine() from ftrace_module_enable()
+
+Fortunately, the problematic fix is needed only on x86_64. It is
+the only architecture that calls set_all_modules_text_rw()
+in ftrace path and supports livepatching at the same time.
+
+Therefore it is enough to move text_mutex handling from the generic
+kernel/trace/ftrace.c into arch/x86/kernel/ftrace.c:
+
+ ftrace_arch_code_modify_prepare()
+ ftrace_arch_code_modify_post_process()
+
+This patch basically reverts the ftrace part of the problematic
+commit 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module
+text permissions race"). And provides x86_64 specific-fix.
+
+Some refactoring of the ftrace code will be needed when livepatching
+is implemented for arm or nds32. These architectures call
+set_all_modules_text_rw() and use stop_machine() at the same time.
+
+Link: http://lkml.kernel.org/r/20190627081334.12793-1-pmladek@suse.com
+
+Fixes: 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text permissions race")
+Acked-by: Thomas Gleixner <tglx@linutronix.de>
+Reported-by: Miroslav Benes <mbenes@suse.cz>
+Reviewed-by: Miroslav Benes <mbenes@suse.cz>
+Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
+Signed-off-by: Petr Mladek <pmladek@suse.com>
+[
+ As reviewed by Miroslav Benes <mbenes@suse.cz>, removed return value of
+ ftrace_run_update_code() as it is a void function.
+]
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/ftrace.c | 3 +++
+ kernel/trace/ftrace.c | 10 +---------
+ 2 files changed, 4 insertions(+), 9 deletions(-)
+
+--- a/arch/x86/kernel/ftrace.c
++++ b/arch/x86/kernel/ftrace.c
+@@ -22,6 +22,7 @@
+ #include <linux/init.h>
+ #include <linux/list.h>
+ #include <linux/module.h>
++#include <linux/memory.h>
+
+ #include <trace/syscall.h>
+
+@@ -35,6 +36,7 @@
+
+ int ftrace_arch_code_modify_prepare(void)
+ {
++ mutex_lock(&text_mutex);
+ set_kernel_text_rw();
+ set_all_modules_text_rw();
+ return 0;
+@@ -44,6 +46,7 @@ int ftrace_arch_code_modify_post_process
+ {
+ set_all_modules_text_ro();
+ set_kernel_text_ro();
++ mutex_unlock(&text_mutex);
+ return 0;
+ }
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -34,7 +34,6 @@
+ #include <linux/hash.h>
+ #include <linux/rcupdate.h>
+ #include <linux/kprobes.h>
+-#include <linux/memory.h>
+
+ #include <trace/events/sched.h>
+
+@@ -2615,12 +2614,10 @@ static void ftrace_run_update_code(int c
+ {
+ int ret;
+
+- mutex_lock(&text_mutex);
+-
+ ret = ftrace_arch_code_modify_prepare();
+ FTRACE_WARN_ON(ret);
+ if (ret)
+- goto out_unlock;
++ return;
+
+ /*
+ * By default we use stop_machine() to modify the code.
+@@ -2632,9 +2629,6 @@ static void ftrace_run_update_code(int c
+
+ ret = ftrace_arch_code_modify_post_process();
+ FTRACE_WARN_ON(ret);
+-
+-out_unlock:
+- mutex_unlock(&text_mutex);
+ }
+
+ static void ftrace_run_modify_code(struct ftrace_ops *ops, int command,
+@@ -5788,7 +5782,6 @@ void ftrace_module_enable(struct module
+ struct ftrace_page *pg;
+
+ mutex_lock(&ftrace_lock);
+- mutex_lock(&text_mutex);
+
+ if (ftrace_disabled)
+ goto out_unlock;
+@@ -5850,7 +5843,6 @@ void ftrace_module_enable(struct module
+ ftrace_arch_code_modify_post_process();
+
+ out_unlock:
+- mutex_unlock(&text_mutex);
+ mutex_unlock(&ftrace_lock);
+
+ process_cached_mods(mod->name);
--- /dev/null
+From c8ea9fce2baf7b643384f36f29e4194fa40d33a6 Mon Sep 17 00:00:00 2001
+From: Herbert Xu <herbert@gondor.apana.org.au>
+Date: Mon, 24 Jun 2019 18:32:26 +0800
+Subject: lib/mpi: Fix karactx leak in mpi_powm
+
+From: Herbert Xu <herbert@gondor.apana.org.au>
+
+commit c8ea9fce2baf7b643384f36f29e4194fa40d33a6 upstream.
+
+Sometimes mpi_powm will leak karactx because a memory allocation
+failure causes a bail-out that skips the freeing of karactx. This
+patch moves the freeing of karactx to the end of the function like
+everything else so that it can't be skipped.
+
+Reported-by: syzbot+f7baccc38dcc1e094e77@syzkaller.appspotmail.com
+Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files...")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Reviewed-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ lib/mpi/mpi-pow.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/lib/mpi/mpi-pow.c
++++ b/lib/mpi/mpi-pow.c
+@@ -37,6 +37,7 @@
+ int mpi_powm(MPI res, MPI base, MPI exp, MPI mod)
+ {
+ mpi_ptr_t mp_marker = NULL, bp_marker = NULL, ep_marker = NULL;
++ struct karatsuba_ctx karactx = {};
+ mpi_ptr_t xp_marker = NULL;
+ mpi_ptr_t tspace = NULL;
+ mpi_ptr_t rp, ep, mp, bp;
+@@ -163,13 +164,11 @@ int mpi_powm(MPI res, MPI base, MPI exp,
+ int c;
+ mpi_limb_t e;
+ mpi_limb_t carry_limb;
+- struct karatsuba_ctx karactx;
+
+ xp = xp_marker = mpi_alloc_limb_space(2 * (msize + 1));
+ if (!xp)
+ goto enomem;
+
+- memset(&karactx, 0, sizeof karactx);
+ negative_result = (ep[0] & 1) && base->sign;
+
+ i = esize - 1;
+@@ -294,8 +293,6 @@ int mpi_powm(MPI res, MPI base, MPI exp,
+ if (mod_shift_cnt)
+ mpihelp_rshift(rp, rp, rsize, mod_shift_cnt);
+ MPN_NORMALIZE(rp, rsize);
+-
+- mpihelp_release_karatsuba_ctx(&karactx);
+ }
+
+ if (negative_result && rsize) {
+@@ -312,6 +309,7 @@ int mpi_powm(MPI res, MPI base, MPI exp,
+ leave:
+ rc = 0;
+ enomem:
++ mpihelp_release_karatsuba_ctx(&karactx);
+ if (assign_rp)
+ mpi_assign_limb_space(res, rp, size);
+ if (mp_marker)
--- /dev/null
+From dffcac2cb88e4ec5906235d64a83d802580b119e Mon Sep 17 00:00:00 2001
+From: Shakeel Butt <shakeelb@google.com>
+Date: Thu, 4 Jul 2019 15:14:42 -0700
+Subject: mm/vmscan.c: prevent useless kswapd loops
+
+From: Shakeel Butt <shakeelb@google.com>
+
+commit dffcac2cb88e4ec5906235d64a83d802580b119e upstream.
+
+In production we have noticed hard lockups on large machines running
+large jobs due to kswaps hoarding lru lock within isolate_lru_pages when
+sc->reclaim_idx is 0 which is a small zone. The lru was couple hundred
+GiBs and the condition (page_zonenum(page) > sc->reclaim_idx) in
+isolate_lru_pages() was basically skipping GiBs of pages while holding
+the LRU spinlock with interrupt disabled.
+
+On further inspection, it seems like there are two issues:
+
+(1) If kswapd on the return from balance_pgdat() could not sleep (i.e.
+ node is still unbalanced), the classzone_idx is unintentionally set
+ to 0 and the whole reclaim cycle of kswapd will try to reclaim only
+ the lowest and smallest zone while traversing the whole memory.
+
+(2) Fundamentally isolate_lru_pages() is really bad when the
+ allocation has woken kswapd for a smaller zone on a very large machine
+ running very large jobs. It can hoard the LRU spinlock while skipping
+ over 100s of GiBs of pages.
+
+This patch only fixes (1). (2) needs a more fundamental solution. To
+fix (1), in the kswapd context, if pgdat->kswapd_classzone_idx is
+invalid use the classzone_idx of the previous kswapd loop otherwise use
+the one the waker has requested.
+
+Link: http://lkml.kernel.org/r/20190701201847.251028-1-shakeelb@google.com
+Fixes: e716f2eb24de ("mm, vmscan: prevent kswapd sleeping prematurely due to mismatched classzone_idx")
+Signed-off-by: Shakeel Butt <shakeelb@google.com>
+Reviewed-by: Yang Shi <yang.shi@linux.alibaba.com>
+Acked-by: Mel Gorman <mgorman@techsingularity.net>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Hillf Danton <hdanton@sina.com>
+Cc: Roman Gushchin <guro@fb.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/vmscan.c | 27 +++++++++++++++------------
+ 1 file changed, 15 insertions(+), 12 deletions(-)
+
+--- a/mm/vmscan.c
++++ b/mm/vmscan.c
+@@ -3703,19 +3703,18 @@ out:
+ }
+
+ /*
+- * pgdat->kswapd_classzone_idx is the highest zone index that a recent
+- * allocation request woke kswapd for. When kswapd has not woken recently,
+- * the value is MAX_NR_ZONES which is not a valid index. This compares a
+- * given classzone and returns it or the highest classzone index kswapd
+- * was recently woke for.
++ * The pgdat->kswapd_classzone_idx is used to pass the highest zone index to be
++ * reclaimed by kswapd from the waker. If the value is MAX_NR_ZONES which is not
++ * a valid index then either kswapd runs for first time or kswapd couldn't sleep
++ * after previous reclaim attempt (node is still unbalanced). In that case
++ * return the zone index of the previous kswapd reclaim cycle.
+ */
+ static enum zone_type kswapd_classzone_idx(pg_data_t *pgdat,
+- enum zone_type classzone_idx)
++ enum zone_type prev_classzone_idx)
+ {
+ if (pgdat->kswapd_classzone_idx == MAX_NR_ZONES)
+- return classzone_idx;
+-
+- return max(pgdat->kswapd_classzone_idx, classzone_idx);
++ return prev_classzone_idx;
++ return pgdat->kswapd_classzone_idx;
+ }
+
+ static void kswapd_try_to_sleep(pg_data_t *pgdat, int alloc_order, int reclaim_order,
+@@ -3856,7 +3855,7 @@ kswapd_try_sleep:
+
+ /* Read the new order and classzone_idx */
+ alloc_order = reclaim_order = pgdat->kswapd_order;
+- classzone_idx = kswapd_classzone_idx(pgdat, 0);
++ classzone_idx = kswapd_classzone_idx(pgdat, classzone_idx);
+ pgdat->kswapd_order = 0;
+ pgdat->kswapd_classzone_idx = MAX_NR_ZONES;
+
+@@ -3910,8 +3909,12 @@ void wakeup_kswapd(struct zone *zone, gf
+ if (!cpuset_zone_allowed(zone, gfp_flags))
+ return;
+ pgdat = zone->zone_pgdat;
+- pgdat->kswapd_classzone_idx = kswapd_classzone_idx(pgdat,
+- classzone_idx);
++
++ if (pgdat->kswapd_classzone_idx == MAX_NR_ZONES)
++ pgdat->kswapd_classzone_idx = classzone_idx;
++ else
++ pgdat->kswapd_classzone_idx = max(pgdat->kswapd_classzone_idx,
++ classzone_idx);
+ pgdat->kswapd_order = max(pgdat->kswapd_order, order);
+ if (!waitqueue_active(&pgdat->kswapd_wait))
+ return;
--- /dev/null
+From 6994eefb0053799d2e07cd140df6c2ea106c41ee Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Thu, 4 Jul 2019 17:32:23 +0200
+Subject: ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME
+
+From: Jann Horn <jannh@google.com>
+
+commit 6994eefb0053799d2e07cd140df6c2ea106c41ee upstream.
+
+Fix two issues:
+
+When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU
+reference to the parent's objective credentials, then give that pointer
+to get_cred(). However, the object lifetime rules for things like
+struct cred do not permit unconditionally turning an RCU reference into
+a stable reference.
+
+PTRACE_TRACEME records the parent's credentials as if the parent was
+acting as the subject, but that's not the case. If a malicious
+unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
+at a later point, the parent process becomes attacker-controlled
+(because it drops privileges and calls execve()), the attacker ends up
+with control over two processes with a privileged ptrace relationship,
+which can be abused to ptrace a suid binary and obtain root privileges.
+
+Fix both of these by always recording the credentials of the process
+that is requesting the creation of the ptrace relationship:
+current_cred() can't change under us, and current is the proper subject
+for access control.
+
+This change is theoretically userspace-visible, but I am not aware of
+any code that it will actually break.
+
+Fixes: 64b875f7ac8a ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
+Signed-off-by: Jann Horn <jannh@google.com>
+Acked-by: Oleg Nesterov <oleg@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/ptrace.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/kernel/ptrace.c
++++ b/kernel/ptrace.c
+@@ -78,9 +78,7 @@ void __ptrace_link(struct task_struct *c
+ */
+ static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)
+ {
+- rcu_read_lock();
+- __ptrace_link(child, new_parent, __task_cred(new_parent));
+- rcu_read_unlock();
++ __ptrace_link(child, new_parent, current_cred());
+ }
+
+ /**
tracing-avoid-build-warning-with-have_nop_mcount.patch
module-fix-livepatch-ftrace-module-text-permissions-.patch
ftrace-fix-null-pointer-dereference-in-free_ftrace_f.patch
+ptrace-fix-ptracer_cred-handling-for-ptrace_traceme.patch
+crypto-user-prevent-operating-on-larval-algorithms.patch
+crypto-cryptd-fix-skcipher-instance-memory-leak.patch
+alsa-seq-fix-incorrect-order-of-dest_client-dest_ports-arguments.patch
+alsa-firewire-lib-fireworks-fix-miss-detection-of-received-midi-messages.patch
+alsa-line6-fix-write-on-zero-sized-buffer.patch
+alsa-usb-audio-fix-sign-unintended-sign-extension-on-left-shifts.patch
+alsa-hda-realtek-add-quirks-for-several-clevo-notebook-barebones.patch
+alsa-hda-realtek-change-front-mic-location-for-lenovo-m710q.patch
+dax-fix-xarray-entry-association-for-mixed-mappings.patch
+lib-mpi-fix-karactx-leak-in-mpi_powm.patch
+fs-userfaultfd.c-disable-irqs-for-fault_pending-and-event-locks.patch
+swap_readpage-avoid-blk_wake_io_task-if-synchronous.patch
+tracing-snapshot-resize-spare-buffer-if-size-changed.patch
+arm-dts-armada-xp-98dx3236-switch-to-armada-38x-uart-serial-node.patch
+arm64-kaslr-keep-modules-inside-module-region-when-kasan-is-enabled.patch
+drm-i915-ringbuffer-emit_invalidate-before-switch-context.patch
+drm-amd-powerplay-use-hardware-fan-control-if-no-powerplay-fan-table.patch
+drm-amdgpu-don-t-skip-display-settings-in-hwmgr_resume.patch
+drm-amdgpu-gfx9-use-reset-default-for-pa_sc_fifo_size.patch
+drm-virtio-move-drm_connector_update_edid_property-call.patch
+drm-etnaviv-add-missing-failure-path-to-destroy-suballoc.patch
+drm-imx-notify-drm-core-before-sending-event-during-crtc-disable.patch
+drm-imx-only-send-event-on-crtc-disable-if-kept-disabled.patch
+ftrace-x86-remove-possible-deadlock-between-register_kprobe-and-ftrace_run_update_code.patch
+mm-vmscan.c-prevent-useless-kswapd-loops.patch
--- /dev/null
+From 8751853091998cd31e9e5f1e8206280155af8921 Mon Sep 17 00:00:00 2001
+From: Oleg Nesterov <oleg@redhat.com>
+Date: Thu, 4 Jul 2019 15:14:49 -0700
+Subject: swap_readpage(): avoid blk_wake_io_task() if !synchronous
+
+From: Oleg Nesterov <oleg@redhat.com>
+
+commit 8751853091998cd31e9e5f1e8206280155af8921 upstream.
+
+swap_readpage() sets waiter = bio->bi_private even if synchronous = F,
+this means that the caller can get the spurious wakeup after return.
+
+This can be fatal if blk_wake_io_task() does
+set_current_state(TASK_RUNNING) after the caller does
+set_special_state(), in the worst case the kernel can crash in
+do_task_dead().
+
+Link: http://lkml.kernel.org/r/20190704160301.GA5956@redhat.com
+Fixes: 0619317ff8baa2d ("block: add polled wakeup task helper")
+Signed-off-by: Oleg Nesterov <oleg@redhat.com>
+Reported-by: Qian Cai <cai@lca.pw>
+Acked-by: Hugh Dickins <hughd@google.com>
+Reviewed-by: Jens Axboe <axboe@kernel.dk>
+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>
+
+---
+ mm/page_io.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/mm/page_io.c
++++ b/mm/page_io.c
+@@ -137,8 +137,10 @@ out:
+ unlock_page(page);
+ WRITE_ONCE(bio->bi_private, NULL);
+ bio_put(bio);
+- blk_wake_io_task(waiter);
+- put_task_struct(waiter);
++ if (waiter) {
++ blk_wake_io_task(waiter);
++ put_task_struct(waiter);
++ }
+ }
+
+ int generic_swapfile_activate(struct swap_info_struct *sis,
+@@ -395,11 +397,12 @@ int swap_readpage(struct page *page, boo
+ * Keep this task valid during swap readpage because the oom killer may
+ * attempt to access it in the page fault retry time check.
+ */
+- get_task_struct(current);
+- bio->bi_private = current;
+ bio_set_op_attrs(bio, REQ_OP_READ, 0);
+- if (synchronous)
++ if (synchronous) {
+ bio->bi_opf |= REQ_HIPRI;
++ get_task_struct(current);
++ bio->bi_private = current;
++ }
+ count_vm_event(PSWPIN);
+ bio_get(bio);
+ qc = submit_bio(bio);
--- /dev/null
+From 46cc0b44428d0f0e81f11ea98217fc0edfbeab07 Mon Sep 17 00:00:00 2001
+From: Eiichi Tsukata <devel@etsukata.com>
+Date: Tue, 25 Jun 2019 10:29:10 +0900
+Subject: tracing/snapshot: Resize spare buffer if size changed
+
+From: Eiichi Tsukata <devel@etsukata.com>
+
+commit 46cc0b44428d0f0e81f11ea98217fc0edfbeab07 upstream.
+
+Current snapshot implementation swaps two ring_buffers even though their
+sizes are different from each other, that can cause an inconsistency
+between the contents of buffer_size_kb file and the current buffer size.
+
+For example:
+
+ # cat buffer_size_kb
+ 7 (expanded: 1408)
+ # echo 1 > events/enable
+ # grep bytes per_cpu/cpu0/stats
+ bytes: 1441020
+ # echo 1 > snapshot // current:1408, spare:1408
+ # echo 123 > buffer_size_kb // current:123, spare:1408
+ # echo 1 > snapshot // current:1408, spare:123
+ # grep bytes per_cpu/cpu0/stats
+ bytes: 1443700
+ # cat buffer_size_kb
+ 123 // != current:1408
+
+And also, a similar per-cpu case hits the following WARNING:
+
+Reproducer:
+
+ # echo 1 > per_cpu/cpu0/snapshot
+ # echo 123 > buffer_size_kb
+ # echo 1 > per_cpu/cpu0/snapshot
+
+WARNING:
+
+ WARNING: CPU: 0 PID: 1946 at kernel/trace/trace.c:1607 update_max_tr_single.part.0+0x2b8/0x380
+ Modules linked in:
+ CPU: 0 PID: 1946 Comm: bash Not tainted 5.2.0-rc6 #20
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014
+ RIP: 0010:update_max_tr_single.part.0+0x2b8/0x380
+ Code: ff e8 dc da f9 ff 0f 0b e9 88 fe ff ff e8 d0 da f9 ff 44 89 ee bf f5 ff ff ff e8 33 dc f9 ff 41 83 fd f5 74 96 e8 b8 da f9 ff <0f> 0b eb 8d e8 af da f9 ff 0f 0b e9 bf fd ff ff e8 a3 da f9 ff 48
+ RSP: 0018:ffff888063e4fca0 EFLAGS: 00010093
+ RAX: ffff888066214380 RBX: ffffffff99850fe0 RCX: ffffffff964298a8
+ RDX: 0000000000000000 RSI: 00000000fffffff5 RDI: 0000000000000005
+ RBP: 1ffff1100c7c9f96 R08: ffff888066214380 R09: ffffed100c7c9f9b
+ R10: ffffed100c7c9f9a R11: 0000000000000003 R12: 0000000000000000
+ R13: 00000000ffffffea R14: ffff888066214380 R15: ffffffff99851060
+ FS: 00007f9f8173c700(0000) GS:ffff88806d000000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000714dc0 CR3: 0000000066fa6000 CR4: 00000000000006f0
+ Call Trace:
+ ? trace_array_printk_buf+0x140/0x140
+ ? __mutex_lock_slowpath+0x10/0x10
+ tracing_snapshot_write+0x4c8/0x7f0
+ ? trace_printk_init_buffers+0x60/0x60
+ ? selinux_file_permission+0x3b/0x540
+ ? tracer_preempt_off+0x38/0x506
+ ? trace_printk_init_buffers+0x60/0x60
+ __vfs_write+0x81/0x100
+ vfs_write+0x1e1/0x560
+ ksys_write+0x126/0x250
+ ? __ia32_sys_read+0xb0/0xb0
+ ? do_syscall_64+0x1f/0x390
+ do_syscall_64+0xc1/0x390
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+This patch adds resize_buffer_duplicate_size() to check if there is a
+difference between current/spare buffer sizes and resize a spare buffer
+if necessary.
+
+Link: http://lkml.kernel.org/r/20190625012910.13109-1-devel@etsukata.com
+
+Cc: stable@vger.kernel.org
+Fixes: ad909e21bbe69 ("tracing: Add internal tracing_snapshot() functions")
+Signed-off-by: Eiichi Tsukata <devel@etsukata.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -6696,11 +6696,13 @@ tracing_snapshot_write(struct file *filp
+ break;
+ }
+ #endif
+- if (!tr->allocated_snapshot) {
++ if (tr->allocated_snapshot)
++ ret = resize_buffer_duplicate_size(&tr->max_buffer,
++ &tr->trace_buffer, iter->cpu_file);
++ else
+ ret = tracing_alloc_snapshot_instance(tr);
+- if (ret < 0)
+- break;
+- }
++ if (ret < 0)
++ break;
+ local_irq_disable();
+ /* Now, we're going to swap */
+ if (iter->cpu_file == RING_BUFFER_ALL_CPUS)
projects / thirdparty / kernel / stable-queue.git / commitdiff
