From: Greg Kroah-Hartman Date: Tue, 10 Sep 2019 11:30:05 +0000 (+0100) Subject: 4.19-stable patches X-Git-Tag: v4.4.193~28 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=36a9410bbc395767144d81e10183c3d550f5c0d1;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch alsa-hda-realtek-add-quirk-for-hp-pavilion-15.patch alsa-hda-realtek-enable-internal-speaker-headset-mic-of-asus-ux431fl.patch alsa-hda-realtek-fix-overridden-device-specific-initialization.patch alsa-hda-realtek-fix-the-problem-of-two-front-mics-on-a-thinkcentre.patch drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch vhost-test-fix-build-for-vhost-test-again.patch vhost-test-fix-build-for-vhost-test.patch --- diff --git a/queue-4.19/alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch b/queue-4.19/alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch new file mode 100644 index 00000000000..d3baa950e7d --- /dev/null +++ b/queue-4.19/alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch @@ -0,0 +1,43 @@ +From 333f31436d3db19f4286f8862a00ea1d8d8420a1 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 29 Aug 2019 09:52:02 +0200 +Subject: ALSA: hda - Fix potential endless loop at applying quirks + +From: Takashi Iwai + +commit 333f31436d3db19f4286f8862a00ea1d8d8420a1 upstream. + +Since the chained quirks via chained_before flag is applied before the +depth check, it may lead to the endless recursive calls, when the +chain were set up incorrectly. Fix it by moving the depth check at +the beginning of the loop. + +Fixes: 1f57825077dc ("ALSA: hda - Add chained_before flag to the fixup entry") +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/hda_auto_parser.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/sound/pci/hda/hda_auto_parser.c ++++ b/sound/pci/hda/hda_auto_parser.c +@@ -828,6 +828,8 @@ static void apply_fixup(struct hda_codec + while (id >= 0) { + const struct hda_fixup *fix = codec->fixup_list + id; + ++ if (++depth > 10) ++ break; + if (fix->chained_before) + apply_fixup(codec, fix->chain_id, action, depth + 1); + +@@ -867,8 +869,6 @@ static void apply_fixup(struct hda_codec + } + if (!fix->chained || fix->chained_before) + break; +- if (++depth > 10) +- break; + id = fix->chain_id; + } + } diff --git a/queue-4.19/alsa-hda-realtek-add-quirk-for-hp-pavilion-15.patch b/queue-4.19/alsa-hda-realtek-add-quirk-for-hp-pavilion-15.patch new file mode 100644 index 00000000000..b1f7fe533c9 --- /dev/null +++ b/queue-4.19/alsa-hda-realtek-add-quirk-for-hp-pavilion-15.patch @@ -0,0 +1,33 @@ +From d33cd42d86671bed870827aa399aeb9f1da74119 Mon Sep 17 00:00:00 2001 +From: Sam Bazley +Date: Sun, 1 Sep 2019 03:31:30 +0100 +Subject: ALSA: hda/realtek - Add quirk for HP Pavilion 15 + +From: Sam Bazley + +commit d33cd42d86671bed870827aa399aeb9f1da74119 upstream. + +HP Pavilion 15 (AMD Ryzen-based model) with 103c:84e7 needs the same +quirk like HP Envy/Spectre x360 for enabling the mute LED over Mic3 pin. + +[ rearranged in the SSID number order by tiwai ] + +Signed-off-by: Sam Bazley +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -6845,6 +6845,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x103c, 0x82c0, "HP G3 mini premium", ALC221_FIXUP_HP_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x103c, 0x83b9, "HP Spectre x360", ALC269_FIXUP_HP_MUTE_LED_MIC3), + SND_PCI_QUIRK(0x103c, 0x8497, "HP Envy x360", ALC269_FIXUP_HP_MUTE_LED_MIC3), ++ SND_PCI_QUIRK(0x103c, 0x84e7, "HP Pavilion 15", ALC269_FIXUP_HP_MUTE_LED_MIC3), + SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC), + SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC282_FIXUP_ASUS_TX300), + SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), diff --git a/queue-4.19/alsa-hda-realtek-enable-internal-speaker-headset-mic-of-asus-ux431fl.patch b/queue-4.19/alsa-hda-realtek-enable-internal-speaker-headset-mic-of-asus-ux431fl.patch new file mode 100644 index 00000000000..dfb533d00d8 --- /dev/null +++ b/queue-4.19/alsa-hda-realtek-enable-internal-speaker-headset-mic-of-asus-ux431fl.patch @@ -0,0 +1,79 @@ +From 60083f9e94b2f28047d71ed778adf89357c1a8fb Mon Sep 17 00:00:00 2001 +From: Jian-Hong Pan +Date: Mon, 2 Sep 2019 18:00:56 +0800 +Subject: ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL + +From: Jian-Hong Pan + +commit 60083f9e94b2f28047d71ed778adf89357c1a8fb upstream. + +Original pin node values of ASUS UX431FL with ALC294: + +0x12 0xb7a60140 +0x13 0x40000000 +0x14 0x90170110 +0x15 0x411111f0 +0x16 0x411111f0 +0x17 0x90170111 +0x18 0x411111f0 +0x19 0x411111f0 +0x1a 0x411111f0 +0x1b 0x411111f0 +0x1d 0x4066852d +0x1e 0x411111f0 +0x1f 0x411111f0 +0x21 0x04211020 + +1. Has duplicated internal speakers (0x14 & 0x17) which makes the output + route become confused. So, the output volume cannot be changed by + setting. +2. Misses the headset mic pin node. + +This patch disables the confusing speaker (NID 0x14) and enables the +headset mic (NID 0x19). + +Link: https://lore.kernel.org/r/20190902100054.6941-1-jian-hong@endlessm.com +Signed-off-by: Jian-Hong Pan +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -5675,6 +5675,7 @@ enum { + ALC286_FIXUP_ACER_AIO_HEADSET_MIC, + ALC256_FIXUP_ASUS_MIC_NO_PRESENCE, + ALC299_FIXUP_PREDATOR_SPK, ++ ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC, + }; + + static const struct hda_fixup alc269_fixups[] = { +@@ -6703,6 +6704,16 @@ static const struct hda_fixup alc269_fix + { } + } + }, ++ [ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC] = { ++ .type = HDA_FIXUP_PINS, ++ .v.pins = (const struct hda_pintbl[]) { ++ { 0x14, 0x411111f0 }, /* disable confusing internal speaker */ ++ { 0x19, 0x04a11150 }, /* use as headset mic, without its own jack detect */ ++ { } ++ }, ++ .chained = true, ++ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC ++ }, + }; + + static const struct snd_pci_quirk alc269_fixup_tbl[] = { +@@ -6862,6 +6873,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), + SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A), + SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC), ++ SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL", ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC), + SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW), + SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC), + SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC), diff --git a/queue-4.19/alsa-hda-realtek-fix-overridden-device-specific-initialization.patch b/queue-4.19/alsa-hda-realtek-fix-overridden-device-specific-initialization.patch new file mode 100644 index 00000000000..e51b5ad69a2 --- /dev/null +++ b/queue-4.19/alsa-hda-realtek-fix-overridden-device-specific-initialization.patch @@ -0,0 +1,69 @@ +From 89781d0806c2c4f29072d3f00cb2dd4274aabc3d Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 30 Aug 2019 12:03:38 +0200 +Subject: ALSA: hda/realtek - Fix overridden device-specific initialization + +From: Takashi Iwai + +commit 89781d0806c2c4f29072d3f00cb2dd4274aabc3d upstream. + +The recent change to shuffle the codec initialization procedure for +Realtek via commit 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on +later") caused the silent output on some machines. This change was +supposed to be safe, but it isn't actually; some devices have quirk +setups to override the EAPD via COEF or BTL in the additional verb +table, which is applied at the beginning of snd_hda_gen_init(). And +this EAPD setup is again overridden in alc_auto_init_amp(). + +For recovering from the regression, tell snd_hda_gen_init() not to +apply the verbs there by a new flag, then apply the verbs in +alc_init(). + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204727 +Fixes: 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later") +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/hda_generic.c | 3 ++- + sound/pci/hda/hda_generic.h | 1 + + sound/pci/hda/patch_realtek.c | 2 ++ + 3 files changed, 5 insertions(+), 1 deletion(-) + +--- a/sound/pci/hda/hda_generic.c ++++ b/sound/pci/hda/hda_generic.c +@@ -5991,7 +5991,8 @@ int snd_hda_gen_init(struct hda_codec *c + if (spec->init_hook) + spec->init_hook(codec); + +- snd_hda_apply_verbs(codec); ++ if (!spec->skip_verbs) ++ snd_hda_apply_verbs(codec); + + init_multi_out(codec); + init_extra_out(codec); +--- a/sound/pci/hda/hda_generic.h ++++ b/sound/pci/hda/hda_generic.h +@@ -247,6 +247,7 @@ struct hda_gen_spec { + unsigned int indep_hp_enabled:1; /* independent HP enabled */ + unsigned int have_aamix_ctl:1; + unsigned int hp_mic_jack_modes:1; ++ unsigned int skip_verbs:1; /* don't apply verbs at snd_hda_gen_init() */ + + /* additional mute flags (only effective with auto_mute_via_amp=1) */ + u64 mute_bits; +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -836,9 +836,11 @@ static int alc_init(struct hda_codec *co + if (spec->init_hook) + spec->init_hook(codec); + ++ spec->gen.skip_verbs = 1; /* applied in below */ + snd_hda_gen_init(codec); + alc_fix_pll(codec); + alc_auto_init_amp(codec, spec->init_amp); ++ snd_hda_apply_verbs(codec); /* apply verbs here after own init */ + + snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_INIT); + diff --git a/queue-4.19/alsa-hda-realtek-fix-the-problem-of-two-front-mics-on-a-thinkcentre.patch b/queue-4.19/alsa-hda-realtek-fix-the-problem-of-two-front-mics-on-a-thinkcentre.patch new file mode 100644 index 00000000000..9d5539ecf5f --- /dev/null +++ b/queue-4.19/alsa-hda-realtek-fix-the-problem-of-two-front-mics-on-a-thinkcentre.patch @@ -0,0 +1,48 @@ +From 2a36c16efab254dd6017efeb35ad88ecc96f2328 Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Wed, 4 Sep 2019 13:53:27 +0800 +Subject: ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre + +From: Hui Wang + +commit 2a36c16efab254dd6017efeb35ad88ecc96f2328 upstream. + +This ThinkCentre machine has a new realtek codec alc222, it is not +in the support list, we add it in the realtek.c then this machine +can apply FIXUPs for the realtek codec. + +And this machine has two front mics which can't be handled +by PA so far, it uses the pin 0x18 and 0x19 as the front mics, as +a result the existing FIXUP ALC294_FIXUP_LENOVO_MIC_LOCATION doesn't +work on this machine. Fortunately another FIXUP +ALC283_FIXUP_HEADSET_MIC also can change the location for one of the +two mics on this machine. + +Link: https://lore.kernel.org/r/20190904055327.9883-1-hui.wang@canonical.com +Signed-off-by: Hui Wang +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -6951,6 +6951,7 @@ static const struct snd_pci_quirk alc269 + 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), ++ SND_PCI_QUIRK(0x17aa, 0x3151, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC), + SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI), + SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC), + SND_PCI_QUIRK(0x17aa, 0x3978, "Lenovo B50-70", ALC269_FIXUP_DMIC_THINKPAD_ACPI), +@@ -8813,6 +8814,7 @@ static int patch_alc680(struct hda_codec + static const struct hda_device_id snd_hda_id_realtek[] = { + HDA_CODEC_ENTRY(0x10ec0215, "ALC215", patch_alc269), + HDA_CODEC_ENTRY(0x10ec0221, "ALC221", patch_alc269), ++ HDA_CODEC_ENTRY(0x10ec0222, "ALC222", patch_alc269), + HDA_CODEC_ENTRY(0x10ec0225, "ALC225", patch_alc269), + HDA_CODEC_ENTRY(0x10ec0231, "ALC231", patch_alc269), + HDA_CODEC_ENTRY(0x10ec0233, "ALC233", patch_alc269), diff --git a/queue-4.19/drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch b/queue-4.19/drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch new file mode 100644 index 00000000000..bcfeff0414d --- /dev/null +++ b/queue-4.19/drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch @@ -0,0 +1,68 @@ +From 08b0c891605acf727e43e3e03a25857d3e789b61 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Thu, 15 Aug 2019 11:30:50 +0300 +Subject: drm/vmwgfx: Fix double free in vmw_recv_msg() + +From: Dan Carpenter + +commit 08b0c891605acf727e43e3e03a25857d3e789b61 upstream. + +We recently added a kfree() after the end of the loop: + + if (retries == RETRIES) { + kfree(reply); + return -EINVAL; + } + +There are two problems. First the test is wrong and because retries +equals RETRIES if we succeed on the last iteration through the loop. +Second if we fail on the last iteration through the loop then the kfree +is a double free. + +When you're reading this code, please note the break statement at the +end of the while loop. This patch changes the loop so that if it's not +successful then "reply" is NULL and we can test for that afterward. + +Cc: +Fixes: 6b7c3b86f0b6 ("drm/vmwgfx: fix memory leak when too many retries have occurred") +Signed-off-by: Dan Carpenter +Reviewed-by: Thomas Hellstrom +Signed-off-by: Thomas Hellstrom +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c ++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c +@@ -353,7 +353,7 @@ static int vmw_recv_msg(struct rpc_chann + !!(HIGH_WORD(ecx) & MESSAGE_STATUS_HB)); + if ((HIGH_WORD(ebx) & MESSAGE_STATUS_SUCCESS) == 0) { + kfree(reply); +- ++ reply = NULL; + if ((HIGH_WORD(ebx) & MESSAGE_STATUS_CPT) != 0) { + /* A checkpoint occurred. Retry. */ + continue; +@@ -377,7 +377,7 @@ static int vmw_recv_msg(struct rpc_chann + + if ((HIGH_WORD(ecx) & MESSAGE_STATUS_SUCCESS) == 0) { + kfree(reply); +- ++ reply = NULL; + if ((HIGH_WORD(ecx) & MESSAGE_STATUS_CPT) != 0) { + /* A checkpoint occurred. Retry. */ + continue; +@@ -389,10 +389,8 @@ static int vmw_recv_msg(struct rpc_chann + break; + } + +- if (retries == RETRIES) { +- kfree(reply); ++ if (!reply) + return -EINVAL; +- } + + *msg_len = reply_len; + *msg = reply; diff --git a/queue-4.19/powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch b/queue-4.19/powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch new file mode 100644 index 00000000000..3ad205ef32f --- /dev/null +++ b/queue-4.19/powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch @@ -0,0 +1,114 @@ +From 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 Mon Sep 17 00:00:00 2001 +From: Gustavo Romero +Date: Wed, 4 Sep 2019 00:55:27 -0400 +Subject: powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction + +From: Gustavo Romero + +commit 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 upstream. + +When we take an FP unavailable exception in a transaction we have to +account for the hardware FP TM checkpointed registers being +incorrect. In this case for this process we know the current and +checkpointed FP registers must be the same (since FP wasn't used +inside the transaction) hence in the thread_struct we copy the current +FP registers to the checkpointed ones. + +This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr +to determine if FP was on when in userspace. thread->ckpt_regs.msr +represents the state of the MSR when exiting userspace. This is setup +by check_if_tm_restore_required(). + +Unfortunatley there is an optimisation in giveup_all() which returns +early if tsk->thread.regs->msr (via local variable `usermsr`) has +FP=VEC=VSX=SPE=0. This optimisation means that +check_if_tm_restore_required() is not called and hence +thread->ckpt_regs.msr is not updated and will contain an old value. + +This can happen if due to load_fp=255 we start a userspace process +with MSR FP=1 and then we are context switched out. In this case +thread->ckpt_regs.msr will contain FP=1. If that same process is then +context switched in and load_fp overflows, MSR will have FP=0. If that +process now enters a transaction and does an FP instruction, the FP +unavailable will not update thread->ckpt_regs.msr (the bug) and MSR +FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread() +will then not perform the required memcpy and the checkpointed FP regs +in the thread struct will contain the wrong values. + +The code path for this happening is: + + Userspace: Kernel + Start userspace + with MSR FP/VEC/VSX/SPE=0 TM=1 + < ----- + ... + tbegin + bne + fp instruction + FP unavailable + ---- > + fp_unavailable_tm() + tm_reclaim_current() + tm_reclaim_thread() + giveup_all() + return early since FP/VMX/VSX=0 + /* ckpt MSR not updated (Incorrect) */ + tm_reclaim() + /* thread_struct ckpt FP regs contain junk (OK) */ + /* Sees ckpt MSR FP=1 (Incorrect) */ + no memcpy() performed + /* thread_struct ckpt FP regs not fixed (Incorrect) */ + tm_recheckpoint() + /* Put junk in hardware checkpoint FP regs */ + .... + < ----- + Return to userspace + with MSR TM=1 FP=1 + with junk in the FP TM checkpoint + TM rollback + reads FP junk + +This is a data integrity problem for the current process as the FP +registers are corrupted. It's also a security problem as the FP +registers from one process may be leaked to another. + +This patch moves up check_if_tm_restore_required() in giveup_all() to +ensure thread->ckpt_regs.msr is updated correctly. + +A simple testcase to replicate this will be posted to +tools/testing/selftests/powerpc/tm/tm-poison.c + +Similarly for VMX. + +This fixes CVE-2019-15030. + +Fixes: f48e91e87e67 ("powerpc/tm: Fix FP and VMX register corruption") +Cc: stable@vger.kernel.org # 4.12+ +Signed-off-by: Gustavo Romero +Signed-off-by: Michael Neuling +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/process.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/kernel/process.c ++++ b/arch/powerpc/kernel/process.c +@@ -499,13 +499,14 @@ void giveup_all(struct task_struct *tsk) + if (!tsk->thread.regs) + return; + ++ check_if_tm_restore_required(tsk); ++ + usermsr = tsk->thread.regs->msr; + + if ((usermsr & msr_all_available) == 0) + return; + + msr_check_and_set(msr_all_available); +- check_if_tm_restore_required(tsk); + + WARN_ON((usermsr & MSR_VSX) && !((usermsr & MSR_FP) && (usermsr & MSR_VEC))); + diff --git a/queue-4.19/sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch b/queue-4.19/sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch new file mode 100644 index 00000000000..60184539122 --- /dev/null +++ b/queue-4.19/sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch @@ -0,0 +1,73 @@ +From 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 Mon Sep 17 00:00:00 2001 +From: Liangyan +Date: Mon, 26 Aug 2019 20:16:33 +0800 +Subject: sched/fair: Don't assign runtime for throttled cfs_rq + +From: Liangyan + +commit 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 upstream. + +do_sched_cfs_period_timer() will refill cfs_b runtime and call +distribute_cfs_runtime to unthrottle cfs_rq, sometimes cfs_b->runtime +will allocate all quota to one cfs_rq incorrectly, then other cfs_rqs +attached to this cfs_b can't get runtime and will be throttled. + +We find that one throttled cfs_rq has non-negative +cfs_rq->runtime_remaining and cause an unexpetced cast from s64 to u64 +in snippet: + + distribute_cfs_runtime() { + runtime = -cfs_rq->runtime_remaining + 1; + } + +The runtime here will change to a large number and consume all +cfs_b->runtime in this cfs_b period. + +According to Ben Segall, the throttled cfs_rq can have +account_cfs_rq_runtime called on it because it is throttled before +idle_balance, and the idle_balance calls update_rq_clock to add time +that is accounted to the task. + +This commit prevents cfs_rq to be assgined new runtime if it has been +throttled until that distribute_cfs_runtime is called. + +Signed-off-by: Liangyan +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Valentin Schneider +Reviewed-by: Ben Segall +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: shanpeic@linux.alibaba.com +Cc: stable@vger.kernel.org +Cc: xlpang@linux.alibaba.com +Fixes: d3d9dc330236 ("sched: Throttle entities exceeding their allowed bandwidth") +Link: https://lkml.kernel.org/r/20190826121633.6538-1-liangyan.peng@linux.alibaba.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/sched/fair.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/kernel/sched/fair.c ++++ b/kernel/sched/fair.c +@@ -4420,6 +4420,8 @@ static void __account_cfs_rq_runtime(str + if (likely(cfs_rq->runtime_remaining > 0)) + return; + ++ if (cfs_rq->throttled) ++ return; + /* + * if we're unable to extend our runtime we resched so that the active + * hierarchy can be throttled +@@ -4615,6 +4617,9 @@ static u64 distribute_cfs_runtime(struct + if (!cfs_rq_throttled(cfs_rq)) + goto next; + ++ /* By the above check, this should never be true */ ++ SCHED_WARN_ON(cfs_rq->runtime_remaining > 0); ++ + runtime = -cfs_rq->runtime_remaining + 1; + if (runtime > remaining) + runtime = remaining; diff --git a/queue-4.19/vhost-test-fix-build-for-vhost-test-again.patch b/queue-4.19/vhost-test-fix-build-for-vhost-test-again.patch new file mode 100644 index 00000000000..ab6b5bf258c --- /dev/null +++ b/queue-4.19/vhost-test-fix-build-for-vhost-test-again.patch @@ -0,0 +1,62 @@ +From 264b563b8675771834419057cbe076c1a41fb666 Mon Sep 17 00:00:00 2001 +From: Tiwei Bie +Date: Wed, 28 Aug 2019 13:37:00 +0800 +Subject: vhost/test: fix build for vhost test - again + +From: Tiwei Bie + +commit 264b563b8675771834419057cbe076c1a41fb666 upstream. + +Since vhost_exceeds_weight() was introduced, callers need to specify +the packet weight and byte weight in vhost_dev_init(). Note that, the +packet weight isn't counted in this patch to keep the original behavior +unchanged. + +Fixes: e82b9b0727ff ("vhost: introduce vhost_exceeds_weight()") +Cc: stable@vger.kernel.org +Signed-off-by: Tiwei Bie +Signed-off-by: Michael S. Tsirkin +Acked-by: Jason Wang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/vhost/test.c | 13 +++++++++---- + 1 file changed, 9 insertions(+), 4 deletions(-) + +--- a/drivers/vhost/test.c ++++ b/drivers/vhost/test.c +@@ -23,6 +23,12 @@ + * Using this limit prevents one virtqueue from starving others. */ + #define VHOST_TEST_WEIGHT 0x80000 + ++/* Max number of packets transferred before requeueing the job. ++ * Using this limit prevents one virtqueue from starving others with ++ * pkts. ++ */ ++#define VHOST_TEST_PKT_WEIGHT 256 ++ + enum { + VHOST_TEST_VQ = 0, + VHOST_TEST_VQ_MAX = 1, +@@ -81,10 +87,8 @@ static void handle_vq(struct vhost_test + } + vhost_add_used_and_signal(&n->dev, vq, head, 0); + total_len += len; +- if (unlikely(total_len >= VHOST_TEST_WEIGHT)) { +- vhost_poll_queue(&vq->poll); ++ if (unlikely(vhost_exceeds_weight(vq, 0, total_len))) + break; +- } + } + + mutex_unlock(&vq->mutex); +@@ -116,7 +120,8 @@ static int vhost_test_open(struct inode + dev = &n->dev; + vqs[VHOST_TEST_VQ] = &n->vqs[VHOST_TEST_VQ]; + n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick; +- vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV); ++ vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV, ++ VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT); + + f->private_data = n; + diff --git a/queue-4.19/vhost-test-fix-build-for-vhost-test.patch b/queue-4.19/vhost-test-fix-build-for-vhost-test.patch new file mode 100644 index 00000000000..7b764632e21 --- /dev/null +++ b/queue-4.19/vhost-test-fix-build-for-vhost-test.patch @@ -0,0 +1,34 @@ +From 93d2c4de8d8129b97ee1e1a222aedb0719d2fcd9 Mon Sep 17 00:00:00 2001 +From: Tiwei Bie +Date: Wed, 28 Aug 2019 13:36:59 +0800 +Subject: vhost/test: fix build for vhost test + +From: Tiwei Bie + +commit 93d2c4de8d8129b97ee1e1a222aedb0719d2fcd9 upstream. + +Since below commit, callers need to specify the iov_limit in +vhost_dev_init() explicitly. + +Fixes: b46a0bf78ad7 ("vhost: fix OOB in get_rx_bufs()") +Cc: stable@vger.kernel.org +Signed-off-by: Tiwei Bie +Signed-off-by: Michael S. Tsirkin +Acked-by: Jason Wang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/vhost/test.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/vhost/test.c ++++ b/drivers/vhost/test.c +@@ -116,7 +116,7 @@ static int vhost_test_open(struct inode + dev = &n->dev; + vqs[VHOST_TEST_VQ] = &n->vqs[VHOST_TEST_VQ]; + n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick; +- vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX); ++ vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV); + + f->private_data = n; +