From: Sasha Levin Date: Mon, 18 Jul 2022 01:29:47 +0000 (-0400) Subject: Fixes for 4.19 X-Git-Tag: v4.9.324~31 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=0971c172f73d3d4bdfc26aecf33623eb4914bc4f;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.19 Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/arm-dts-stm32-use-the-correct-clock-source-for-cec-o.patch b/queue-4.19/arm-dts-stm32-use-the-correct-clock-source-for-cec-o.patch new file mode 100644 index 00000000000..2fe939d1ae9 --- /dev/null +++ b/queue-4.19/arm-dts-stm32-use-the-correct-clock-source-for-cec-o.patch @@ -0,0 +1,34 @@ +From 739a0dafbe60b4490c5ec80bc3f44779bf369957 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 24 Jun 2022 11:27:13 +0200 +Subject: ARM: dts: stm32: use the correct clock source for CEC on stm32mp151 + +From: Gabriel Fernandez + +[ Upstream commit 78ece8cce1ba0c3f3e5a7c6c1b914b3794f04c44 ] + +The peripheral clock of CEC is not LSE but CEC. + +Signed-off-by: Gabriel Fernandez +Signed-off-by: Alexandre Torgue +Signed-off-by: Sasha Levin +--- + arch/arm/boot/dts/stm32mp157c.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi +index 4278a4b22860..7c5b2727ba2e 100644 +--- a/arch/arm/boot/dts/stm32mp157c.dtsi ++++ b/arch/arm/boot/dts/stm32mp157c.dtsi +@@ -413,7 +413,7 @@ + compatible = "st,stm32-cec"; + reg = <0x40016000 0x400>; + interrupts = ; +- clocks = <&rcc CEC_K>, <&clk_lse>; ++ clocks = <&rcc CEC_K>, <&rcc CEC>; + clock-names = "cec", "hdmi-cec"; + status = "disabled"; + }; +-- +2.35.1 + diff --git a/queue-4.19/asoc-ops-fix-off-by-one-in-range-control-validation.patch b/queue-4.19/asoc-ops-fix-off-by-one-in-range-control-validation.patch new file mode 100644 index 00000000000..015a7c92318 --- /dev/null +++ b/queue-4.19/asoc-ops-fix-off-by-one-in-range-control-validation.patch @@ -0,0 +1,45 @@ +From 57e93401b14701fb5dd1259c7c5503a5172e46ce Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 4 Jun 2022 11:52:46 +0100 +Subject: ASoC: ops: Fix off by one in range control validation + +From: Mark Brown + +[ Upstream commit 5871321fb4558c55bf9567052b618ff0be6b975e ] + +We currently report that range controls accept a range of 0..(max-min) but +accept writes in the range 0..(max-min+1). Remove that extra +1. + +Signed-off-by: Mark Brown +Link: https://lore.kernel.org/r/20220604105246.4055214-1-broonie@kernel.org +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/soc-ops.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c +index 7a37312c8e0c..453b61b42dd9 100644 +--- a/sound/soc/soc-ops.c ++++ b/sound/soc/soc-ops.c +@@ -530,7 +530,7 @@ int snd_soc_put_volsw_range(struct snd_kcontrol *kcontrol, + return -EINVAL; + if (mc->platform_max && tmp > mc->platform_max) + return -EINVAL; +- if (tmp > mc->max - mc->min + 1) ++ if (tmp > mc->max - mc->min) + return -EINVAL; + + if (invert) +@@ -551,7 +551,7 @@ int snd_soc_put_volsw_range(struct snd_kcontrol *kcontrol, + return -EINVAL; + if (mc->platform_max && tmp > mc->platform_max) + return -EINVAL; +- if (tmp > mc->max - mc->min + 1) ++ if (tmp > mc->max - mc->min) + return -EINVAL; + + if (invert) +-- +2.35.1 + diff --git a/queue-4.19/asoc-wm5110-fix-dre-control.patch b/queue-4.19/asoc-wm5110-fix-dre-control.patch new file mode 100644 index 00000000000..ca6f4798c34 --- /dev/null +++ b/queue-4.19/asoc-wm5110-fix-dre-control.patch @@ -0,0 +1,56 @@ +From 270d76035086806adeac017a06ca1cfdacd69c09 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 21 Jun 2022 11:20:39 +0100 +Subject: ASoC: wm5110: Fix DRE control + +From: Charles Keepax + +[ Upstream commit 0bc0ae9a5938d512fd5d44f11c9c04892dcf4961 ] + +The DRE controls on wm5110 should return a value of 1 if the DRE state +is actually changed, update to fix this. + +Signed-off-by: Charles Keepax +Link: https://lore.kernel.org/r/20220621102041.1713504-2-ckeepax@opensource.cirrus.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/codecs/wm5110.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/sound/soc/codecs/wm5110.c b/sound/soc/codecs/wm5110.c +index b0789a03d699..e510aca55163 100644 +--- a/sound/soc/codecs/wm5110.c ++++ b/sound/soc/codecs/wm5110.c +@@ -414,6 +414,7 @@ static int wm5110_put_dre(struct snd_kcontrol *kcontrol, + unsigned int rnew = (!!ucontrol->value.integer.value[1]) << mc->rshift; + unsigned int lold, rold; + unsigned int lena, rena; ++ bool change = false; + int ret; + + snd_soc_dapm_mutex_lock(dapm); +@@ -441,8 +442,8 @@ static int wm5110_put_dre(struct snd_kcontrol *kcontrol, + goto err; + } + +- ret = regmap_update_bits(arizona->regmap, ARIZONA_DRE_ENABLE, +- mask, lnew | rnew); ++ ret = regmap_update_bits_check(arizona->regmap, ARIZONA_DRE_ENABLE, ++ mask, lnew | rnew, &change); + if (ret) { + dev_err(arizona->dev, "Failed to set DRE: %d\n", ret); + goto err; +@@ -455,6 +456,9 @@ static int wm5110_put_dre(struct snd_kcontrol *kcontrol, + if (!rnew && rold) + wm5110_clear_pga_volume(arizona, mc->rshift); + ++ if (change) ++ ret = 1; ++ + err: + snd_soc_dapm_mutex_unlock(dapm); + +-- +2.35.1 + diff --git a/queue-4.19/cpufreq-pmac32-cpufreq-fix-refcount-leak-bug.patch b/queue-4.19/cpufreq-pmac32-cpufreq-fix-refcount-leak-bug.patch new file mode 100644 index 00000000000..d5012f1c097 --- /dev/null +++ b/queue-4.19/cpufreq-pmac32-cpufreq-fix-refcount-leak-bug.patch @@ -0,0 +1,38 @@ +From 65eb53412c14a4b3cce1e5fd9dba44908f591e11 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 18 Jun 2022 10:25:45 +0800 +Subject: cpufreq: pmac32-cpufreq: Fix refcount leak bug + +From: Liang He + +[ Upstream commit ccd7567d4b6cf187fdfa55f003a9e461ee629e36 ] + +In pmac_cpufreq_init_MacRISC3(), we need to add corresponding +of_node_put() for the three node pointers whose refcount have +been incremented by of_find_node_by_name(). + +Signed-off-by: Liang He +Signed-off-by: Viresh Kumar +Signed-off-by: Sasha Levin +--- + drivers/cpufreq/pmac32-cpufreq.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/cpufreq/pmac32-cpufreq.c b/drivers/cpufreq/pmac32-cpufreq.c +index e225edb5c359..ce0dda1a4241 100644 +--- a/drivers/cpufreq/pmac32-cpufreq.c ++++ b/drivers/cpufreq/pmac32-cpufreq.c +@@ -474,6 +474,10 @@ static int pmac_cpufreq_init_MacRISC3(struct device_node *cpunode) + if (slew_done_gpio_np) + slew_done_gpio = read_gpio(slew_done_gpio_np); + ++ of_node_put(volt_gpio_np); ++ of_node_put(freq_gpio_np); ++ of_node_put(slew_done_gpio_np); ++ + /* If we use the frequency GPIOs, calculate the min/max speeds based + * on the bus frequencies + */ +-- +2.35.1 + diff --git a/queue-4.19/irqchip-or1k-pic-undefine-mask_ack-for-level-trigger.patch b/queue-4.19/irqchip-or1k-pic-undefine-mask_ack-for-level-trigger.patch new file mode 100644 index 00000000000..6bca7c68811 --- /dev/null +++ b/queue-4.19/irqchip-or1k-pic-undefine-mask_ack-for-level-trigger.patch @@ -0,0 +1,41 @@ +From af283264daf71989194bf062825dc5d4036359d0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 15 Jun 2022 08:54:26 +0900 +Subject: irqchip: or1k-pic: Undefine mask_ack for level triggered hardware + +From: Stafford Horne + +[ Upstream commit 8520501346ed8d1c4a6dfa751cb57328a9c843f1 ] + +The mask_ack operation clears the interrupt by writing to the PICSR +register. This we don't want for level triggered interrupt because +it does not actually clear the interrupt on the source hardware. + +This was causing issues in qemu with multi core setups where +interrupts would continue to fire even though they had been cleared in +PICSR. + +Just remove the mask_ack operation. + +Acked-by: Marc Zyngier +Signed-off-by: Stafford Horne +Signed-off-by: Sasha Levin +--- + drivers/irqchip/irq-or1k-pic.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/drivers/irqchip/irq-or1k-pic.c b/drivers/irqchip/irq-or1k-pic.c +index dd9d5d12fea2..05931fdedbb9 100644 +--- a/drivers/irqchip/irq-or1k-pic.c ++++ b/drivers/irqchip/irq-or1k-pic.c +@@ -70,7 +70,6 @@ static struct or1k_pic_dev or1k_pic_level = { + .name = "or1k-PIC-level", + .irq_unmask = or1k_pic_unmask, + .irq_mask = or1k_pic_mask, +- .irq_mask_ack = or1k_pic_mask_ack, + }, + .handle = handle_level_irq, + .flags = IRQ_LEVEL | IRQ_NOPROBE, +-- +2.35.1 + diff --git a/queue-4.19/net-sfp-fix-memory-leak-in-sfp_probe.patch b/queue-4.19/net-sfp-fix-memory-leak-in-sfp_probe.patch new file mode 100644 index 00000000000..f67bd84dc3a --- /dev/null +++ b/queue-4.19/net-sfp-fix-memory-leak-in-sfp_probe.patch @@ -0,0 +1,39 @@ +From 2c89e88daa70e8945de417fbe88ed1f7c0b0d29f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 29 Jun 2022 15:55:50 +0800 +Subject: net: sfp: fix memory leak in sfp_probe() + +From: Jianglei Nie + +[ Upstream commit 0a18d802d65cf662644fd1d369c86d84a5630652 ] + +sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When +devm_add_action() fails, sfp is not freed, which leads to a memory leak. + +We should use devm_add_action_or_reset() instead of devm_add_action(). + +Signed-off-by: Jianglei Nie +Reviewed-by: Russell King (Oracle) +Link: https://lore.kernel.org/r/20220629075550.2152003-1-niejianglei2021@163.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/phy/sfp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c +index 71bafc8f5ed0..e7af73ad8a44 100644 +--- a/drivers/net/phy/sfp.c ++++ b/drivers/net/phy/sfp.c +@@ -1811,7 +1811,7 @@ static int sfp_probe(struct platform_device *pdev) + + platform_set_drvdata(pdev, sfp); + +- err = devm_add_action(sfp->dev, sfp_cleanup, sfp); ++ err = devm_add_action_or_reset(sfp->dev, sfp_cleanup, sfp); + if (err < 0) + return err; + +-- +2.35.1 + diff --git a/queue-4.19/net-tipc-fix-possible-refcount-leak-in-tipc_sk_creat.patch b/queue-4.19/net-tipc-fix-possible-refcount-leak-in-tipc_sk_creat.patch new file mode 100644 index 00000000000..023b03f6d66 --- /dev/null +++ b/queue-4.19/net-tipc-fix-possible-refcount-leak-in-tipc_sk_creat.patch @@ -0,0 +1,34 @@ +From 7e5088cefe82d073a78748416fa1f5cbeae353f7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 29 Jun 2022 14:34:18 +0800 +Subject: net: tipc: fix possible refcount leak in tipc_sk_create() + +From: Hangyu Hua + +[ Upstream commit 00aff3590fc0a73bddd3b743863c14e76fd35c0c ] + +Free sk in case tipc_sk_insert() fails. + +Signed-off-by: Hangyu Hua +Reviewed-by: Tung Nguyen +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/tipc/socket.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/net/tipc/socket.c b/net/tipc/socket.c +index 6c18b4565ab5..8266452c143b 100644 +--- a/net/tipc/socket.c ++++ b/net/tipc/socket.c +@@ -453,6 +453,7 @@ static int tipc_sk_create(struct net *net, struct socket *sock, + sock_init_data(sock, sk); + tipc_set_sk_state(sk, TIPC_OPEN); + if (tipc_sk_insert(tsk)) { ++ sk_free(sk); + pr_warn("Socket create failed; port number exhausted\n"); + return -EINVAL; + } +-- +2.35.1 + diff --git a/queue-4.19/netfilter-br_netfilter-do-not-skip-all-hooks-with-0-.patch b/queue-4.19/netfilter-br_netfilter-do-not-skip-all-hooks-with-0-.patch new file mode 100644 index 00000000000..ecbe2b6758b --- /dev/null +++ b/queue-4.19/netfilter-br_netfilter-do-not-skip-all-hooks-with-0-.patch @@ -0,0 +1,104 @@ +From e2c0afcf2c43a652fa7a620b211d2c5125b394d6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 21 Jun 2022 18:26:03 +0200 +Subject: netfilter: br_netfilter: do not skip all hooks with 0 priority + +From: Florian Westphal + +[ Upstream commit c2577862eeb0be94f151f2f1fff662b028061b00 ] + +When br_netfilter module is loaded, skbs may be diverted to the +ipv4/ipv6 hooks, just like as if we were routing. + +Unfortunately, bridge filter hooks with priority 0 may be skipped +in this case. + +Example: +1. an nftables bridge ruleset is loaded, with a prerouting + hook that has priority 0. +2. interface is added to the bridge. +3. no tcp packet is ever seen by the bridge prerouting hook. +4. flush the ruleset +5. load the bridge ruleset again. +6. tcp packets are processed as expected. + +After 1) the only registered hook is the bridge prerouting hook, but its +not called yet because the bridge hasn't been brought up yet. + +After 2), hook order is: + 0 br_nf_pre_routing // br_netfilter internal hook + 0 chain bridge f prerouting // nftables bridge ruleset + +The packet is diverted to br_nf_pre_routing. +If call-iptables is off, the nftables bridge ruleset is called as expected. + +But if its enabled, br_nf_hook_thresh() will skip it because it assumes +that all 0-priority hooks had been called previously in bridge context. + +To avoid this, check for the br_nf_pre_routing hook itself, we need to +resume directly after it, even if this hook has a priority of 0. + +Unfortunately, this still results in different packet flow. +With this fix, the eval order after in 3) is: +1. br_nf_pre_routing +2. ip(6)tables (if enabled) +3. nftables bridge + +but after 5 its the much saner: +1. nftables bridge +2. br_nf_pre_routing +3. ip(6)tables (if enabled) + +Unfortunately I don't see a solution here: +It would be possible to move br_nf_pre_routing to a higher priority +so that it will be called later in the pipeline, but this also impacts +ebtables evaluation order, and would still result in this very ordering +problem for all nftables-bridge hooks with the same priority as the +br_nf_pre_routing one. + +Searching back through the git history I don't think this has +ever behaved in any other way, hence, no fixes-tag. + +Reported-by: Radim Hrazdil +Signed-off-by: Florian Westphal +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/bridge/br_netfilter_hooks.c | 21 ++++++++++++++++++--- + 1 file changed, 18 insertions(+), 3 deletions(-) + +diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c +index 4b9d1d6bbf6f..55c7cdf5e7b8 100644 +--- a/net/bridge/br_netfilter_hooks.c ++++ b/net/bridge/br_netfilter_hooks.c +@@ -1001,9 +1001,24 @@ int br_nf_hook_thresh(unsigned int hook, struct net *net, + return okfn(net, sk, skb); + + ops = nf_hook_entries_get_hook_ops(e); +- for (i = 0; i < e->num_hook_entries && +- ops[i]->priority <= NF_BR_PRI_BRNF; i++) +- ; ++ for (i = 0; i < e->num_hook_entries; i++) { ++ /* These hooks have already been called */ ++ if (ops[i]->priority < NF_BR_PRI_BRNF) ++ continue; ++ ++ /* These hooks have not been called yet, run them. */ ++ if (ops[i]->priority > NF_BR_PRI_BRNF) ++ break; ++ ++ /* take a closer look at NF_BR_PRI_BRNF. */ ++ if (ops[i]->hook == br_nf_pre_routing) { ++ /* This hook diverted the skb to this function, ++ * hooks after this have not been run yet. ++ */ ++ i++; ++ break; ++ } ++ } + + nf_hook_state_init(&state, hook, NFPROTO_BRIDGE, indev, outdev, + sk, net, okfn); +-- +2.35.1 + diff --git a/queue-4.19/nfc-nxp-nci-don-t-print-header-length-mismatch-on-i2.patch b/queue-4.19/nfc-nxp-nci-don-t-print-header-length-mismatch-on-i2.patch new file mode 100644 index 00000000000..9e3d44cd786 --- /dev/null +++ b/queue-4.19/nfc-nxp-nci-don-t-print-header-length-mismatch-on-i2.patch @@ -0,0 +1,50 @@ +From 2029686f87c639a5aee49121e7920b6c446e860a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 27 Jun 2022 19:06:43 +0200 +Subject: NFC: nxp-nci: don't print header length mismatch on i2c error + +From: Michael Walle + +[ Upstream commit 9577fc5fdc8b07b891709af6453545db405e24ad ] + +Don't print a misleading header length mismatch error if the i2c call +returns an error. Instead just return the error code without any error +message. + +Signed-off-by: Michael Walle +Reviewed-by: Krzysztof Kozlowski +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/nfc/nxp-nci/i2c.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c +index 16c52d4c833c..e4e0744e2470 100644 +--- a/drivers/nfc/nxp-nci/i2c.c ++++ b/drivers/nfc/nxp-nci/i2c.c +@@ -138,7 +138,9 @@ static int nxp_nci_i2c_fw_read(struct nxp_nci_i2c_phy *phy, + skb_put_data(*skb, &header, NXP_NCI_FW_HDR_LEN); + + r = i2c_master_recv(client, skb_put(*skb, frame_len), frame_len); +- if (r != frame_len) { ++ if (r < 0) { ++ goto fw_read_exit_free_skb; ++ } else if (r != frame_len) { + nfc_err(&client->dev, + "Invalid frame length: %u (expected %zu)\n", + r, frame_len); +@@ -182,7 +184,9 @@ static int nxp_nci_i2c_nci_read(struct nxp_nci_i2c_phy *phy, + return 0; + + r = i2c_master_recv(client, skb_put(*skb, header.plen), header.plen); +- if (r != header.plen) { ++ if (r < 0) { ++ goto nci_read_exit_free_skb; ++ } else if (r != header.plen) { + nfc_err(&client->dev, + "Invalid frame payload length: %u (expected %u)\n", + r, header.plen); +-- +2.35.1 + diff --git a/queue-4.19/platform-x86-hp-wmi-ignore-sanitization-mode-event.patch b/queue-4.19/platform-x86-hp-wmi-ignore-sanitization-mode-event.patch new file mode 100644 index 00000000000..8fef20fb4ba --- /dev/null +++ b/queue-4.19/platform-x86-hp-wmi-ignore-sanitization-mode-event.patch @@ -0,0 +1,49 @@ +From 9c16512ea59bc2e4a8684b4500188fb5ef430634 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 28 Jun 2022 20:37:26 +0800 +Subject: platform/x86: hp-wmi: Ignore Sanitization Mode event + +From: Kai-Heng Feng + +[ Upstream commit 9ab762a84b8094540c18a170e5ddd6488632c456 ] + +After system resume the hp-wmi driver may complain: +[ 702.620180] hp_wmi: Unknown event_id - 23 - 0x0 + +According to HP it means 'Sanitization Mode' and it's harmless to just +ignore the event. + +Cc: Jorge Lopez +Signed-off-by: Kai-Heng Feng +Link: https://lore.kernel.org/r/20220628123726.250062-1-kai.heng.feng@canonical.com +Reviewed-by: Hans de Goede +Signed-off-by: Hans de Goede +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/hp-wmi.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c +index 93fadd4abf14..f911410bb4c7 100644 +--- a/drivers/platform/x86/hp-wmi.c ++++ b/drivers/platform/x86/hp-wmi.c +@@ -75,6 +75,7 @@ enum hp_wmi_event_ids { + HPWMI_BACKLIT_KB_BRIGHTNESS = 0x0D, + HPWMI_PEAKSHIFT_PERIOD = 0x0F, + HPWMI_BATTERY_CHARGE_PERIOD = 0x10, ++ HPWMI_SANITIZATION_MODE = 0x17, + }; + + struct bios_args { +@@ -631,6 +632,8 @@ static void hp_wmi_notify(u32 value, void *context) + break; + case HPWMI_BATTERY_CHARGE_PERIOD: + break; ++ case HPWMI_SANITIZATION_MODE: ++ break; + default: + pr_info("Unknown event_id - %d - 0x%x\n", event_id, event_data); + break; +-- +2.35.1 + diff --git a/queue-4.19/series b/queue-4.19/series index c5ffd63c1ce..a6d279f592d 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -24,3 +24,17 @@ seg6-fix-skb-checksum-evaluation-in-srh-encapsulatio.patch seg6-fix-skb-checksum-in-srv6-end.b6-and-end.b6.enca.patch seg6-bpf-fix-skb-checksum-in-bpf_push_seg6_encap.patch sfc-fix-kernel-panic-when-creating-vf.patch +virtio_mmio-add-missing-pm-calls-to-freeze-restore.patch +virtio_mmio-restore-guest-page-size-on-resume.patch +netfilter-br_netfilter-do-not-skip-all-hooks-with-0-.patch +cpufreq-pmac32-cpufreq-fix-refcount-leak-bug.patch +platform-x86-hp-wmi-ignore-sanitization-mode-event.patch +net-tipc-fix-possible-refcount-leak-in-tipc_sk_creat.patch +nfc-nxp-nci-don-t-print-header-length-mismatch-on-i2.patch +net-sfp-fix-memory-leak-in-sfp_probe.patch +asoc-ops-fix-off-by-one-in-range-control-validation.patch +asoc-wm5110-fix-dre-control.patch +irqchip-or1k-pic-undefine-mask_ack-for-level-trigger.patch +x86-clear-.brk-area-at-early-boot.patch +arm-dts-stm32-use-the-correct-clock-source-for-cec-o.patch +signal-handling-don-t-use-bug_on-for-debugging.patch diff --git a/queue-4.19/signal-handling-don-t-use-bug_on-for-debugging.patch b/queue-4.19/signal-handling-don-t-use-bug_on-for-debugging.patch new file mode 100644 index 00000000000..b745bc1ab5c --- /dev/null +++ b/queue-4.19/signal-handling-don-t-use-bug_on-for-debugging.patch @@ -0,0 +1,54 @@ +From ac8c5857e95d7f6590ea31a86551211a13515412 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 6 Jul 2022 12:20:59 -0700 +Subject: signal handling: don't use BUG_ON() for debugging + +From: Linus Torvalds + +[ Upstream commit a382f8fee42ca10c9bfce0d2352d4153f931f5dc ] + +These are indeed "should not happen" situations, but it turns out recent +changes made the 'task_is_stopped_or_trace()' case trigger (fix for that +exists, is pending more testing), and the BUG_ON() makes it +unnecessarily hard to actually debug for no good reason. + +It's been that way for a long time, but let's make it clear: BUG_ON() is +not good for debugging, and should never be used in situations where you +could just say "this shouldn't happen, but we can continue". + +Use WARN_ON_ONCE() instead to make sure it gets logged, and then just +continue running. Instead of making the system basically unusuable +because you crashed the machine while potentially holding some very core +locks (eg this function is commonly called while holding 'tasklist_lock' +for writing). + +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + kernel/signal.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/kernel/signal.c b/kernel/signal.c +index 4cc3f3ba13a9..c79b87ac1041 100644 +--- a/kernel/signal.c ++++ b/kernel/signal.c +@@ -1825,12 +1825,12 @@ bool do_notify_parent(struct task_struct *tsk, int sig) + bool autoreap = false; + u64 utime, stime; + +- BUG_ON(sig == -1); ++ WARN_ON_ONCE(sig == -1); + +- /* do_notify_parent_cldstop should have been called instead. */ +- BUG_ON(task_is_stopped_or_traced(tsk)); ++ /* do_notify_parent_cldstop should have been called instead. */ ++ WARN_ON_ONCE(task_is_stopped_or_traced(tsk)); + +- BUG_ON(!tsk->ptrace && ++ WARN_ON_ONCE(!tsk->ptrace && + (tsk->group_leader != tsk || !thread_group_empty(tsk))); + + if (sig != SIGCHLD) { +-- +2.35.1 + diff --git a/queue-4.19/virtio_mmio-add-missing-pm-calls-to-freeze-restore.patch b/queue-4.19/virtio_mmio-add-missing-pm-calls-to-freeze-restore.patch new file mode 100644 index 00000000000..4a1853824c7 --- /dev/null +++ b/queue-4.19/virtio_mmio-add-missing-pm-calls-to-freeze-restore.patch @@ -0,0 +1,81 @@ +From 7d77b37a4babb5f4ebd092a02cd6a22b464031ba Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 21 Jun 2022 13:06:20 +0200 +Subject: virtio_mmio: Add missing PM calls to freeze/restore + +From: Stephan Gerhold + +[ Upstream commit ed7ac37fde33ccd84e4bd2b9363c191f925364c7 ] + +Most virtio drivers provide freeze/restore callbacks to finish up +device usage before suspend and to reinitialize the virtio device after +resume. However, these callbacks are currently only called when using +virtio_pci. virtio_mmio does not have any PM ops defined. + +This causes problems for example after suspend to disk (hibernation), +since the virtio devices might lose their state after the VMM is +restarted. Calling virtio_device_freeze()/restore() ensures that +the virtio devices are re-initialized correctly. + +Fix this by implementing the dev_pm_ops for virtio_mmio, +similar to virtio_pci_common. + +Signed-off-by: Stephan Gerhold +Message-Id: <20220621110621.3638025-2-stephan.gerhold@kernkonzept.com> +Signed-off-by: Michael S. Tsirkin +Signed-off-by: Sasha Levin +--- + drivers/virtio/virtio_mmio.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c +index c69c755bf553..79474bd0c52c 100644 +--- a/drivers/virtio/virtio_mmio.c ++++ b/drivers/virtio/virtio_mmio.c +@@ -66,6 +66,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -508,6 +509,25 @@ static const struct virtio_config_ops virtio_mmio_config_ops = { + .bus_name = vm_bus_name, + }; + ++#ifdef CONFIG_PM_SLEEP ++static int virtio_mmio_freeze(struct device *dev) ++{ ++ struct virtio_mmio_device *vm_dev = dev_get_drvdata(dev); ++ ++ return virtio_device_freeze(&vm_dev->vdev); ++} ++ ++static int virtio_mmio_restore(struct device *dev) ++{ ++ struct virtio_mmio_device *vm_dev = dev_get_drvdata(dev); ++ ++ return virtio_device_restore(&vm_dev->vdev); ++} ++ ++static const struct dev_pm_ops virtio_mmio_pm_ops = { ++ SET_SYSTEM_SLEEP_PM_OPS(virtio_mmio_freeze, virtio_mmio_restore) ++}; ++#endif + + static void virtio_mmio_release_dev(struct device *_d) + { +@@ -761,6 +781,9 @@ static struct platform_driver virtio_mmio_driver = { + .name = "virtio-mmio", + .of_match_table = virtio_mmio_match, + .acpi_match_table = ACPI_PTR(virtio_mmio_acpi_match), ++#ifdef CONFIG_PM_SLEEP ++ .pm = &virtio_mmio_pm_ops, ++#endif + }, + }; + +-- +2.35.1 + diff --git a/queue-4.19/virtio_mmio-restore-guest-page-size-on-resume.patch b/queue-4.19/virtio_mmio-restore-guest-page-size-on-resume.patch new file mode 100644 index 00000000000..d5516c1561b --- /dev/null +++ b/queue-4.19/virtio_mmio-restore-guest-page-size-on-resume.patch @@ -0,0 +1,44 @@ +From 5494a16f30288d7c8cccb146de916bff07cb425e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 21 Jun 2022 13:06:21 +0200 +Subject: virtio_mmio: Restore guest page size on resume + +From: Stephan Gerhold + +[ Upstream commit e0c2ce8217955537dd5434baeba061f209797119 ] + +Virtio devices might lose their state when the VMM is restarted +after a suspend to disk (hibernation) cycle. This means that the +guest page size register must be restored for the virtio_mmio legacy +interface, since otherwise the virtio queues are not functional. + +This is particularly problematic for QEMU that currently still defaults +to using the legacy interface for virtio_mmio. Write the guest page +size register again in virtio_mmio_restore() to make legacy virtio_mmio +devices work correctly after hibernation. + +Signed-off-by: Stephan Gerhold +Message-Id: <20220621110621.3638025-3-stephan.gerhold@kernkonzept.com> +Signed-off-by: Michael S. Tsirkin +Signed-off-by: Sasha Levin +--- + drivers/virtio/virtio_mmio.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c +index 79474bd0c52c..17cd682acc22 100644 +--- a/drivers/virtio/virtio_mmio.c ++++ b/drivers/virtio/virtio_mmio.c +@@ -521,6 +521,9 @@ static int virtio_mmio_restore(struct device *dev) + { + struct virtio_mmio_device *vm_dev = dev_get_drvdata(dev); + ++ if (vm_dev->version == 1) ++ writel(PAGE_SIZE, vm_dev->base + VIRTIO_MMIO_GUEST_PAGE_SIZE); ++ + return virtio_device_restore(&vm_dev->vdev); + } + +-- +2.35.1 + diff --git a/queue-4.19/x86-clear-.brk-area-at-early-boot.patch b/queue-4.19/x86-clear-.brk-area-at-early-boot.patch new file mode 100644 index 00000000000..68a505f3bdf --- /dev/null +++ b/queue-4.19/x86-clear-.brk-area-at-early-boot.patch @@ -0,0 +1,43 @@ +From 6e73aaf1fecfcffb34698dcbac74dde579b23534 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 30 Jun 2022 09:14:40 +0200 +Subject: x86: Clear .brk area at early boot + +From: Juergen Gross + +[ Upstream commit 38fa5479b41376dc9d7f57e71c83514285a25ca0 ] + +The .brk section has the same properties as .bss: it is an alloc-only +section and should be cleared before being used. + +Not doing so is especially a problem for Xen PV guests, as the +hypervisor will validate page tables (check for writable page tables +and hypervisor private bits) before accepting them to be used. + +Make sure .brk is initially zero by letting clear_bss() clear the brk +area, too. + +Signed-off-by: Juergen Gross +Signed-off-by: Borislav Petkov +Link: https://lore.kernel.org/r/20220630071441.28576-3-jgross@suse.com +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/head64.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c +index 88dc38b4a147..90c2613af36b 100644 +--- a/arch/x86/kernel/head64.c ++++ b/arch/x86/kernel/head64.c +@@ -383,6 +383,8 @@ static void __init clear_bss(void) + { + memset(__bss_start, 0, + (unsigned long) __bss_stop - (unsigned long) __bss_start); ++ memset(__brk_base, 0, ++ (unsigned long) __brk_limit - (unsigned long) __brk_base); + } + + static unsigned long get_cmd_line_ptr(void) +-- +2.35.1 +