From: Sasha Levin Date: Sun, 10 Apr 2022 02:06:29 +0000 (-0400) Subject: Fixes for 4.19 X-Git-Tag: v4.9.310~109 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=dddbfe6c848241b2f7f5d4aeff76acc178a0044c;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.19 Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/arm-9187-1-jive-fix-return-value-of-__setup-handler.patch b/queue-4.19/arm-9187-1-jive-fix-return-value-of-__setup-handler.patch new file mode 100644 index 00000000000..690f8e088d4 --- /dev/null +++ b/queue-4.19/arm-9187-1-jive-fix-return-value-of-__setup-handler.patch @@ -0,0 +1,61 @@ +From ba6adeae0678ba9015779a3ddd98962d00e48c5c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 12 Mar 2022 07:36:09 +0100 +Subject: ARM: 9187/1: JIVE: fix return value of __setup handler + +From: Randy Dunlap + +[ Upstream commit 8b2360c7157b462c4870d447d1e65d30ef31f9aa ] + +__setup() handlers should return 1 to obsolete_checksetup() in +init/main.c to indicate that the boot option has been handled. +A return of 0 causes the boot option/value to be listed as an Unknown +kernel parameter and added to init's (limited) argument or environment +strings. Also, error return codes don't mean anything to +obsolete_checksetup() -- only non-zero (usually 1) or zero. +So return 1 from jive_mtdset(). + +Fixes: 9db829f485c5 ("[ARM] JIVE: Initial machine support for Logitech Jive") +Signed-off-by: Randy Dunlap +Cc: Ben Dooks +Cc: Krzysztof Kozlowski +Cc: Alim Akhtar +Cc: linux-arm-kernel@lists.infradead.org +Cc: linux-samsung-soc@vger.kernel.org +Cc: patches@armlinux.org.uk +Signed-off-by: Russell King (Oracle) +Signed-off-by: Sasha Levin +--- + arch/arm/mach-s3c24xx/mach-jive.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c +index 885e8f12e4b9..eedc9f8ed210 100644 +--- a/arch/arm/mach-s3c24xx/mach-jive.c ++++ b/arch/arm/mach-s3c24xx/mach-jive.c +@@ -237,11 +237,11 @@ static int __init jive_mtdset(char *options) + unsigned long set; + + if (options == NULL || options[0] == '\0') +- return 0; ++ return 1; + + if (kstrtoul(options, 10, &set)) { + printk(KERN_ERR "failed to parse mtdset=%s\n", options); +- return 0; ++ return 1; + } + + switch (set) { +@@ -256,7 +256,7 @@ static int __init jive_mtdset(char *options) + "using default.", set); + } + +- return 0; ++ return 1; + } + + /* parse the mtdset= option given to the kernel command line */ +-- +2.35.1 + diff --git a/queue-4.19/ath5k-fix-oob-in-ath5k_eeprom_read_pcal_info_5111.patch b/queue-4.19/ath5k-fix-oob-in-ath5k_eeprom_read_pcal_info_5111.patch new file mode 100644 index 00000000000..516e1a587c2 --- /dev/null +++ b/queue-4.19/ath5k-fix-oob-in-ath5k_eeprom_read_pcal_info_5111.patch @@ -0,0 +1,87 @@ +From 620e726bae6e60f1eb4eb453c969baba6aeb0ffe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 26 Dec 2021 22:12:13 -0500 +Subject: ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111 + +From: Zekun Shen + +[ Upstream commit 564d4eceb97eaf381dd6ef6470b06377bb50c95a ] + +The bug was found during fuzzing. Stacktrace locates it in +ath5k_eeprom_convert_pcal_info_5111. +When none of the curve is selected in the loop, idx can go +up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound. +pd = &chinfo[pier].pd_curves[idx]; + +There are many OOB writes using pd later in the code. So I +added a sanity check for idx. Checks for other loops involving +AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not +used outside the loops. + +The patch is NOT tested with real device. + +The following is the fuzzing report + +BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] +Write of size 1 at addr ffff8880174a4d60 by task modprobe/214 + +CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1 +Call Trace: + dump_stack+0x76/0xa0 + print_address_description.constprop.0+0x16/0x200 + ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] + ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] + __kasan_report.cold+0x37/0x7c + ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] + kasan_report+0xe/0x20 + ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] + ? apic_timer_interrupt+0xa/0x20 + ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] + ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] + ath5k_eeprom_init+0x2513/0x6290 [ath5k] + ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] + ? usleep_range+0xb8/0x100 + ? apic_timer_interrupt+0xa/0x20 + ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] + ath5k_hw_init+0xb60/0x1970 [ath5k] + ath5k_init_ah+0x6fe/0x2530 [ath5k] + ? kasprintf+0xa6/0xe0 + ? ath5k_stop+0x140/0x140 [ath5k] + ? _dev_notice+0xf6/0xf6 + ? apic_timer_interrupt+0xa/0x20 + ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] + ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] + ? mutex_lock+0x89/0xd0 + ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] + local_pci_probe+0xd3/0x160 + pci_device_probe+0x23f/0x3e0 + ? pci_device_remove+0x280/0x280 + ? pci_device_remove+0x280/0x280 + really_probe+0x209/0x5d0 + +Reported-by: Brendan Dolan-Gavitt +Signed-off-by: Zekun Shen +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/YckvDdj3mtCkDRIt@a-10-27-26-18.dynapool.vpn.nyu.edu +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/ath/ath5k/eeprom.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/net/wireless/ath/ath5k/eeprom.c b/drivers/net/wireless/ath/ath5k/eeprom.c +index 94d34ee02265..01163b333945 100644 +--- a/drivers/net/wireless/ath/ath5k/eeprom.c ++++ b/drivers/net/wireless/ath/ath5k/eeprom.c +@@ -746,6 +746,9 @@ ath5k_eeprom_convert_pcal_info_5111(struct ath5k_hw *ah, int mode, + } + } + ++ if (idx == AR5K_EEPROM_N_PD_CURVES) ++ goto err_out; ++ + ee->ee_pd_gains[mode] = 1; + + pd = &chinfo[pier].pd_curves[idx]; +-- +2.35.1 + diff --git a/queue-4.19/bluetooth-fix-use-after-free-in-hci_send_acl.patch b/queue-4.19/bluetooth-fix-use-after-free-in-hci_send_acl.patch new file mode 100644 index 00000000000..a54d169d5bb --- /dev/null +++ b/queue-4.19/bluetooth-fix-use-after-free-in-hci_send_acl.patch @@ -0,0 +1,134 @@ +From db39add60b12bdc428b356c150b9d76aae271f04 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 11 Mar 2022 13:19:33 -0800 +Subject: Bluetooth: Fix use after free in hci_send_acl +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Luiz Augusto von Dentz + +[ Upstream commit f63d24baff787e13b723d86fe036f84bdbc35045 ] + +This fixes the following trace caused by receiving +HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without +first checking if conn->type is in fact AMP_LINK and in case it is +do properly cleanup upper layers with hci_disconn_cfm: + + ================================================================== + BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 + Read of size 8 at addr ffff88800e404818 by task bluetoothd/142 + + CPU: 0 PID: 142 Comm: bluetoothd Not tainted + 5.17.0-rc5-00006-gda4022eeac1a #7 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS + rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 + Call Trace: + + dump_stack_lvl+0x45/0x59 + print_address_description.constprop.0+0x1f/0x150 + kasan_report.cold+0x7f/0x11b + hci_send_acl+0xaba/0xc50 + l2cap_do_send+0x23f/0x3d0 + l2cap_chan_send+0xc06/0x2cc0 + l2cap_sock_sendmsg+0x201/0x2b0 + sock_sendmsg+0xdc/0x110 + sock_write_iter+0x20f/0x370 + do_iter_readv_writev+0x343/0x690 + do_iter_write+0x132/0x640 + vfs_writev+0x198/0x570 + do_writev+0x202/0x280 + do_syscall_64+0x38/0x90 + entry_SYSCALL_64_after_hwframe+0x44/0xae + RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 + Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 + 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05 + <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 + RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015 + RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77 + R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580 + RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001 + + R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0 + + Allocated by task 45: + kasan_save_stack+0x1e/0x40 + __kasan_kmalloc+0x81/0xa0 + hci_chan_create+0x9a/0x2f0 + l2cap_conn_add.part.0+0x1a/0xdc0 + l2cap_connect_cfm+0x236/0x1000 + le_conn_complete_evt+0x15a7/0x1db0 + hci_le_conn_complete_evt+0x226/0x2c0 + hci_le_meta_evt+0x247/0x450 + hci_event_packet+0x61b/0xe90 + hci_rx_work+0x4d5/0xc50 + process_one_work+0x8fb/0x15a0 + worker_thread+0x576/0x1240 + kthread+0x29d/0x340 + ret_from_fork+0x1f/0x30 + + Freed by task 45: + kasan_save_stack+0x1e/0x40 + kasan_set_track+0x21/0x30 + kasan_set_free_info+0x20/0x30 + __kasan_slab_free+0xfb/0x130 + kfree+0xac/0x350 + hci_conn_cleanup+0x101/0x6a0 + hci_conn_del+0x27e/0x6c0 + hci_disconn_phylink_complete_evt+0xe0/0x120 + hci_event_packet+0x812/0xe90 + hci_rx_work+0x4d5/0xc50 + process_one_work+0x8fb/0x15a0 + worker_thread+0x576/0x1240 + kthread+0x29d/0x340 + ret_from_fork+0x1f/0x30 + + The buggy address belongs to the object at ffff88800c0f0500 + The buggy address is located 24 bytes inside of + which belongs to the cache kmalloc-128 of size 128 + The buggy address belongs to the page: + 128-byte region [ffff88800c0f0500, ffff88800c0f0580) + flags: 0x100000000000200(slab|node=0|zone=1) + page:00000000fe45cd86 refcount:1 mapcount:0 + mapping:0000000000000000 index:0x0 pfn:0xc0f0 + raw: 0000000000000000 0000000080100010 00000001ffffffff + 0000000000000000 + raw: 0100000000000200 ffffea00003a2c80 dead000000000004 + ffff8880078418c0 + page dumped because: kasan: bad access detected + ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc + Memory state around the buggy address: + >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + ^ + ================================================================== + ffff88800c0f0600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + +Reported-by: Sönke Huster +Tested-by: Sönke Huster +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Marcel Holtmann +Signed-off-by: Sasha Levin +--- + net/bluetooth/hci_event.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c +index 196d0d832007..dd7bf437d88e 100644 +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -4792,8 +4792,9 @@ static void hci_disconn_phylink_complete_evt(struct hci_dev *hdev, + hci_dev_lock(hdev); + + hcon = hci_conn_hash_lookup_handle(hdev, ev->phy_handle); +- if (hcon) { ++ if (hcon && hcon->type == AMP_LINK) { + hcon->state = BT_CLOSED; ++ hci_disconn_cfm(hcon, ev->reason); + hci_conn_del(hcon); + } + +-- +2.35.1 + diff --git a/queue-4.19/bnxt_en-eliminate-unintended-link-toggle-during-fw-r.patch b/queue-4.19/bnxt_en-eliminate-unintended-link-toggle-during-fw-r.patch new file mode 100644 index 00000000000..bc7a01e0487 --- /dev/null +++ b/queue-4.19/bnxt_en-eliminate-unintended-link-toggle-during-fw-r.patch @@ -0,0 +1,47 @@ +From 7554a442f2303438583dc32d6364199f1242def0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 5 Mar 2022 03:54:39 -0500 +Subject: bnxt_en: Eliminate unintended link toggle during FW reset + +From: Michael Chan + +[ Upstream commit 7c492a2530c1f05441da541307c2534230dfd59b ] + +If the flow control settings have been changed, a subsequent FW reset +may cause the ethernet link to toggle unnecessarily. This link toggle +will increase the down time by a few seconds. + +The problem is caused by bnxt_update_phy_setting() detecting a false +mismatch in the flow control settings between the stored software +settings and the current FW settings after the FW reset. This mismatch +is caused by the AUTONEG bit added to link_info->req_flow_ctrl in an +inconsistent way in bnxt_set_pauseparam() in autoneg mode. The AUTONEG +bit should not be added to link_info->req_flow_ctrl. + +Reviewed-by: Colin Winegarden +Reviewed-by: Pavan Chebbi +Signed-off-by: Michael Chan +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c +index e75a47a9f511..deba77670b1c 100644 +--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c ++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c +@@ -1377,9 +1377,7 @@ static int bnxt_set_pauseparam(struct net_device *dev, + } + + link_info->autoneg |= BNXT_AUTONEG_FLOW_CTRL; +- if (bp->hwrm_spec_code >= 0x10201) +- link_info->req_flow_ctrl = +- PORT_PHY_CFG_REQ_AUTO_PAUSE_AUTONEG_PAUSE; ++ link_info->req_flow_ctrl = 0; + } else { + /* when transition from auto pause to force pause, + * force a link change +-- +2.35.1 + diff --git a/queue-4.19/clk-enforce-that-disjoints-limits-are-invalid.patch b/queue-4.19/clk-enforce-that-disjoints-limits-are-invalid.patch new file mode 100644 index 00000000000..00d7540ee54 --- /dev/null +++ b/queue-4.19/clk-enforce-that-disjoints-limits-are-invalid.patch @@ -0,0 +1,103 @@ +From 59b72ab798990b82299b34a83bd3e836516b1042 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 25 Feb 2022 15:35:25 +0100 +Subject: clk: Enforce that disjoints limits are invalid + +From: Maxime Ripard + +[ Upstream commit 10c46f2ea914202482d19cf80dcc9c321c9ff59b ] + +If we were to have two users of the same clock, doing something like: + +clk_set_rate_range(user1, 1000, 2000); +clk_set_rate_range(user2, 3000, 4000); + +The second call would fail with -EINVAL, preventing from getting in a +situation where we end up with impossible limits. + +However, this is never explicitly checked against and enforced, and +works by relying on an undocumented behaviour of clk_set_rate(). + +Indeed, on the first clk_set_rate_range will make sure the current clock +rate is within the new range, so it will be between 1000 and 2000Hz. On +the second clk_set_rate_range(), it will consider (rightfully), that our +current clock is outside of the 3000-4000Hz range, and will call +clk_core_set_rate_nolock() to set it to 3000Hz. + +clk_core_set_rate_nolock() will then call clk_calc_new_rates() that will +eventually check that our rate 3000Hz rate is outside the min 3000Hz max +2000Hz range, will bail out, the error will propagate and we'll +eventually return -EINVAL. + +This solely relies on the fact that clk_calc_new_rates(), and in +particular clk_core_determine_round_nolock(), won't modify the new rate +allowing the error to be reported. That assumption won't be true for all +drivers, and most importantly we'll break that assumption in a later +patch. + +It can also be argued that we shouldn't even reach the point where we're +calling clk_core_set_rate_nolock(). + +Let's make an explicit check for disjoints range before we're doing +anything. + +Signed-off-by: Maxime Ripard +Link: https://lore.kernel.org/r/20220225143534.405820-4-maxime@cerno.tech +Signed-off-by: Stephen Boyd +Signed-off-by: Sasha Levin +--- + drivers/clk/clk.c | 24 ++++++++++++++++++++++++ + 1 file changed, 24 insertions(+) + +diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c +index a9490c8e82a7..32606d1094fe 100644 +--- a/drivers/clk/clk.c ++++ b/drivers/clk/clk.c +@@ -523,6 +523,24 @@ static void clk_core_get_boundaries(struct clk_core *core, + *max_rate = min(*max_rate, clk_user->max_rate); + } + ++static bool clk_core_check_boundaries(struct clk_core *core, ++ unsigned long min_rate, ++ unsigned long max_rate) ++{ ++ struct clk *user; ++ ++ lockdep_assert_held(&prepare_lock); ++ ++ if (min_rate > core->max_rate || max_rate < core->min_rate) ++ return false; ++ ++ hlist_for_each_entry(user, &core->clks, clks_node) ++ if (min_rate > user->max_rate || max_rate < user->min_rate) ++ return false; ++ ++ return true; ++} ++ + void clk_hw_set_rate_range(struct clk_hw *hw, unsigned long min_rate, + unsigned long max_rate) + { +@@ -2066,6 +2084,11 @@ int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max) + clk->min_rate = min; + clk->max_rate = max; + ++ if (!clk_core_check_boundaries(clk->core, min, max)) { ++ ret = -EINVAL; ++ goto out; ++ } ++ + rate = clk_core_get_rate_nolock(clk->core); + if (rate < min || rate > max) { + /* +@@ -2094,6 +2117,7 @@ int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max) + } + } + ++out: + if (clk->exclusive_count) + clk_core_rate_protect(clk->core); + +-- +2.35.1 + diff --git a/queue-4.19/dm-ioctl-prevent-potential-spectre-v1-gadget.patch b/queue-4.19/dm-ioctl-prevent-potential-spectre-v1-gadget.patch new file mode 100644 index 00000000000..2b1412db092 --- /dev/null +++ b/queue-4.19/dm-ioctl-prevent-potential-spectre-v1-gadget.patch @@ -0,0 +1,44 @@ +From 1b52ab44ce597173825c3ac0df0fe07eb6714d99 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 29 Jan 2022 15:58:39 +0100 +Subject: dm ioctl: prevent potential spectre v1 gadget + +From: Jordy Zomer + +[ Upstream commit cd9c88da171a62c4b0f1c70e50c75845969fbc18 ] + +It appears like cmd could be a Spectre v1 gadget as it's supplied by a +user and used as an array index. Prevent the contents of kernel memory +from being leaked to userspace via speculative execution by using +array_index_nospec. + +Signed-off-by: Jordy Zomer +Signed-off-by: Mike Snitzer +Signed-off-by: Sasha Levin +--- + drivers/md/dm-ioctl.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c +index 17cbad58834f..0aae4a46db66 100644 +--- a/drivers/md/dm-ioctl.c ++++ b/drivers/md/dm-ioctl.c +@@ -17,6 +17,7 @@ + #include + #include + #include ++#include + + #include + +@@ -1670,6 +1671,7 @@ static ioctl_fn lookup_ioctl(unsigned int cmd, int *ioctl_flags) + if (unlikely(cmd >= ARRAY_SIZE(_ioctls))) + return NULL; + ++ cmd = array_index_nospec(cmd, ARRAY_SIZE(_ioctls)); + *ioctl_flags = _ioctls[cmd].flags; + return _ioctls[cmd].fn; + } +-- +2.35.1 + diff --git a/queue-4.19/drm-add-orientation-quirk-for-gpd-win-max.patch b/queue-4.19/drm-add-orientation-quirk-for-gpd-win-max.patch new file mode 100644 index 00000000000..1e042417f23 --- /dev/null +++ b/queue-4.19/drm-add-orientation-quirk-for-gpd-win-max.patch @@ -0,0 +1,40 @@ +From 3735e06c86cf765412b021a813ba159e3e8b99c4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 29 Dec 2021 23:22:00 +0100 +Subject: drm: Add orientation quirk for GPD Win Max + +From: Anisse Astier + +[ Upstream commit 0b464ca3e0dd3cec65f28bc6d396d82f19080f69 ] + +Panel is 800x1280, but mounted on a laptop form factor, sideways. + +Signed-off-by: Anisse Astier +Reviewed-by: Hans de Goede +Signed-off-by: Jani Nikula +Link: https://patchwork.freedesktop.org/patch/msgid/20211229222200.53128-3-anisse@astier.eu +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c b/drivers/gpu/drm/drm_panel_orientation_quirks.c +index 3b70a338e5b4..265df1e67eb3 100644 +--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c ++++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c +@@ -133,6 +133,12 @@ static const struct dmi_system_id orientation_data[] = { + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "MicroPC"), + }, + .driver_data = (void *)&lcd720x1280_rightside_up, ++ }, { /* GPD Win Max */ ++ .matches = { ++ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"), ++ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1619-01"), ++ }, ++ .driver_data = (void *)&lcd800x1280_rightside_up, + }, { /* + * GPD Pocket, note that the the DMI data is less generic then + * it seems, devices with a board-vendor of "AMI Corporation" +-- +2.35.1 + diff --git a/queue-4.19/drm-amd-amdgpu-amdgpu_cs-fix-refcount-leak-of-a-dma_.patch b/queue-4.19/drm-amd-amdgpu-amdgpu_cs-fix-refcount-leak-of-a-dma_.patch new file mode 100644 index 00000000000..36133a14f25 --- /dev/null +++ b/queue-4.19/drm-amd-amdgpu-amdgpu_cs-fix-refcount-leak-of-a-dma_.patch @@ -0,0 +1,46 @@ +From 99d5afa21a90d362c3442244dc95468167a6c165 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 21 Jan 2022 15:46:23 -0500 +Subject: drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Xin Xiong + +[ Upstream commit dfced44f122c500004a48ecc8db516bb6a295a1b ] + +This issue takes place in an error path in +amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into +default case, the function simply returns -EINVAL, forgetting to +decrement the reference count of a dma_fence obj, which is bumped +earlier by amdgpu_cs_get_fence(). This may result in reference count +leaks. + +Fix it by decreasing the refcount of specific object before returning +the error code. + +Reviewed-by: Christian König +Signed-off-by: Xin Xiong +Signed-off-by: Xin Tan +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +index 81001d879322..023309296bfc 100644 +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +@@ -1469,6 +1469,7 @@ int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data, + return 0; + + default: ++ dma_fence_put(fence); + return -EINVAL; + } + } +-- +2.35.1 + diff --git a/queue-4.19/drm-amdkfd-make-crat-table-missing-message-informati.patch b/queue-4.19/drm-amdkfd-make-crat-table-missing-message-informati.patch new file mode 100644 index 00000000000..05b7cbfa231 --- /dev/null +++ b/queue-4.19/drm-amdkfd-make-crat-table-missing-message-informati.patch @@ -0,0 +1,38 @@ +From d0c343246cbec24f4c7ad5bba0a9fc36ec7127d6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 18 Feb 2022 15:40:12 -0500 +Subject: drm/amdkfd: make CRAT table missing message informational only + +From: Alex Deucher + +[ Upstream commit 9dff13f9edf755a15f6507874185a3290c1ae8bb ] + +The driver has a fallback so make the message informational +rather than a warning. The driver has a fallback if the +Component Resource Association Table (CRAT) is missing, so +make this informational now. + +Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1906 +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c +index ee4996029a86..e2780643f4c3 100644 +--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c +@@ -733,7 +733,7 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t *size) + /* Fetch the CRAT table from ACPI */ + status = acpi_get_table(CRAT_SIGNATURE, 0, &crat_table); + if (status == AE_NOT_FOUND) { +- pr_warn("CRAT table not found\n"); ++ pr_info("CRAT table not found\n"); + return -ENODATA; + } else if (ACPI_FAILURE(status)) { + const char *err = acpi_format_exception(status); +-- +2.35.1 + diff --git a/queue-4.19/init-main.c-return-1-from-handled-__setup-functions.patch b/queue-4.19/init-main.c-return-1-from-handled-__setup-functions.patch new file mode 100644 index 00000000000..3bbe6f960ca --- /dev/null +++ b/queue-4.19/init-main.c-return-1-from-handled-__setup-functions.patch @@ -0,0 +1,57 @@ +From f00d96055942b9d33d2c6a27d2b6696d2f6db032 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 23 Mar 2022 16:06:14 -0700 +Subject: init/main.c: return 1 from handled __setup() functions + +From: Randy Dunlap + +[ Upstream commit f9a40b0890658330c83c95511f9d6b396610defc ] + +initcall_blacklist() should return 1 to indicate that it handled its +cmdline arguments. + +set_debug_rodata() should return 1 to indicate that it handled its +cmdline arguments. Print a warning if the option string is invalid. + +This prevents these strings from being added to the 'init' program's +environment as they are not init arguments/parameters. + +Link: https://lkml.kernel.org/r/20220221050901.23985-1-rdunlap@infradead.org +Signed-off-by: Randy Dunlap +Reported-by: Igor Zhbanov +Cc: Ingo Molnar +Cc: Greg Kroah-Hartman +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + init/main.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/init/main.c b/init/main.c +index 7baad67c2e93..272ec131211c 100644 +--- a/init/main.c ++++ b/init/main.c +@@ -774,7 +774,7 @@ static int __init initcall_blacklist(char *str) + } + } while (str_entry); + +- return 0; ++ return 1; + } + + static bool __init_or_module initcall_blacklisted(initcall_t fn) +@@ -1027,7 +1027,9 @@ static noinline void __init kernel_init_freeable(void); + bool rodata_enabled __ro_after_init = true; + static int __init set_debug_rodata(char *str) + { +- return strtobool(str, &rodata_enabled); ++ if (strtobool(str, &rodata_enabled)) ++ pr_warn("Invalid option string for rodata: '%s'\n", str); ++ return 1; + } + __setup("rodata=", set_debug_rodata); + #endif +-- +2.35.1 + diff --git a/queue-4.19/iommu-arm-smmu-v3-fix-event-handling-soft-lockup.patch b/queue-4.19/iommu-arm-smmu-v3-fix-event-handling-soft-lockup.patch new file mode 100644 index 00000000000..a4581dff284 --- /dev/null +++ b/queue-4.19/iommu-arm-smmu-v3-fix-event-handling-soft-lockup.patch @@ -0,0 +1,55 @@ +From b0be17b0022430630ca1cdc71c0b929dd5eaf499 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 19 Jan 2022 07:07:54 +0000 +Subject: iommu/arm-smmu-v3: fix event handling soft lockup + +From: Zhou Guanghui + +[ Upstream commit 30de2b541af98179780054836b48825fcfba4408 ] + +During event processing, events are read from the event queue one +by one until the queue is empty.If the master device continuously +requests address access at the same time and the SMMU generates +events, the cyclic processing of the event takes a long time and +softlockup warnings may be reported. + +arm-smmu-v3 arm-smmu-v3.34.auto: event 0x0a received: +arm-smmu-v3 arm-smmu-v3.34.auto: 0x00007f220000280a +arm-smmu-v3 arm-smmu-v3.34.auto: 0x000010000000007e +arm-smmu-v3 arm-smmu-v3.34.auto: 0x00000000034e8670 +watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [irq/268-arm-smm:247] +Call trace: + _dev_info+0x7c/0xa0 + arm_smmu_evtq_thread+0x1c0/0x230 + irq_thread_fn+0x30/0x80 + irq_thread+0x128/0x210 + kthread+0x134/0x138 + ret_from_fork+0x10/0x1c +Kernel panic - not syncing: softlockup: hung tasks + +Fix this by calling cond_resched() after the event information is +printed. + +Signed-off-by: Zhou Guanghui +Link: https://lore.kernel.org/r/20220119070754.26528-1-zhouguanghui1@huawei.com +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + drivers/iommu/arm-smmu-v3.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c +index 6b7664052b5b..9f16f47e7021 100644 +--- a/drivers/iommu/arm-smmu-v3.c ++++ b/drivers/iommu/arm-smmu-v3.c +@@ -1250,6 +1250,7 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev) + dev_info(smmu->dev, "\t0x%016llx\n", + (unsigned long long)evt[i]); + ++ cond_resched(); + } + + /* +-- +2.35.1 + diff --git a/queue-4.19/ipv4-invalidate-neighbour-for-broadcast-address-upon.patch b/queue-4.19/ipv4-invalidate-neighbour-for-broadcast-address-upon.patch new file mode 100644 index 00000000000..c8e9d250c00 --- /dev/null +++ b/queue-4.19/ipv4-invalidate-neighbour-for-broadcast-address-upon.patch @@ -0,0 +1,118 @@ +From 1f3cc69744ceb28d668928a8533ea1a43ac7fd83 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 19 Feb 2022 17:45:19 +0200 +Subject: ipv4: Invalidate neighbour for broadcast address upon address + addition + +From: Ido Schimmel + +[ Upstream commit 0c51e12e218f20b7d976158fdc18019627326f7a ] + +In case user space sends a packet destined to a broadcast address when a +matching broadcast route is not configured, the kernel will create a +unicast neighbour entry that will never be resolved [1]. + +When the broadcast route is configured, the unicast neighbour entry will +not be invalidated and continue to linger, resulting in packets being +dropped. + +Solve this by invalidating unresolved neighbour entries for broadcast +addresses after routes for these addresses are internally configured by +the kernel. This allows the kernel to create a broadcast neighbour entry +following the next route lookup. + +Another possible solution that is more generic but also more complex is +to have the ARP code register a listener to the FIB notification chain +and invalidate matching neighbour entries upon the addition of broadcast +routes. + +It is also possible to wave off the issue as a user space problem, but +it seems a bit excessive to expect user space to be that intimately +familiar with the inner workings of the FIB/neighbour kernel code. + +[1] https://lore.kernel.org/netdev/55a04a8f-56f3-f73c-2aea-2195923f09d1@huawei.com/ + +Reported-by: Wang Hai +Signed-off-by: Ido Schimmel +Tested-by: Wang Hai +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + include/net/arp.h | 1 + + net/ipv4/arp.c | 9 +++++++-- + net/ipv4/fib_frontend.c | 5 ++++- + 3 files changed, 12 insertions(+), 3 deletions(-) + +diff --git a/include/net/arp.h b/include/net/arp.h +index c8f580a0e6b1..dc6e9dd3e1e6 100644 +--- a/include/net/arp.h ++++ b/include/net/arp.h +@@ -71,6 +71,7 @@ void arp_send(int type, int ptype, __be32 dest_ip, + const unsigned char *src_hw, const unsigned char *th); + int arp_mc_map(__be32 addr, u8 *haddr, struct net_device *dev, int dir); + void arp_ifdown(struct net_device *dev); ++int arp_invalidate(struct net_device *dev, __be32 ip, bool force); + + struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip, + struct net_device *dev, __be32 src_ip, +diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c +index e90c89ef8c08..b18b2a3c54ad 100644 +--- a/net/ipv4/arp.c ++++ b/net/ipv4/arp.c +@@ -1114,13 +1114,18 @@ static int arp_req_get(struct arpreq *r, struct net_device *dev) + return err; + } + +-static int arp_invalidate(struct net_device *dev, __be32 ip) ++int arp_invalidate(struct net_device *dev, __be32 ip, bool force) + { + struct neighbour *neigh = neigh_lookup(&arp_tbl, &ip, dev); + int err = -ENXIO; + struct neigh_table *tbl = &arp_tbl; + + if (neigh) { ++ if ((neigh->nud_state & NUD_VALID) && !force) { ++ neigh_release(neigh); ++ return 0; ++ } ++ + if (neigh->nud_state & ~NUD_NOARP) + err = neigh_update(neigh, NULL, NUD_FAILED, + NEIGH_UPDATE_F_OVERRIDE| +@@ -1167,7 +1172,7 @@ static int arp_req_delete(struct net *net, struct arpreq *r, + if (!dev) + return -EINVAL; + } +- return arp_invalidate(dev, ip); ++ return arp_invalidate(dev, ip, true); + } + + /* +diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c +index 70e5e9e5d835..1885a2fbad86 100644 +--- a/net/ipv4/fib_frontend.c ++++ b/net/ipv4/fib_frontend.c +@@ -917,9 +917,11 @@ void fib_add_ifaddr(struct in_ifaddr *ifa) + return; + + /* Add broadcast address, if it is explicitly assigned. */ +- if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0xFFFFFFFF)) ++ if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0xFFFFFFFF)) { + fib_magic(RTM_NEWROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, + prim, 0); ++ arp_invalidate(dev, ifa->ifa_broadcast, false); ++ } + + if (!ipv4_is_zeronet(prefix) && !(ifa->ifa_flags & IFA_F_SECONDARY) && + (prefix != addr || ifa->ifa_prefixlen < 32)) { +@@ -935,6 +937,7 @@ void fib_add_ifaddr(struct in_ifaddr *ifa) + prim, 0); + fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix | ~mask, + 32, prim, 0); ++ arp_invalidate(dev, prefix | ~mask, false); + } + } + } +-- +2.35.1 + diff --git a/queue-4.19/jfs-prevent-null-deref-in-difree.patch b/queue-4.19/jfs-prevent-null-deref-in-difree.patch new file mode 100644 index 00000000000..204832f5c3d --- /dev/null +++ b/queue-4.19/jfs-prevent-null-deref-in-difree.patch @@ -0,0 +1,48 @@ +From dff6fefcf16fb15e2974b43bb53fba4ee7f3273a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Mar 2022 21:59:17 +0800 +Subject: jfs: prevent NULL deref in diFree + +From: Haimin Zhang + +[ Upstream commit a53046291020ec41e09181396c1e829287b48d47 ] + +Add validation check for JFS_IP(ipimap)->i_imap to prevent a NULL deref +in diFree since diFree uses it without do any validations. +When function jfs_mount calls diMount to initialize fileset inode +allocation map, it can fail and JFS_IP(ipimap)->i_imap won't be +initialized. Then it calls diFreeSpecial to close fileset inode allocation +map inode and it will flow into jfs_evict_inode. Function jfs_evict_inode +just validates JFS_SBI(inode->i_sb)->ipimap, then calls diFree. diFree use +JFS_IP(ipimap)->i_imap directly, then it will cause a NULL deref. + +Reported-by: TCS Robot +Signed-off-by: Haimin Zhang +Signed-off-by: Dave Kleikamp +Signed-off-by: Sasha Levin +--- + fs/jfs/inode.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/fs/jfs/inode.c b/fs/jfs/inode.c +index 87b41edc800d..68779cc3609a 100644 +--- a/fs/jfs/inode.c ++++ b/fs/jfs/inode.c +@@ -156,12 +156,13 @@ void jfs_evict_inode(struct inode *inode) + dquot_initialize(inode); + + if (JFS_IP(inode)->fileset == FILESYSTEM_I) { ++ struct inode *ipimap = JFS_SBI(inode->i_sb)->ipimap; + truncate_inode_pages_final(&inode->i_data); + + if (test_cflag(COMMIT_Freewmap, inode)) + jfs_free_zero_link(inode); + +- if (JFS_SBI(inode->i_sb)->ipimap) ++ if (ipimap && JFS_IP(ipimap)->i_imap) + diFree(inode); + + /* +-- +2.35.1 + diff --git a/queue-4.19/kvm-arm64-check-arm64_get_bp_hardening_data-didn-t-r.patch b/queue-4.19/kvm-arm64-check-arm64_get_bp_hardening_data-didn-t-r.patch new file mode 100644 index 00000000000..f0353cd27ce --- /dev/null +++ b/queue-4.19/kvm-arm64-check-arm64_get_bp_hardening_data-didn-t-r.patch @@ -0,0 +1,63 @@ +From a5603c7a34e01797b8b11850e7bd77693b0a1abf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 8 Apr 2022 18:22:32 +0100 +Subject: KVM: arm64: Check arm64_get_bp_hardening_data() didn't return NULL + +From: James Morse + +Will reports that with CONFIG_EXPERT=y and CONFIG_HARDEN_BRANCH_PREDICTOR=n, +the kernel dereferences a NULL pointer during boot: + +[ 2.384444] Internal error: Oops: 96000004 [#1] PREEMPT SMP +[ 2.384461] pstate: 20400085 (nzCv daIf +PAN -UAO) +[ 2.384472] pc : cpu_hyp_reinit+0x114/0x30c +[ 2.384476] lr : cpu_hyp_reinit+0x80/0x30c + +[ 2.384529] Call trace: +[ 2.384533] cpu_hyp_reinit+0x114/0x30c +[ 2.384537] _kvm_arch_hardware_enable+0x30/0x54 +[ 2.384541] flush_smp_call_function_queue+0xe4/0x154 +[ 2.384544] generic_smp_call_function_single_interrupt+0x10/0x18 +[ 2.384549] ipi_handler+0x170/0x2b0 +[ 2.384555] handle_percpu_devid_fasteoi_ipi+0x120/0x1cc +[ 2.384560] __handle_domain_irq+0x9c/0xf4 +[ 2.384563] gic_handle_irq+0x6c/0xe4 +[ 2.384566] el1_irq+0xf0/0x1c0 +[ 2.384570] arch_cpu_idle+0x28/0x44 +[ 2.384574] do_idle+0x100/0x2a8 +[ 2.384577] cpu_startup_entry+0x20/0x24 +[ 2.384581] secondary_start_kernel+0x1b0/0x1cc +[ 2.384589] Code: b9469d08 7100011f 540003ad 52800208 (f9400108) +[ 2.384600] ---[ end trace 266d08dbf96ff143 ]--- +[ 2.385171] Kernel panic - not syncing: Fatal exception in interrupt + +In this configuration arm64_get_bp_hardening_data() returns NULL. +Add a check in kvm_get_hyp_vector(). + +Cc: Will Deacon +Link: https://lore.kernel.org/linux-arm-kernel/20220408120041.GB27685@willie-the-truck/ +Fixes: a68912a3ae3 ("KVM: arm64: Add templates for BHB mitigation sequences") +Cc: stable@vger.kernel.org # 4.19 +Signed-off-by: James Morse +Signed-off-by: Sasha Levin +--- + arch/arm64/include/asm/kvm_mmu.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h +index 44d3fdbcdf62..0243b6d22453 100644 +--- a/arch/arm64/include/asm/kvm_mmu.h ++++ b/arch/arm64/include/asm/kvm_mmu.h +@@ -439,7 +439,8 @@ static inline void *kvm_get_hyp_vector(void) + int slot = -1; + + if ((cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR) || +- cpus_have_const_cap(ARM64_SPECTRE_BHB)) && data->template_start) { ++ cpus_have_const_cap(ARM64_SPECTRE_BHB)) && ++ data && data->template_start) { + vect = kern_hyp_va(kvm_ksym_ref(__bp_harden_hyp_vecs_start)); + slot = data->hyp_vectors_slot; + } +-- +2.35.1 + diff --git a/queue-4.19/kvm-x86-svm-clear-reserved-bits-written-to-perfevtse.patch b/queue-4.19/kvm-x86-svm-clear-reserved-bits-written-to-perfevtse.patch new file mode 100644 index 00000000000..c8666663069 --- /dev/null +++ b/queue-4.19/kvm-x86-svm-clear-reserved-bits-written-to-perfevtse.patch @@ -0,0 +1,74 @@ +From 22f50668b4019cc8301de6ff288935000d204610 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 26 Feb 2022 15:41:31 -0800 +Subject: KVM: x86/svm: Clear reserved bits written to PerfEvtSeln MSRs + +From: Jim Mattson + +[ Upstream commit 9b026073db2f1ad0e4d8b61c83316c8497981037 ] + +AMD EPYC CPUs never raise a #GP for a WRMSR to a PerfEvtSeln MSR. Some +reserved bits are cleared, and some are not. Specifically, on +Zen3/Milan, bits 19 and 42 are not cleared. + +When emulating such a WRMSR, KVM should not synthesize a #GP, +regardless of which bits are set. However, undocumented bits should +not be passed through to the hardware MSR. So, rather than checking +for reserved bits and synthesizing a #GP, just clear the reserved +bits. + +This may seem pedantic, but since KVM currently does not support the +"Host/Guest Only" bits (41:40), it is necessary to clear these bits +rather than synthesizing #GP, because some popular guests (e.g Linux) +will set the "Host Only" bit even on CPUs that don't support +EFER.SVME, and they don't expect a #GP. + +For example, + +root@Ubuntu1804:~# perf stat -e r26 -a sleep 1 + + Performance counter stats for 'system wide': + + 0 r26 + + 1.001070977 seconds time elapsed + +Feb 23 03:59:58 Ubuntu1804 kernel: [ 405.379957] unchecked MSR access error: WRMSR to 0xc0010200 (tried to write 0x0000020000130026) at rIP: 0xffffffff9b276a28 (native_write_msr+0x8/0x30) +Feb 23 03:59:58 Ubuntu1804 kernel: [ 405.379958] Call Trace: +Feb 23 03:59:58 Ubuntu1804 kernel: [ 405.379963] amd_pmu_disable_event+0x27/0x90 + +Fixes: ca724305a2b0 ("KVM: x86/vPMU: Implement AMD vPMU code for KVM") +Reported-by: Lotus Fenn +Signed-off-by: Jim Mattson +Reviewed-by: Like Xu +Reviewed-by: David Dunn +Message-Id: <20220226234131.2167175-1-jmattson@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Sasha Levin +--- + arch/x86/kvm/pmu_amd.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +diff --git a/arch/x86/kvm/pmu_amd.c b/arch/x86/kvm/pmu_amd.c +index 41dff881e0f0..93a135f216b2 100644 +--- a/arch/x86/kvm/pmu_amd.c ++++ b/arch/x86/kvm/pmu_amd.c +@@ -247,12 +247,10 @@ static int amd_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) + /* MSR_EVNTSELn */ + pmc = get_gp_pmc_amd(pmu, msr, PMU_TYPE_EVNTSEL); + if (pmc) { +- if (data == pmc->eventsel) +- return 0; +- if (!(data & pmu->reserved_bits)) { ++ data &= ~pmu->reserved_bits; ++ if (data != pmc->eventsel) + reprogram_gp_counter(pmc, data); +- return 0; +- } ++ return 0; + } + + return 1; +-- +2.35.1 + diff --git a/queue-4.19/macvtap-advertise-link-netns-via-netlink.patch b/queue-4.19/macvtap-advertise-link-netns-via-netlink.patch new file mode 100644 index 00000000000..73d8d20d93b --- /dev/null +++ b/queue-4.19/macvtap-advertise-link-netns-via-netlink.patch @@ -0,0 +1,68 @@ +From 9c0453816b995473612bdfbda3d1bbe4c7d2f7de Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 28 Feb 2022 01:32:40 +0100 +Subject: macvtap: advertise link netns via netlink +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Sven Eckelmann + +[ Upstream commit a02192151b7dbf855084c38dca380d77c7658353 ] + +Assign rtnl_link_ops->get_link_net() callback so that IFLA_LINK_NETNSID is +added to rtnetlink messages. This fixes iproute2 which otherwise resolved +the link interface to an interface in the wrong namespace. + +Test commands: + + ip netns add nst + ip link add dummy0 type dummy + ip link add link macvtap0 link dummy0 type macvtap + ip link set macvtap0 netns nst + ip -netns nst link show macvtap0 + +Before: + + 10: macvtap0@gre0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 500 + link/ether 5e:8f:ae:1d:60:50 brd ff:ff:ff:ff:ff:ff + +After: + + 10: macvtap0@if2: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 500 + link/ether 5e:8f:ae:1d:60:50 brd ff:ff:ff:ff:ff:ff link-netnsid 0 + +Reported-by: Leonardo Mörlein +Signed-off-by: Sven Eckelmann +Link: https://lore.kernel.org/r/20220228003240.1337426-1-sven@narfation.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/macvtap.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c +index 9a10029caf83..085f1648a8a6 100644 +--- a/drivers/net/macvtap.c ++++ b/drivers/net/macvtap.c +@@ -132,11 +132,17 @@ static void macvtap_setup(struct net_device *dev) + dev->tx_queue_len = TUN_READQ_SIZE; + } + ++static struct net *macvtap_link_net(const struct net_device *dev) ++{ ++ return dev_net(macvlan_dev_real_dev(dev)); ++} ++ + static struct rtnl_link_ops macvtap_link_ops __read_mostly = { + .kind = "macvtap", + .setup = macvtap_setup, + .newlink = macvtap_newlink, + .dellink = macvtap_dellink, ++ .get_link_net = macvtap_link_net, + .priv_size = sizeof(struct macvtap_dev), + }; + +-- +2.35.1 + diff --git a/queue-4.19/minix-fix-bug-when-opening-a-file-with-o_direct.patch b/queue-4.19/minix-fix-bug-when-opening-a-file-with-o_direct.patch new file mode 100644 index 00000000000..a722d482035 --- /dev/null +++ b/queue-4.19/minix-fix-bug-when-opening-a-file-with-o_direct.patch @@ -0,0 +1,48 @@ +From 4ffa8a0ca5e0931016db6be5bcd09d48e29aecce Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 23 Mar 2022 16:06:23 -0700 +Subject: minix: fix bug when opening a file with O_DIRECT + +From: Qinghua Jin + +[ Upstream commit 9ce3c0d26c42d279b6c378a03cd6a61d828f19ca ] + +Testcase: +1. create a minix file system and mount it +2. open a file on the file system with O_RDWR|O_CREAT|O_TRUNC|O_DIRECT +3. open fails with -EINVAL but leaves an empty file behind. All other + open() failures don't leave the failed open files behind. + +It is hard to check the direct_IO op before creating the inode. Just as +ext4 and btrfs do, this patch will resolve the issue by allowing to +create the file with O_DIRECT but returning error when writing the file. + +Link: https://lkml.kernel.org/r/20220107133626.413379-1-qhjin.dev@gmail.com +Signed-off-by: Qinghua Jin +Reported-by: Colin Ian King +Reviewed-by: Jan Kara +Acked-by: Christian Brauner +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + fs/minix/inode.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/fs/minix/inode.c b/fs/minix/inode.c +index 03fe8bac36cf..3ce91ad1ee1b 100644 +--- a/fs/minix/inode.c ++++ b/fs/minix/inode.c +@@ -450,7 +450,8 @@ static const struct address_space_operations minix_aops = { + .writepage = minix_writepage, + .write_begin = minix_write_begin, + .write_end = generic_write_end, +- .bmap = minix_bmap ++ .bmap = minix_bmap, ++ .direct_IO = noop_direct_IO + }; + + static const struct inode_operations minix_symlink_inode_operations = { +-- +2.35.1 + diff --git a/queue-4.19/mips-fix-fortify-panic-when-copying-asm-exception-ha.patch b/queue-4.19/mips-fix-fortify-panic-when-copying-asm-exception-ha.patch new file mode 100644 index 00000000000..d92fa76f501 --- /dev/null +++ b/queue-4.19/mips-fix-fortify-panic-when-copying-asm-exception-ha.patch @@ -0,0 +1,99 @@ +From 72157e6d50700bb4a11fb4053fe59a733bbd7298 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 23 Feb 2022 01:30:23 +0000 +Subject: MIPS: fix fortify panic when copying asm exception handlers + +From: Alexander Lobakin + +[ Upstream commit d17b66417308996e7e64b270a3c7f3c1fbd4cfc8 ] + +With KCFLAGS="-O3", I was able to trigger a fortify-source +memcpy() overflow panic on set_vi_srs_handler(). +Although O3 level is not supported in the mainline, under some +conditions that may've happened with any optimization settings, +it's just a matter of inlining luck. The panic itself is correct, +more precisely, 50/50 false-positive and not at the same time. +From the one side, no real overflow happens. Exception handler +defined in asm just gets copied to some reserved places in the +memory. +But the reason behind is that C code refers to that exception +handler declares it as `char`, i.e. something of 1 byte length. +It's obvious that the asm function itself is way more than 1 byte, +so fortify logics thought we are going to past the symbol declared. +The standard way to refer to asm symbols from C code which is not +supposed to be called from C is to declare them as +`extern const u8[]`. This is fully correct from any point of view, +as any code itself is just a bunch of bytes (including 0 as it is +for syms like _stext/_etext/etc.), and the exact size is not known +at the moment of compilation. +Adjust the type of the except_vec_vi_*() and related variables. +Make set_handler() take `const` as a second argument to avoid +cast-away warnings and give a little more room for optimization. + +Signed-off-by: Alexander Lobakin +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Sasha Levin +--- + arch/mips/include/asm/setup.h | 2 +- + arch/mips/kernel/traps.c | 22 +++++++++++----------- + 2 files changed, 12 insertions(+), 12 deletions(-) + +diff --git a/arch/mips/include/asm/setup.h b/arch/mips/include/asm/setup.h +index bb36a400203d..8c56b862fd9c 100644 +--- a/arch/mips/include/asm/setup.h ++++ b/arch/mips/include/asm/setup.h +@@ -16,7 +16,7 @@ static inline void setup_8250_early_printk_port(unsigned long base, + unsigned int reg_shift, unsigned int timeout) {} + #endif + +-extern void set_handler(unsigned long offset, void *addr, unsigned long len); ++void set_handler(unsigned long offset, const void *addr, unsigned long len); + extern void set_uncached_handler(unsigned long offset, void *addr, unsigned long len); + + typedef void (*vi_handler_t)(void); +diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c +index b9da2cefb564..0ca4185cc5e3 100644 +--- a/arch/mips/kernel/traps.c ++++ b/arch/mips/kernel/traps.c +@@ -1978,19 +1978,19 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs) + * If no shadow set is selected then use the default handler + * that does normal register saving and standard interrupt exit + */ +- extern char except_vec_vi, except_vec_vi_lui; +- extern char except_vec_vi_ori, except_vec_vi_end; +- extern char rollback_except_vec_vi; +- char *vec_start = using_rollback_handler() ? +- &rollback_except_vec_vi : &except_vec_vi; ++ extern const u8 except_vec_vi[], except_vec_vi_lui[]; ++ extern const u8 except_vec_vi_ori[], except_vec_vi_end[]; ++ extern const u8 rollback_except_vec_vi[]; ++ const u8 *vec_start = using_rollback_handler() ? ++ rollback_except_vec_vi : except_vec_vi; + #if defined(CONFIG_CPU_MICROMIPS) || defined(CONFIG_CPU_BIG_ENDIAN) +- const int lui_offset = &except_vec_vi_lui - vec_start + 2; +- const int ori_offset = &except_vec_vi_ori - vec_start + 2; ++ const int lui_offset = except_vec_vi_lui - vec_start + 2; ++ const int ori_offset = except_vec_vi_ori - vec_start + 2; + #else +- const int lui_offset = &except_vec_vi_lui - vec_start; +- const int ori_offset = &except_vec_vi_ori - vec_start; ++ const int lui_offset = except_vec_vi_lui - vec_start; ++ const int ori_offset = except_vec_vi_ori - vec_start; + #endif +- const int handler_len = &except_vec_vi_end - vec_start; ++ const int handler_len = except_vec_vi_end - vec_start; + + if (handler_len > VECTORSPACING) { + /* +@@ -2210,7 +2210,7 @@ void per_cpu_trap_init(bool is_boot_cpu) + } + + /* Install CPU exception handler */ +-void set_handler(unsigned long offset, void *addr, unsigned long size) ++void set_handler(unsigned long offset, const void *addr, unsigned long size) + { + #ifdef CONFIG_CPU_MICROMIPS + memcpy((void *)(ebase + offset), ((unsigned char *)addr - 1), size); +-- +2.35.1 + diff --git a/queue-4.19/mm-fix-race-between-madv_free-reclaim-and-blkdev-dir.patch b/queue-4.19/mm-fix-race-between-madv_free-reclaim-and-blkdev-dir.patch new file mode 100644 index 00000000000..44eea7a0386 --- /dev/null +++ b/queue-4.19/mm-fix-race-between-madv_free-reclaim-and-blkdev-dir.patch @@ -0,0 +1,463 @@ +From 3ef716860f87efb87df5e8c7cf390cfe1b004e90 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 7 Apr 2022 16:14:30 -0300 +Subject: mm: fix race between MADV_FREE reclaim and blkdev direct IO read + +From: Mauricio Faria de Oliveira + +commit 6c8e2a256915a223f6289f651d6b926cd7135c9e upstream. + +Problem: +======= + +Userspace might read the zero-page instead of actual data from a direct IO +read on a block device if the buffers have been called madvise(MADV_FREE) +on earlier (this is discussed below) due to a race between page reclaim on +MADV_FREE and blkdev direct IO read. + +- Race condition: + ============== + +During page reclaim, the MADV_FREE page check in try_to_unmap_one() checks +if the page is not dirty, then discards its rmap PTE(s) (vs. remap back +if the page is dirty). + +However, after try_to_unmap_one() returns to shrink_page_list(), it might +keep the page _anyway_ if page_ref_freeze() fails (it expects exactly +_one_ page reference, from the isolation for page reclaim). + +Well, blkdev_direct_IO() gets references for all pages, and on READ +operations it only sets them dirty _later_. + +So, if MADV_FREE'd pages (i.e., not dirty) are used as buffers for direct +IO read from block devices, and page reclaim happens during +__blkdev_direct_IO[_simple]() exactly AFTER bio_iov_iter_get_pages() +returns, but BEFORE the pages are set dirty, the situation happens. + +The direct IO read eventually completes. Now, when userspace reads the +buffers, the PTE is no longer there and the page fault handler +do_anonymous_page() services that with the zero-page, NOT the data! + +A synthetic reproducer is provided. + +- Page faults: + =========== + +If page reclaim happens BEFORE bio_iov_iter_get_pages() the issue doesn't +happen, because that faults-in all pages as writeable, so +do_anonymous_page() sets up a new page/rmap/PTE, and that is used by +direct IO. The userspace reads don't fault as the PTE is there (thus +zero-page is not used/setup). + +But if page reclaim happens AFTER it / BEFORE setting pages dirty, the PTE +is no longer there; the subsequent page faults can't help: + +The data-read from the block device probably won't generate faults due to +DMA (no MMU) but even in the case it wouldn't use DMA, that happens on +different virtual addresses (not user-mapped addresses) because `struct +bio_vec` stores `struct page` to figure addresses out (which are different +from user-mapped addresses) for the read. + +Thus userspace reads (to user-mapped addresses) still fault, then +do_anonymous_page() gets another `struct page` that would address/ map to +other memory than the `struct page` used by `struct bio_vec` for the read. +(The original `struct page` is not available, since it wasn't freed, as +page_ref_freeze() failed due to more page refs. And even if it were +available, its data cannot be trusted anymore.) + +Solution: +======== + +One solution is to check for the expected page reference count in +try_to_unmap_one(). + +There should be one reference from the isolation (that is also checked in +shrink_page_list() with page_ref_freeze()) plus one or more references +from page mapping(s) (put in discard: label). Further references mean +that rmap/PTE cannot be unmapped/nuked. + +(Note: there might be more than one reference from mapping due to +fork()/clone() without CLONE_VM, which use the same `struct page` for +references, until the copy-on-write page gets copied.) + +So, additional page references (e.g., from direct IO read) now prevent the +rmap/PTE from being unmapped/dropped; similarly to the page is not freed +per shrink_page_list()/page_ref_freeze()). + +- Races and Barriers: + ================== + +The new check in try_to_unmap_one() should be safe in races with +bio_iov_iter_get_pages() in get_user_pages() fast and slow paths, as it's +done under the PTE lock. + +The fast path doesn't take the lock, but it checks if the PTE has changed +and if so, it drops the reference and leaves the page for the slow path +(which does take that lock). + +The fast path requires synchronization w/ full memory barrier: it writes +the page reference count first then it reads the PTE later, while +try_to_unmap() writes PTE first then it reads page refcount. + +And a second barrier is needed, as the page dirty flag should not be read +before the page reference count (as in __remove_mapping()). (This can be +a load memory barrier only; no writes are involved.) + +Call stack/comments: + +- try_to_unmap_one() + - page_vma_mapped_walk() + - map_pte() # see pte_offset_map_lock(): + pte_offset_map() + spin_lock() + + - ptep_get_and_clear() # write PTE + - smp_mb() # (new barrier) GUP fast path + - page_ref_count() # (new check) read refcount + + - page_vma_mapped_walk_done() # see pte_unmap_unlock(): + pte_unmap() + spin_unlock() + +- bio_iov_iter_get_pages() + - __bio_iov_iter_get_pages() + - iov_iter_get_pages() + - get_user_pages_fast() + - internal_get_user_pages_fast() + + # fast path + - lockless_pages_from_mm() + - gup_{pgd,p4d,pud,pmd,pte}_range() + ptep = pte_offset_map() # not _lock() + pte = ptep_get_lockless(ptep) + + page = pte_page(pte) + try_grab_compound_head(page) # inc refcount + # (RMW/barrier + # on success) + + if (pte_val(pte) != pte_val(*ptep)) # read PTE + put_compound_head(page) # dec refcount + # go slow path + + # slow path + - __gup_longterm_unlocked() + - get_user_pages_unlocked() + - __get_user_pages_locked() + - __get_user_pages() + - follow_{page,p4d,pud,pmd}_mask() + - follow_page_pte() + ptep = pte_offset_map_lock() + pte = *ptep + page = vm_normal_page(pte) + try_grab_page(page) # inc refcount + pte_unmap_unlock() + +- Huge Pages: + ========== + +Regarding transparent hugepages, that logic shouldn't change, as MADV_FREE +(aka lazyfree) pages are PageAnon() && !PageSwapBacked() +(madvise_free_pte_range() -> mark_page_lazyfree() -> lru_lazyfree_fn()) +thus should reach shrink_page_list() -> split_huge_page_to_list() before +try_to_unmap[_one](), so it deals with normal pages only. + +(And in case unlikely/TTU_SPLIT_HUGE_PMD/split_huge_pmd_address() happens, +which should not or be rare, the page refcount should be greater than +mapcount: the head page is referenced by tail pages. That also prevents +checking the head `page` then incorrectly call page_remove_rmap(subpage) +for a tail page, that isn't even in the shrink_page_list()'s page_list (an +effect of split huge pmd/pmvw), as it might happen today in this unlikely +scenario.) + +MADV_FREE'd buffers: +=================== + +So, back to the "if MADV_FREE pages are used as buffers" note. The case +is arguable, and subject to multiple interpretations. + +The madvise(2) manual page on the MADV_FREE advice value says: + +1) 'After a successful MADV_FREE ... data will be lost when + the kernel frees the pages.' +2) 'the free operation will be canceled if the caller writes + into the page' / 'subsequent writes ... will succeed and + then [the] kernel cannot free those dirtied pages' +3) 'If there is no subsequent write, the kernel can free the + pages at any time.' + +Thoughts, questions, considerations... respectively: + +1) Since the kernel didn't actually free the page (page_ref_freeze() + failed), should the data not have been lost? (on userspace read.) +2) Should writes performed by the direct IO read be able to cancel + the free operation? + - Should the direct IO read be considered as 'the caller' too, + as it's been requested by 'the caller'? + - Should the bio technique to dirty pages on return to userspace + (bio_check_pages_dirty() is called/used by __blkdev_direct_IO()) + be considered in another/special way here? +3) Should an upcoming write from a previously requested direct IO + read be considered as a subsequent write, so the kernel should + not free the pages? (as it's known at the time of page reclaim.) + +And lastly: + +Technically, the last point would seem a reasonable consideration and +balance, as the madvise(2) manual page apparently (and fairly) seem to +assume that 'writes' are memory access from the userspace process (not +explicitly considering writes from the kernel or its corner cases; again, +fairly).. plus the kernel fix implementation for the corner case of the +largely 'non-atomic write' encompassed by a direct IO read operation, is +relatively simple; and it helps. + +Reproducer: +========== + +@ test.c (simplified, but works) + + #define _GNU_SOURCE + #include + #include + #include + #include + + int main() { + int fd, i; + char *buf; + + fd = open(DEV, O_RDONLY | O_DIRECT); + + buf = mmap(NULL, BUF_SIZE, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + + for (i = 0; i < BUF_SIZE; i += PAGE_SIZE) + buf[i] = 1; // init to non-zero + + madvise(buf, BUF_SIZE, MADV_FREE); + + read(fd, buf, BUF_SIZE); + + for (i = 0; i < BUF_SIZE; i += PAGE_SIZE) + printf("%p: 0x%x\n", &buf[i], buf[i]); + + return 0; + } + +@ block/fops.c (formerly fs/block_dev.c) + + +#include + ... + ... __blkdev_direct_IO[_simple](...) + { + ... + + if (!strcmp(current->comm, "good")) + + shrink_all_memory(ULONG_MAX); + + + ret = bio_iov_iter_get_pages(...); + + + + if (!strcmp(current->comm, "bad")) + + shrink_all_memory(ULONG_MAX); + ... + } + +@ shell + + # NUM_PAGES=4 + # PAGE_SIZE=$(getconf PAGE_SIZE) + + # yes | dd of=test.img bs=${PAGE_SIZE} count=${NUM_PAGES} + # DEV=$(losetup -f --show test.img) + + # gcc -DDEV=\"$DEV\" \ + -DBUF_SIZE=$((PAGE_SIZE * NUM_PAGES)) \ + -DPAGE_SIZE=${PAGE_SIZE} \ + test.c -o test + + # od -tx1 $DEV + 0000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a + * + 0040000 + + # mv test good + # ./good + 0x7f7c10418000: 0x79 + 0x7f7c10419000: 0x79 + 0x7f7c1041a000: 0x79 + 0x7f7c1041b000: 0x79 + + # mv good bad + # ./bad + 0x7fa1b8050000: 0x0 + 0x7fa1b8051000: 0x0 + 0x7fa1b8052000: 0x0 + 0x7fa1b8053000: 0x0 + +Note: the issue is consistent on v5.17-rc3, but it's intermittent with the +support of MADV_FREE on v4.5 (60%-70% error; needs swap). [wrap +do_direct_IO() in do_blockdev_direct_IO() @ fs/direct-io.c]. + +- v5.17-rc3: + + # for i in {1..1000}; do ./good; done \ + | cut -d: -f2 | sort | uniq -c + 4000 0x79 + + # mv good bad + # for i in {1..1000}; do ./bad; done \ + | cut -d: -f2 | sort | uniq -c + 4000 0x0 + + # free | grep Swap + Swap: 0 0 0 + +- v4.5: + + # for i in {1..1000}; do ./good; done \ + | cut -d: -f2 | sort | uniq -c + 4000 0x79 + + # mv good bad + # for i in {1..1000}; do ./bad; done \ + | cut -d: -f2 | sort | uniq -c + 2702 0x0 + 1298 0x79 + + # swapoff -av + swapoff /swap + + # for i in {1..1000}; do ./bad; done \ + | cut -d: -f2 | sort | uniq -c + 4000 0x79 + +Ceph/TCMalloc: +============= + +For documentation purposes, the use case driving the analysis/fix is Ceph +on Ubuntu 18.04, as the TCMalloc library there still uses MADV_FREE to +release unused memory to the system from the mmap'ed page heap (might be +committed back/used again; it's not munmap'ed.) - PageHeap::DecommitSpan() +-> TCMalloc_SystemRelease() -> madvise() - PageHeap::CommitSpan() -> +TCMalloc_SystemCommit() -> do nothing. + +Note: TCMalloc switched back to MADV_DONTNEED a few commits after the +release in Ubuntu 18.04 (google-perftools/gperftools 2.5), so the issue +just 'disappeared' on Ceph on later Ubuntu releases but is still present +in the kernel, and can be hit by other use cases. + +The observed issue seems to be the old Ceph bug #22464 [1], where checksum +mismatches are observed (and instrumentation with buffer dumps shows +zero-pages read from mmap'ed/MADV_FREE'd page ranges). + +The issue in Ceph was reasonably deemed a kernel bug (comment #50) and +mostly worked around with a retry mechanism, but other parts of Ceph could +still hit that (rocksdb). Anyway, it's less likely to be hit again as +TCMalloc switched out of MADV_FREE by default. + +(Some kernel versions/reports from the Ceph bug, and relation with +the MADV_FREE introduction/changes; TCMalloc versions not checked.) +- 4.4 good +- 4.5 (madv_free: introduction) +- 4.9 bad +- 4.10 good? maybe a swapless system +- 4.12 (madv_free: no longer free instantly on swapless systems) +- 4.13 bad + +[1] https://tracker.ceph.com/issues/22464 + +Thanks: +====== + +Several people contributed to analysis/discussions/tests/reproducers in +the first stages when drilling down on ceph/tcmalloc/linux kernel: + +- Dan Hill +- Dan Streetman +- Dongdong Tao +- Gavin Guo +- Gerald Yang +- Heitor Alves de Siqueira +- Ioanna Alifieraki +- Jay Vosburgh +- Matthew Ruffell +- Ponnuvel Palaniyappan + +Reviews, suggestions, corrections, comments: + +- Minchan Kim +- Yu Zhao +- Huang, Ying +- John Hubbard +- Christoph Hellwig + +[mfo@canonical.com: v4] + Link: https://lkml.kernel.org/r/20220209202659.183418-1-mfo@canonical.comLink: https://lkml.kernel.org/r/20220131230255.789059-1-mfo@canonical.com + +Fixes: 802a3a92ad7a ("mm: reclaim MADV_FREE pages") +Signed-off-by: Mauricio Faria de Oliveira +Reviewed-by: "Huang, Ying" +Cc: Minchan Kim +Cc: Yu Zhao +Cc: Yang Shi +Cc: Miaohe Lin +Cc: Dan Hill +Cc: Dan Streetman +Cc: Dongdong Tao +Cc: Gavin Guo +Cc: Gerald Yang +Cc: Heitor Alves de Siqueira +Cc: Ioanna Alifieraki +Cc: Jay Vosburgh +Cc: Matthew Ruffell +Cc: Ponnuvel Palaniyappan +Cc: +Cc: Christoph Hellwig +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +[mfo: backport: replace folio/test_flag with page/flag equivalents; + real Fixes: 854e9ed09ded ("mm: support madvise(MADV_FREE)") in v4.] +Signed-off-by: Mauricio Faria de Oliveira +Signed-off-by: Sasha Levin +--- + mm/rmap.c | 25 ++++++++++++++++++++++++- + 1 file changed, 24 insertions(+), 1 deletion(-) + +diff --git a/mm/rmap.c b/mm/rmap.c +index 699f445e3e78..e578eb942317 100644 +--- a/mm/rmap.c ++++ b/mm/rmap.c +@@ -1594,7 +1594,30 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma, + + /* MADV_FREE page check */ + if (!PageSwapBacked(page)) { +- if (!PageDirty(page)) { ++ int ref_count, map_count; ++ ++ /* ++ * Synchronize with gup_pte_range(): ++ * - clear PTE; barrier; read refcount ++ * - inc refcount; barrier; read PTE ++ */ ++ smp_mb(); ++ ++ ref_count = page_ref_count(page); ++ map_count = page_mapcount(page); ++ ++ /* ++ * Order reads for page refcount and dirty flag ++ * (see comments in __remove_mapping()). ++ */ ++ smp_rmb(); ++ ++ /* ++ * The only page refs must be one from isolation ++ * plus the rmap(s) (dropped by discard:). ++ */ ++ if (ref_count == 1 + map_count && ++ !PageDirty(page)) { + /* Invalidate as we cleared the pte */ + mmu_notifier_invalidate_range(mm, + address, address + PAGE_SIZE); +-- +2.35.1 + diff --git a/queue-4.19/net-add-missing-sof_timestamping_opt_id-support.patch b/queue-4.19/net-add-missing-sof_timestamping_opt_id-support.patch new file mode 100644 index 00000000000..8b8961b261f --- /dev/null +++ b/queue-4.19/net-add-missing-sof_timestamping_opt_id-support.patch @@ -0,0 +1,150 @@ +From e1f8b467b2757c4dd6a3ddb2452aadd36714338e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 6 Apr 2022 22:29:56 +0300 +Subject: net: add missing SOF_TIMESTAMPING_OPT_ID support + +From: Willem de Bruijn + +[ Upstream commit 8f932f762e7928d250e21006b00ff9b7718b0a64 ] + +SOF_TIMESTAMPING_OPT_ID is supported on TCP, UDP and RAW sockets. +But it was missing on RAW with IPPROTO_IP, PF_PACKET and CAN. + +Add skb_setup_tx_timestamp that configures both tx_flags and tskey +for these paths that do not need corking or use bytestream keys. + +Fixes: 09c2d251b707 ("net-timestamp: add key to disambiguate concurrent datagrams") +Signed-off-by: Willem de Bruijn +Acked-by: Soheil Hassas Yeganeh +Signed-off-by: David S. Miller +Signed-off-by: Vladimir Oltean +Signed-off-by: Sasha Levin +--- + include/net/sock.h | 25 +++++++++++++++++++++---- + net/can/raw.c | 2 +- + net/ipv4/raw.c | 2 +- + net/ipv6/raw.c | 2 +- + net/packet/af_packet.c | 6 +++--- + 5 files changed, 27 insertions(+), 10 deletions(-) + +diff --git a/include/net/sock.h b/include/net/sock.h +index 2bf8dcf863f2..7d3a4c2eea95 100644 +--- a/include/net/sock.h ++++ b/include/net/sock.h +@@ -2400,22 +2400,39 @@ static inline void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk, + void __sock_tx_timestamp(__u16 tsflags, __u8 *tx_flags); + + /** +- * sock_tx_timestamp - checks whether the outgoing packet is to be time stamped ++ * _sock_tx_timestamp - checks whether the outgoing packet is to be time stamped + * @sk: socket sending this packet + * @tsflags: timestamping flags to use + * @tx_flags: completed with instructions for time stamping ++ * @tskey: filled in with next sk_tskey (not for TCP, which uses seqno) + * + * Note: callers should take care of initial ``*tx_flags`` value (usually 0) + */ +-static inline void sock_tx_timestamp(const struct sock *sk, __u16 tsflags, +- __u8 *tx_flags) ++static inline void _sock_tx_timestamp(struct sock *sk, __u16 tsflags, ++ __u8 *tx_flags, __u32 *tskey) + { +- if (unlikely(tsflags)) ++ if (unlikely(tsflags)) { + __sock_tx_timestamp(tsflags, tx_flags); ++ if (tsflags & SOF_TIMESTAMPING_OPT_ID && tskey && ++ tsflags & SOF_TIMESTAMPING_TX_RECORD_MASK) ++ *tskey = sk->sk_tskey++; ++ } + if (unlikely(sock_flag(sk, SOCK_WIFI_STATUS))) + *tx_flags |= SKBTX_WIFI_STATUS; + } + ++static inline void sock_tx_timestamp(struct sock *sk, __u16 tsflags, ++ __u8 *tx_flags) ++{ ++ _sock_tx_timestamp(sk, tsflags, tx_flags, NULL); ++} ++ ++static inline void skb_setup_tx_timestamp(struct sk_buff *skb, __u16 tsflags) ++{ ++ _sock_tx_timestamp(skb->sk, tsflags, &skb_shinfo(skb)->tx_flags, ++ &skb_shinfo(skb)->tskey); ++} ++ + /** + * sk_eat_skb - Release a skb if it is no longer needed + * @sk: socket to eat this skb from +diff --git a/net/can/raw.c b/net/can/raw.c +index d0fb5a57c66d..2a6db8752b61 100644 +--- a/net/can/raw.c ++++ b/net/can/raw.c +@@ -814,7 +814,7 @@ static int raw_sendmsg(struct socket *sock, struct msghdr *msg, size_t size) + if (err < 0) + goto free_skb; + +- sock_tx_timestamp(sk, sk->sk_tsflags, &skb_shinfo(skb)->tx_flags); ++ skb_setup_tx_timestamp(skb, sk->sk_tsflags); + + skb->dev = dev; + skb->sk = sk; +diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c +index 8cae691c3c9f..654f586fc0d7 100644 +--- a/net/ipv4/raw.c ++++ b/net/ipv4/raw.c +@@ -391,7 +391,7 @@ static int raw_send_hdrinc(struct sock *sk, struct flowi4 *fl4, + + skb->ip_summed = CHECKSUM_NONE; + +- sock_tx_timestamp(sk, sockc->tsflags, &skb_shinfo(skb)->tx_flags); ++ skb_setup_tx_timestamp(skb, sockc->tsflags); + + if (flags & MSG_CONFIRM) + skb_set_dst_pending_confirm(skb, 1); +diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c +index 98c8f98a7660..ad7bd40b6d53 100644 +--- a/net/ipv6/raw.c ++++ b/net/ipv6/raw.c +@@ -660,7 +660,7 @@ static int rawv6_send_hdrinc(struct sock *sk, struct msghdr *msg, int length, + + skb->ip_summed = CHECKSUM_NONE; + +- sock_tx_timestamp(sk, sockc->tsflags, &skb_shinfo(skb)->tx_flags); ++ skb_setup_tx_timestamp(skb, sockc->tsflags); + + if (flags & MSG_CONFIRM) + skb_set_dst_pending_confirm(skb, 1); +diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c +index d65051959f85..b951f411dded 100644 +--- a/net/packet/af_packet.c ++++ b/net/packet/af_packet.c +@@ -1978,7 +1978,7 @@ static int packet_sendmsg_spkt(struct socket *sock, struct msghdr *msg, + skb->mark = sk->sk_mark; + skb->tstamp = sockc.transmit_time; + +- sock_tx_timestamp(sk, sockc.tsflags, &skb_shinfo(skb)->tx_flags); ++ skb_setup_tx_timestamp(skb, sockc.tsflags); + + if (unlikely(extra_len == 4)) + skb->no_fcs = 1; +@@ -2501,7 +2501,7 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb, + skb->priority = po->sk.sk_priority; + skb->mark = po->sk.sk_mark; + skb->tstamp = sockc->transmit_time; +- sock_tx_timestamp(&po->sk, sockc->tsflags, &skb_shinfo(skb)->tx_flags); ++ skb_setup_tx_timestamp(skb, sockc->tsflags); + skb_zcopy_set_nouarg(skb, ph.raw); + + skb_reserve(skb, hlen); +@@ -2965,7 +2965,7 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len) + goto out_free; + } + +- sock_tx_timestamp(sk, sockc.tsflags, &skb_shinfo(skb)->tx_flags); ++ skb_setup_tx_timestamp(skb, sockc.tsflags); + + if (!vnet_hdr.gso_type && (len > dev->mtu + reserve + extra_len) && + !packet_extra_vlan_len_allowed(dev, skb)) { +-- +2.35.1 + diff --git a/queue-4.19/net-smc-correct-settings-of-rmb-window-update-limit.patch b/queue-4.19/net-smc-correct-settings-of-rmb-window-update-limit.patch new file mode 100644 index 00000000000..028405956fd --- /dev/null +++ b/queue-4.19/net-smc-correct-settings-of-rmb-window-update-limit.patch @@ -0,0 +1,52 @@ +From 140aae27f7beb803f9ec620f63c5631591723a8f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Mar 2022 17:44:00 +0800 +Subject: net/smc: correct settings of RMB window update limit + +From: Dust Li + +[ Upstream commit 6bf536eb5c8ca011d1ff57b5c5f7c57ceac06a37 ] + +rmbe_update_limit is used to limit announcing receive +window updating too frequently. RFC7609 request a minimal +increase in the window size of 10% of the receive buffer +space. But current implementation used: + + min_t(int, rmbe_size / 10, SOCK_MIN_SNDBUF / 2) + +and SOCK_MIN_SNDBUF / 2 == 2304 Bytes, which is almost +always less then 10% of the receive buffer space. + +This causes the receiver always sending CDC message to +update its consumer cursor when it consumes more then 2K +of data. And as a result, we may encounter something like +"TCP silly window syndrome" when sending 2.5~8K message. + +This patch fixes this using max(rmbe_size / 10, SOCK_MIN_SNDBUF / 2). + +With this patch and SMC autocorking enabled, qperf 2K/4K/8K +tcp_bw test shows 45%/75%/40% increase in throughput respectively. + +Signed-off-by: Dust Li +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/smc/smc_core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c +index 6add3094ea9e..4d421407d6fc 100644 +--- a/net/smc/smc_core.c ++++ b/net/smc/smc_core.c +@@ -709,7 +709,7 @@ static struct smc_buf_desc *smc_buf_get_slot(int compressed_bufsize, + */ + static inline int smc_rmb_wnd_update_limit(int rmbe_size) + { +- return min_t(int, rmbe_size / 10, SOCK_MIN_SNDBUF / 2); ++ return max_t(int, rmbe_size / 10, SOCK_MIN_SNDBUF / 2); + } + + static struct smc_buf_desc *smcr_new_buf_create(struct smc_link_group *lgr, +-- +2.35.1 + diff --git a/queue-4.19/nfs-swap-io-handling-is-slightly-different-for-o_dir.patch b/queue-4.19/nfs-swap-io-handling-is-slightly-different-for-o_dir.patch new file mode 100644 index 00000000000..cf35047545d --- /dev/null +++ b/queue-4.19/nfs-swap-io-handling-is-slightly-different-for-o_dir.patch @@ -0,0 +1,183 @@ +From 16f76482b17993c401c2b2dd59760c2b8a9b2036 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 7 Mar 2022 10:41:44 +1100 +Subject: NFS: swap IO handling is slightly different for O_DIRECT IO + +From: NeilBrown + +[ Upstream commit 64158668ac8b31626a8ce48db4cad08496eb8340 ] + +1/ Taking the i_rwsem for swap IO triggers lockdep warnings regarding + possible deadlocks with "fs_reclaim". These deadlocks could, I believe, + eventuate if a buffered read on the swapfile was attempted. + + We don't need coherence with the page cache for a swap file, and + buffered writes are forbidden anyway. There is no other need for + i_rwsem during direct IO. So never take it for swap_rw() + +2/ generic_write_checks() explicitly forbids writes to swap, and + performs checks that are not needed for swap. So bypass it + for swap_rw(). + +Signed-off-by: NeilBrown +Signed-off-by: Trond Myklebust +Signed-off-by: Sasha Levin +--- + fs/nfs/direct.c | 42 ++++++++++++++++++++++++++++-------------- + fs/nfs/file.c | 4 ++-- + include/linux/nfs_fs.h | 8 ++++---- + 3 files changed, 34 insertions(+), 20 deletions(-) + +diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c +index e5da9d7fb69e..41ff316cd6ad 100644 +--- a/fs/nfs/direct.c ++++ b/fs/nfs/direct.c +@@ -288,8 +288,8 @@ ssize_t nfs_direct_IO(struct kiocb *iocb, struct iov_iter *iter) + VM_BUG_ON(iov_iter_count(iter) != PAGE_SIZE); + + if (iov_iter_rw(iter) == READ) +- return nfs_file_direct_read(iocb, iter); +- return nfs_file_direct_write(iocb, iter); ++ return nfs_file_direct_read(iocb, iter, true); ++ return nfs_file_direct_write(iocb, iter, true); + } + + static void nfs_direct_release_pages(struct page **pages, unsigned int npages) +@@ -553,6 +553,7 @@ static ssize_t nfs_direct_read_schedule_iovec(struct nfs_direct_req *dreq, + * nfs_file_direct_read - file direct read operation for NFS files + * @iocb: target I/O control block + * @iter: vector of user buffers into which to read data ++ * @swap: flag indicating this is swap IO, not O_DIRECT IO + * + * We use this function for direct reads instead of calling + * generic_file_aio_read() in order to avoid gfar's check to see if +@@ -568,7 +569,8 @@ static ssize_t nfs_direct_read_schedule_iovec(struct nfs_direct_req *dreq, + * client must read the updated atime from the server back into its + * cache. + */ +-ssize_t nfs_file_direct_read(struct kiocb *iocb, struct iov_iter *iter) ++ssize_t nfs_file_direct_read(struct kiocb *iocb, struct iov_iter *iter, ++ bool swap) + { + struct file *file = iocb->ki_filp; + struct address_space *mapping = file->f_mapping; +@@ -610,12 +612,14 @@ ssize_t nfs_file_direct_read(struct kiocb *iocb, struct iov_iter *iter) + if (iter_is_iovec(iter)) + dreq->flags = NFS_ODIRECT_SHOULD_DIRTY; + +- nfs_start_io_direct(inode); ++ if (!swap) ++ nfs_start_io_direct(inode); + + NFS_I(inode)->read_io += count; + requested = nfs_direct_read_schedule_iovec(dreq, iter, iocb->ki_pos); + +- nfs_end_io_direct(inode); ++ if (!swap) ++ nfs_end_io_direct(inode); + + if (requested > 0) { + result = nfs_direct_wait(dreq); +@@ -971,6 +975,7 @@ static ssize_t nfs_direct_write_schedule_iovec(struct nfs_direct_req *dreq, + * nfs_file_direct_write - file direct write operation for NFS files + * @iocb: target I/O control block + * @iter: vector of user buffers from which to write data ++ * @swap: flag indicating this is swap IO, not O_DIRECT IO + * + * We use this function for direct writes instead of calling + * generic_file_aio_write() in order to avoid taking the inode +@@ -987,7 +992,8 @@ static ssize_t nfs_direct_write_schedule_iovec(struct nfs_direct_req *dreq, + * Note that O_APPEND is not supported for NFS direct writes, as there + * is no atomic O_APPEND write facility in the NFS protocol. + */ +-ssize_t nfs_file_direct_write(struct kiocb *iocb, struct iov_iter *iter) ++ssize_t nfs_file_direct_write(struct kiocb *iocb, struct iov_iter *iter, ++ bool swap) + { + ssize_t result = -EINVAL, requested; + size_t count; +@@ -1001,7 +1007,11 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct iov_iter *iter) + dfprintk(FILE, "NFS: direct write(%pD2, %zd@%Ld)\n", + file, iov_iter_count(iter), (long long) iocb->ki_pos); + +- result = generic_write_checks(iocb, iter); ++ if (swap) ++ /* bypass generic checks */ ++ result = iov_iter_count(iter); ++ else ++ result = generic_write_checks(iocb, iter); + if (result <= 0) + return result; + count = result; +@@ -1031,16 +1041,20 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct iov_iter *iter) + if (!is_sync_kiocb(iocb)) + dreq->iocb = iocb; + +- nfs_start_io_direct(inode); ++ if (swap) { ++ requested = nfs_direct_write_schedule_iovec(dreq, iter, pos); ++ } else { ++ nfs_start_io_direct(inode); + +- requested = nfs_direct_write_schedule_iovec(dreq, iter, pos); ++ requested = nfs_direct_write_schedule_iovec(dreq, iter, pos); + +- if (mapping->nrpages) { +- invalidate_inode_pages2_range(mapping, +- pos >> PAGE_SHIFT, end); +- } ++ if (mapping->nrpages) { ++ invalidate_inode_pages2_range(mapping, ++ pos >> PAGE_SHIFT, end); ++ } + +- nfs_end_io_direct(inode); ++ nfs_end_io_direct(inode); ++ } + + if (requested > 0) { + result = nfs_direct_wait(dreq); +diff --git a/fs/nfs/file.c b/fs/nfs/file.c +index 29553fdba8af..62a86c414391 100644 +--- a/fs/nfs/file.c ++++ b/fs/nfs/file.c +@@ -157,7 +157,7 @@ nfs_file_read(struct kiocb *iocb, struct iov_iter *to) + ssize_t result; + + if (iocb->ki_flags & IOCB_DIRECT) +- return nfs_file_direct_read(iocb, to); ++ return nfs_file_direct_read(iocb, to, false); + + dprintk("NFS: read(%pD2, %zu@%lu)\n", + iocb->ki_filp, +@@ -606,7 +606,7 @@ ssize_t nfs_file_write(struct kiocb *iocb, struct iov_iter *from) + return result; + + if (iocb->ki_flags & IOCB_DIRECT) +- return nfs_file_direct_write(iocb, from); ++ return nfs_file_direct_write(iocb, from, false); + + dprintk("NFS: write(%pD2, %zu@%Ld)\n", + file, iov_iter_count(from), (long long) iocb->ki_pos); +diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h +index 0ff7dd2bf8a4..8ea7ceed8285 100644 +--- a/include/linux/nfs_fs.h ++++ b/include/linux/nfs_fs.h +@@ -475,10 +475,10 @@ static inline struct rpc_cred *nfs_file_cred(struct file *file) + * linux/fs/nfs/direct.c + */ + extern ssize_t nfs_direct_IO(struct kiocb *, struct iov_iter *); +-extern ssize_t nfs_file_direct_read(struct kiocb *iocb, +- struct iov_iter *iter); +-extern ssize_t nfs_file_direct_write(struct kiocb *iocb, +- struct iov_iter *iter); ++ssize_t nfs_file_direct_read(struct kiocb *iocb, ++ struct iov_iter *iter, bool swap); ++ssize_t nfs_file_direct_write(struct kiocb *iocb, ++ struct iov_iter *iter, bool swap); + + /* + * linux/fs/nfs/dir.c +-- +2.35.1 + diff --git a/queue-4.19/nfs-swap-out-must-always-use-stable-writes.patch b/queue-4.19/nfs-swap-out-must-always-use-stable-writes.patch new file mode 100644 index 00000000000..371c0073e86 --- /dev/null +++ b/queue-4.19/nfs-swap-out-must-always-use-stable-writes.patch @@ -0,0 +1,71 @@ +From 70c70392601a7c3ba6b89ec719f90ea931812f41 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 7 Mar 2022 10:41:44 +1100 +Subject: NFS: swap-out must always use STABLE writes. + +From: NeilBrown + +[ Upstream commit c265de257f558a05c1859ee9e3fed04883b9ec0e ] + +The commit handling code is not safe against memory-pressure deadlocks +when writing to swap. In particular, nfs_commitdata_alloc() blocks +indefinitely waiting for memory, and this can consume all available +workqueue threads. + +swap-out most likely uses STABLE writes anyway as COND_STABLE indicates +that a stable write should be used if the write fits in a single +request, and it normally does. However if we ever swap with a small +wsize, or gather unusually large numbers of pages for a single write, +this might change. + +For safety, make it explicit in the code that direct writes used for swap +must always use FLUSH_STABLE. + +Signed-off-by: NeilBrown +Signed-off-by: Trond Myklebust +Signed-off-by: Sasha Levin +--- + fs/nfs/direct.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c +index 41ff316cd6ad..6a4083d550c6 100644 +--- a/fs/nfs/direct.c ++++ b/fs/nfs/direct.c +@@ -888,7 +888,7 @@ static const struct nfs_pgio_completion_ops nfs_direct_write_completion_ops = { + */ + static ssize_t nfs_direct_write_schedule_iovec(struct nfs_direct_req *dreq, + struct iov_iter *iter, +- loff_t pos) ++ loff_t pos, int ioflags) + { + struct nfs_pageio_descriptor desc; + struct inode *inode = dreq->inode; +@@ -896,7 +896,7 @@ static ssize_t nfs_direct_write_schedule_iovec(struct nfs_direct_req *dreq, + size_t requested_bytes = 0; + size_t wsize = max_t(size_t, NFS_SERVER(inode)->wsize, PAGE_SIZE); + +- nfs_pageio_init_write(&desc, inode, FLUSH_COND_STABLE, false, ++ nfs_pageio_init_write(&desc, inode, ioflags, false, + &nfs_direct_write_completion_ops); + desc.pg_dreq = dreq; + get_dreq(dreq); +@@ -1042,11 +1042,13 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct iov_iter *iter, + dreq->iocb = iocb; + + if (swap) { +- requested = nfs_direct_write_schedule_iovec(dreq, iter, pos); ++ requested = nfs_direct_write_schedule_iovec(dreq, iter, pos, ++ FLUSH_STABLE); + } else { + nfs_start_io_direct(inode); + +- requested = nfs_direct_write_schedule_iovec(dreq, iter, pos); ++ requested = nfs_direct_write_schedule_iovec(dreq, iter, pos, ++ FLUSH_COND_STABLE); + + if (mapping->nrpages) { + invalidate_inode_pages2_range(mapping, +-- +2.35.1 + diff --git a/queue-4.19/nfsv4-protect-the-state-recovery-thread-against-dire.patch b/queue-4.19/nfsv4-protect-the-state-recovery-thread-against-dire.patch new file mode 100644 index 00000000000..daa9eca42fa --- /dev/null +++ b/queue-4.19/nfsv4-protect-the-state-recovery-thread-against-dire.patch @@ -0,0 +1,76 @@ +From a5aab25d3cdb64e815ba59c46428222a6f106ce1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 29 Jan 2022 13:32:45 -0500 +Subject: NFSv4: Protect the state recovery thread against direct reclaim + +From: Trond Myklebust + +[ Upstream commit 3e17898aca293a24dae757a440a50aa63ca29671 ] + +If memory allocation triggers a direct reclaim from the state recovery +thread, then we can deadlock. Use memalloc_nofs_save/restore to ensure +that doesn't happen. + +Signed-off-by: Trond Myklebust +Signed-off-by: Sasha Levin +--- + fs/nfs/nfs4state.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c +index 9c98547fcefc..30576a10a1f4 100644 +--- a/fs/nfs/nfs4state.c ++++ b/fs/nfs/nfs4state.c +@@ -49,6 +49,7 @@ + #include + #include + #include ++#include + + #include + +@@ -2505,9 +2506,17 @@ static int nfs4_bind_conn_to_session(struct nfs_client *clp) + + static void nfs4_state_manager(struct nfs_client *clp) + { ++ unsigned int memflags; + int status = 0; + const char *section = "", *section_sep = ""; + ++ /* ++ * State recovery can deadlock if the direct reclaim code tries ++ * start NFS writeback. So ensure memory allocations are all ++ * GFP_NOFS. ++ */ ++ memflags = memalloc_nofs_save(); ++ + /* Ensure exclusive access to NFSv4 state */ + do { + clear_bit(NFS4CLNT_RUN_MANAGER, &clp->cl_state); +@@ -2600,6 +2609,7 @@ static void nfs4_state_manager(struct nfs_client *clp) + goto out_error; + } + ++ memalloc_nofs_restore(memflags); + nfs4_end_drain_session(clp); + nfs4_clear_state_manager_bit(clp); + +@@ -2616,6 +2626,7 @@ static void nfs4_state_manager(struct nfs_client *clp) + return; + if (test_and_set_bit(NFS4CLNT_MANAGER_RUNNING, &clp->cl_state) != 0) + return; ++ memflags = memalloc_nofs_save(); + } while (refcount_read(&clp->cl_count) > 1 && !signalled()); + goto out_drain; + +@@ -2627,6 +2638,7 @@ static void nfs4_state_manager(struct nfs_client *clp) + clp->cl_hostname, -status); + ssleep(1); + out_drain: ++ memalloc_nofs_restore(memflags); + nfs4_end_drain_session(clp); + nfs4_clear_state_manager_bit(clp); + } +-- +2.35.1 + diff --git a/queue-4.19/parisc-fix-cpu-affinity-for-lasi-wax-and-dino-chips.patch b/queue-4.19/parisc-fix-cpu-affinity-for-lasi-wax-and-dino-chips.patch new file mode 100644 index 00000000000..f78024e3b89 --- /dev/null +++ b/queue-4.19/parisc-fix-cpu-affinity-for-lasi-wax-and-dino-chips.patch @@ -0,0 +1,232 @@ +From c0326b467a113d9dd448653a4548c7c6bfbceb82 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 27 Mar 2022 15:46:26 +0200 +Subject: parisc: Fix CPU affinity for Lasi, WAX and Dino chips + +From: Helge Deller + +[ Upstream commit 939fc856676c266c3bc347c1c1661872a3725c0f ] + +Add the missing logic to allow Lasi, WAX and Dino to set the +CPU affinity. This fixes IRQ migration to other CPUs when a +CPU is shutdown which currently holds the IRQs for one of those +chips. + +Signed-off-by: Helge Deller +Signed-off-by: Sasha Levin +--- + drivers/parisc/dino.c | 41 +++++++++++++++++++++++++++++++++-------- + drivers/parisc/gsc.c | 31 +++++++++++++++++++++++++++++++ + drivers/parisc/gsc.h | 1 + + drivers/parisc/lasi.c | 7 +++---- + drivers/parisc/wax.c | 7 +++---- + 5 files changed, 71 insertions(+), 16 deletions(-) + +diff --git a/drivers/parisc/dino.c b/drivers/parisc/dino.c +index 2b60535a9c7b..25f36e5197d4 100644 +--- a/drivers/parisc/dino.c ++++ b/drivers/parisc/dino.c +@@ -144,9 +144,8 @@ struct dino_device + { + struct pci_hba_data hba; /* 'C' inheritance - must be first */ + spinlock_t dinosaur_pen; +- unsigned long txn_addr; /* EIR addr to generate interrupt */ +- u32 txn_data; /* EIR data assign to each dino */ + u32 imr; /* IRQ's which are enabled */ ++ struct gsc_irq gsc_irq; + int global_irq[DINO_LOCAL_IRQS]; /* map IMR bit to global irq */ + #ifdef DINO_DEBUG + unsigned int dino_irr0; /* save most recent IRQ line stat */ +@@ -343,14 +342,43 @@ static void dino_unmask_irq(struct irq_data *d) + if (tmp & DINO_MASK_IRQ(local_irq)) { + DBG(KERN_WARNING "%s(): IRQ asserted! (ILR 0x%x)\n", + __func__, tmp); +- gsc_writel(dino_dev->txn_data, dino_dev->txn_addr); ++ gsc_writel(dino_dev->gsc_irq.txn_data, dino_dev->gsc_irq.txn_addr); + } + } + ++#ifdef CONFIG_SMP ++static int dino_set_affinity_irq(struct irq_data *d, const struct cpumask *dest, ++ bool force) ++{ ++ struct dino_device *dino_dev = irq_data_get_irq_chip_data(d); ++ struct cpumask tmask; ++ int cpu_irq; ++ u32 eim; ++ ++ if (!cpumask_and(&tmask, dest, cpu_online_mask)) ++ return -EINVAL; ++ ++ cpu_irq = cpu_check_affinity(d, &tmask); ++ if (cpu_irq < 0) ++ return cpu_irq; ++ ++ dino_dev->gsc_irq.txn_addr = txn_affinity_addr(d->irq, cpu_irq); ++ eim = ((u32) dino_dev->gsc_irq.txn_addr) | dino_dev->gsc_irq.txn_data; ++ __raw_writel(eim, dino_dev->hba.base_addr+DINO_IAR0); ++ ++ irq_data_update_effective_affinity(d, &tmask); ++ ++ return IRQ_SET_MASK_OK; ++} ++#endif ++ + static struct irq_chip dino_interrupt_type = { + .name = "GSC-PCI", + .irq_unmask = dino_unmask_irq, + .irq_mask = dino_mask_irq, ++#ifdef CONFIG_SMP ++ .irq_set_affinity = dino_set_affinity_irq, ++#endif + }; + + +@@ -811,7 +839,6 @@ static int __init dino_common_init(struct parisc_device *dev, + { + int status; + u32 eim; +- struct gsc_irq gsc_irq; + struct resource *res; + + pcibios_register_hba(&dino_dev->hba); +@@ -826,10 +853,8 @@ static int __init dino_common_init(struct parisc_device *dev, + ** still only has 11 IRQ input lines - just map some of them + ** to a different processor. + */ +- dev->irq = gsc_alloc_irq(&gsc_irq); +- dino_dev->txn_addr = gsc_irq.txn_addr; +- dino_dev->txn_data = gsc_irq.txn_data; +- eim = ((u32) gsc_irq.txn_addr) | gsc_irq.txn_data; ++ dev->irq = gsc_alloc_irq(&dino_dev->gsc_irq); ++ eim = ((u32) dino_dev->gsc_irq.txn_addr) | dino_dev->gsc_irq.txn_data; + + /* + ** Dino needs a PA "IRQ" to get a processor's attention. +diff --git a/drivers/parisc/gsc.c b/drivers/parisc/gsc.c +index 1bab5a2cd359..a0cae6194591 100644 +--- a/drivers/parisc/gsc.c ++++ b/drivers/parisc/gsc.c +@@ -139,10 +139,41 @@ static void gsc_asic_unmask_irq(struct irq_data *d) + */ + } + ++#ifdef CONFIG_SMP ++static int gsc_set_affinity_irq(struct irq_data *d, const struct cpumask *dest, ++ bool force) ++{ ++ struct gsc_asic *gsc_dev = irq_data_get_irq_chip_data(d); ++ struct cpumask tmask; ++ int cpu_irq; ++ ++ if (!cpumask_and(&tmask, dest, cpu_online_mask)) ++ return -EINVAL; ++ ++ cpu_irq = cpu_check_affinity(d, &tmask); ++ if (cpu_irq < 0) ++ return cpu_irq; ++ ++ gsc_dev->gsc_irq.txn_addr = txn_affinity_addr(d->irq, cpu_irq); ++ gsc_dev->eim = ((u32) gsc_dev->gsc_irq.txn_addr) | gsc_dev->gsc_irq.txn_data; ++ ++ /* switch IRQ's for devices below LASI/WAX to other CPU */ ++ gsc_writel(gsc_dev->eim, gsc_dev->hpa + OFFSET_IAR); ++ ++ irq_data_update_effective_affinity(d, &tmask); ++ ++ return IRQ_SET_MASK_OK; ++} ++#endif ++ ++ + static struct irq_chip gsc_asic_interrupt_type = { + .name = "GSC-ASIC", + .irq_unmask = gsc_asic_unmask_irq, + .irq_mask = gsc_asic_mask_irq, ++#ifdef CONFIG_SMP ++ .irq_set_affinity = gsc_set_affinity_irq, ++#endif + }; + + int gsc_assign_irq(struct irq_chip *type, void *data) +diff --git a/drivers/parisc/gsc.h b/drivers/parisc/gsc.h +index b9d7bfb68e24..9a364a4d09a5 100644 +--- a/drivers/parisc/gsc.h ++++ b/drivers/parisc/gsc.h +@@ -32,6 +32,7 @@ struct gsc_asic { + int version; + int type; + int eim; ++ struct gsc_irq gsc_irq; + int global_irq[32]; + }; + +diff --git a/drivers/parisc/lasi.c b/drivers/parisc/lasi.c +index 4c9225431500..07ac0b8ee4fe 100644 +--- a/drivers/parisc/lasi.c ++++ b/drivers/parisc/lasi.c +@@ -167,7 +167,6 @@ static int __init lasi_init_chip(struct parisc_device *dev) + { + extern void (*chassis_power_off)(void); + struct gsc_asic *lasi; +- struct gsc_irq gsc_irq; + int ret; + + lasi = kzalloc(sizeof(*lasi), GFP_KERNEL); +@@ -189,7 +188,7 @@ static int __init lasi_init_chip(struct parisc_device *dev) + lasi_init_irq(lasi); + + /* the IRQ lasi should use */ +- dev->irq = gsc_alloc_irq(&gsc_irq); ++ dev->irq = gsc_alloc_irq(&lasi->gsc_irq); + if (dev->irq < 0) { + printk(KERN_ERR "%s(): cannot get GSC irq\n", + __func__); +@@ -197,9 +196,9 @@ static int __init lasi_init_chip(struct parisc_device *dev) + return -EBUSY; + } + +- lasi->eim = ((u32) gsc_irq.txn_addr) | gsc_irq.txn_data; ++ lasi->eim = ((u32) lasi->gsc_irq.txn_addr) | lasi->gsc_irq.txn_data; + +- ret = request_irq(gsc_irq.irq, gsc_asic_intr, 0, "lasi", lasi); ++ ret = request_irq(lasi->gsc_irq.irq, gsc_asic_intr, 0, "lasi", lasi); + if (ret < 0) { + kfree(lasi); + return ret; +diff --git a/drivers/parisc/wax.c b/drivers/parisc/wax.c +index 6a3e40702b3b..5c42bfa83398 100644 +--- a/drivers/parisc/wax.c ++++ b/drivers/parisc/wax.c +@@ -72,7 +72,6 @@ static int __init wax_init_chip(struct parisc_device *dev) + { + struct gsc_asic *wax; + struct parisc_device *parent; +- struct gsc_irq gsc_irq; + int ret; + + wax = kzalloc(sizeof(*wax), GFP_KERNEL); +@@ -89,7 +88,7 @@ static int __init wax_init_chip(struct parisc_device *dev) + wax_init_irq(wax); + + /* the IRQ wax should use */ +- dev->irq = gsc_claim_irq(&gsc_irq, WAX_GSC_IRQ); ++ dev->irq = gsc_claim_irq(&wax->gsc_irq, WAX_GSC_IRQ); + if (dev->irq < 0) { + printk(KERN_ERR "%s(): cannot get GSC irq\n", + __func__); +@@ -97,9 +96,9 @@ static int __init wax_init_chip(struct parisc_device *dev) + return -EBUSY; + } + +- wax->eim = ((u32) gsc_irq.txn_addr) | gsc_irq.txn_data; ++ wax->eim = ((u32) wax->gsc_irq.txn_addr) | wax->gsc_irq.txn_data; + +- ret = request_irq(gsc_irq.irq, gsc_asic_intr, 0, "wax", wax); ++ ret = request_irq(wax->gsc_irq.irq, gsc_asic_intr, 0, "wax", wax); + if (ret < 0) { + kfree(wax); + return ret; +-- +2.35.1 + diff --git a/queue-4.19/pci-aardvark-fix-support-for-msi-interrupts.patch b/queue-4.19/pci-aardvark-fix-support-for-msi-interrupts.patch new file mode 100644 index 00000000000..69c4af8acd1 --- /dev/null +++ b/queue-4.19/pci-aardvark-fix-support-for-msi-interrupts.patch @@ -0,0 +1,84 @@ +From 5a18eb9886f488b018f8dfebf696ca6f27c46503 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 10 Jan 2022 02:49:58 +0100 +Subject: PCI: aardvark: Fix support for MSI interrupts +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +[ Upstream commit b0b0b8b897f8e12b2368e868bd7cdc5742d5c5a9 ] + +Aardvark hardware supports Multi-MSI and MSI_FLAG_MULTI_PCI_MSI is already +set for the MSI chip. But when allocating MSI interrupt numbers for +Multi-MSI, the numbers need to be properly aligned, otherwise endpoint +devices send MSI interrupt with incorrect numbers. + +Fix this issue by using function bitmap_find_free_region() instead of +bitmap_find_next_zero_area(). + +To ensure that aligned MSI interrupt numbers are used by endpoint devices, +we cannot use Linux virtual irq numbers (as they are random and not +properly aligned). Instead we need to use the aligned hwirq numbers. + +This change fixes receiving MSI interrupts on Armada 3720 boards and +allows using NVMe disks which use Multi-MSI feature with 3 interrupts. + +Without this NVMe disks freeze booting as linux nvme-core.c is waiting +60s for an interrupt. + +Link: https://lore.kernel.org/r/20220110015018.26359-4-kabel@kernel.org +Signed-off-by: Pali Rohár +Signed-off-by: Marek Behún +Signed-off-by: Lorenzo Pieralisi +Signed-off-by: Sasha Levin +--- + drivers/pci/controller/pci-aardvark.c | 16 ++++++---------- + 1 file changed, 6 insertions(+), 10 deletions(-) + +diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c +index e6d60fa2217d..db778a25bae3 100644 +--- a/drivers/pci/controller/pci-aardvark.c ++++ b/drivers/pci/controller/pci-aardvark.c +@@ -833,7 +833,7 @@ static void advk_msi_irq_compose_msi_msg(struct irq_data *data, + + msg->address_lo = lower_32_bits(msi_msg); + msg->address_hi = upper_32_bits(msi_msg); +- msg->data = data->irq; ++ msg->data = data->hwirq; + } + + static int advk_msi_set_affinity(struct irq_data *irq_data, +@@ -850,15 +850,11 @@ static int advk_msi_irq_domain_alloc(struct irq_domain *domain, + int hwirq, i; + + mutex_lock(&pcie->msi_used_lock); +- hwirq = bitmap_find_next_zero_area(pcie->msi_used, MSI_IRQ_NUM, +- 0, nr_irqs, 0); +- if (hwirq >= MSI_IRQ_NUM) { +- mutex_unlock(&pcie->msi_used_lock); +- return -ENOSPC; +- } +- +- bitmap_set(pcie->msi_used, hwirq, nr_irqs); ++ hwirq = bitmap_find_free_region(pcie->msi_used, MSI_IRQ_NUM, ++ order_base_2(nr_irqs)); + mutex_unlock(&pcie->msi_used_lock); ++ if (hwirq < 0) ++ return -ENOSPC; + + for (i = 0; i < nr_irqs; i++) + irq_domain_set_info(domain, virq + i, hwirq + i, +@@ -876,7 +872,7 @@ static void advk_msi_irq_domain_free(struct irq_domain *domain, + struct advk_pcie *pcie = domain->host_data; + + mutex_lock(&pcie->msi_used_lock); +- bitmap_clear(pcie->msi_used, d->hwirq, nr_irqs); ++ bitmap_release_region(pcie->msi_used, d->hwirq, order_base_2(nr_irqs)); + mutex_unlock(&pcie->msi_used_lock); + } + +-- +2.35.1 + diff --git a/queue-4.19/pci-pciehp-add-qualcomm-quirk-for-command-completed-.patch b/queue-4.19/pci-pciehp-add-qualcomm-quirk-for-command-completed-.patch new file mode 100644 index 00000000000..51448b2ff9e --- /dev/null +++ b/queue-4.19/pci-pciehp-add-qualcomm-quirk-for-command-completed-.patch @@ -0,0 +1,44 @@ +From 72f2d4daed54788c9df8135819c5d33b2fa7e177 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 10 Feb 2022 20:20:03 +0530 +Subject: PCI: pciehp: Add Qualcomm quirk for Command Completed erratum + +From: Manivannan Sadhasivam + +[ Upstream commit 9f72d4757cbe4d1ed669192f6d23817c9e437c4b ] + +The Qualcomm PCI bridge device (Device ID 0x0110) found in chipsets such as +SM8450 does not set the Command Completed bit unless writes to the Slot +Command register change "Control" bits. + +This results in timeouts like below: + + pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) + +Add the device to the Command Completed quirk to mark commands "completed" +immediately unless they change the "Control" bits. + +Link: https://lore.kernel.org/r/20220210145003.135907-1-manivannan.sadhasivam@linaro.org +Signed-off-by: Manivannan Sadhasivam +Signed-off-by: Bjorn Helgaas +Signed-off-by: Sasha Levin +--- + drivers/pci/hotplug/pciehp_hpc.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c +index 0fdde66a49f1..2795445233b3 100644 +--- a/drivers/pci/hotplug/pciehp_hpc.c ++++ b/drivers/pci/hotplug/pciehp_hpc.c +@@ -971,6 +971,8 @@ static void quirk_cmd_compl(struct pci_dev *pdev) + } + DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); ++DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_QCOM, 0x0110, ++ PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); + DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_QCOM, 0x0400, + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); + DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_QCOM, 0x0401, +-- +2.35.1 + diff --git a/queue-4.19/power-supply-axp20x_battery-properly-report-current-.patch b/queue-4.19/power-supply-axp20x_battery-properly-report-current-.patch new file mode 100644 index 00000000000..7c78ff9d167 --- /dev/null +++ b/queue-4.19/power-supply-axp20x_battery-properly-report-current-.patch @@ -0,0 +1,63 @@ +From b16d9785a959e0a7582c575e085051008fdf4ed8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Jan 2022 11:47:27 +0300 +Subject: power: supply: axp20x_battery: properly report current when + discharging + +From: Evgeny Boger + +[ Upstream commit d4f408cdcd26921c1268cb8dcbe8ffb6faf837f3 ] + +As stated in [1], negative current values are used for discharging +batteries. + +AXP PMICs internally have two different ADC channels for shunt current +measurement: one used during charging and one during discharging. +The values reported by these ADCs are unsigned. +While the driver properly selects ADC channel to get the data from, +it doesn't apply negative sign when reporting discharging current. + +[1] Documentation/ABI/testing/sysfs-class-power + +Signed-off-by: Evgeny Boger +Acked-by: Chen-Yu Tsai +Signed-off-by: Sebastian Reichel +Signed-off-by: Sasha Levin +--- + drivers/power/supply/axp20x_battery.c | 13 ++++++------- + 1 file changed, 6 insertions(+), 7 deletions(-) + +diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c +index e84b6e4da14a..9fda98b950ba 100644 +--- a/drivers/power/supply/axp20x_battery.c ++++ b/drivers/power/supply/axp20x_battery.c +@@ -185,7 +185,6 @@ static int axp20x_battery_get_prop(struct power_supply *psy, + union power_supply_propval *val) + { + struct axp20x_batt_ps *axp20x_batt = power_supply_get_drvdata(psy); +- struct iio_channel *chan; + int ret = 0, reg, val1; + + switch (psp) { +@@ -265,12 +264,12 @@ static int axp20x_battery_get_prop(struct power_supply *psy, + if (ret) + return ret; + +- if (reg & AXP20X_PWR_STATUS_BAT_CHARGING) +- chan = axp20x_batt->batt_chrg_i; +- else +- chan = axp20x_batt->batt_dischrg_i; +- +- ret = iio_read_channel_processed(chan, &val->intval); ++ if (reg & AXP20X_PWR_STATUS_BAT_CHARGING) { ++ ret = iio_read_channel_processed(axp20x_batt->batt_chrg_i, &val->intval); ++ } else { ++ ret = iio_read_channel_processed(axp20x_batt->batt_dischrg_i, &val1); ++ val->intval = -val1; ++ } + if (ret) + return ret; + +-- +2.35.1 + diff --git a/queue-4.19/powerpc-code-patching-pre-map-patch-area.patch b/queue-4.19/powerpc-code-patching-pre-map-patch-area.patch new file mode 100644 index 00000000000..eb24fecf970 --- /dev/null +++ b/queue-4.19/powerpc-code-patching-pre-map-patch-area.patch @@ -0,0 +1,99 @@ +From 6f97e4943659dbc7d20c176aaa564adc43d6d262 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 23 Feb 2022 12:58:21 +1100 +Subject: powerpc/code-patching: Pre-map patch area + +From: Michael Ellerman + +[ Upstream commit 591b4b268435f00d2f0b81f786c2c7bd5ef66416 ] + +Paul reported a warning with DEBUG_ATOMIC_SLEEP=y: + + BUG: sleeping function called from invalid context at include/linux/sched/mm.h:256 + in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 + preempt_count: 0, expected: 0 + ... + Call Trace: + dump_stack_lvl+0xa0/0xec (unreliable) + __might_resched+0x2f4/0x310 + kmem_cache_alloc+0x220/0x4b0 + __pud_alloc+0x74/0x1d0 + hash__map_kernel_page+0x2cc/0x390 + do_patch_instruction+0x134/0x4a0 + arch_jump_label_transform+0x64/0x78 + __jump_label_update+0x148/0x180 + static_key_enable_cpuslocked+0xd0/0x120 + static_key_enable+0x30/0x50 + check_kvm_guest+0x60/0x88 + pSeries_smp_probe+0x54/0xb0 + smp_prepare_cpus+0x3e0/0x430 + kernel_init_freeable+0x20c/0x43c + kernel_init+0x30/0x1a0 + ret_from_kernel_thread+0x5c/0x64 + +Peter pointed out that this is because do_patch_instruction() has +disabled interrupts, but then map_patch_area() calls map_kernel_page() +then hash__map_kernel_page() which does a sleeping memory allocation. + +We only see the warning in KVM guests with SMT enabled, which is not +particularly common, or on other platforms if CONFIG_KPROBES is +disabled, also not common. The reason we don't see it in most +configurations is that another path that happens to have interrupts +enabled has allocated the required page tables for us, eg. there's a +path in kprobes init that does that. That's just pure luck though. + +As Christophe suggested, the simplest solution is to do a dummy +map/unmap when we initialise the patching, so that any required page +table levels are pre-allocated before the first call to +do_patch_instruction(). This works because the unmap doesn't free any +page tables that were allocated by the map, it just clears the PTE, +leaving the page table levels there for the next map. + +Reported-by: Paul Menzel +Debugged-by: Peter Zijlstra +Suggested-by: Christophe Leroy +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20220223015821.473097-1-mpe@ellerman.id.au +Signed-off-by: Sasha Levin +--- + arch/powerpc/lib/code-patching.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c +index bb245dbf6c57..2b9a92ea2d89 100644 +--- a/arch/powerpc/lib/code-patching.c ++++ b/arch/powerpc/lib/code-patching.c +@@ -46,9 +46,14 @@ int raw_patch_instruction(unsigned int *addr, unsigned int instr) + #ifdef CONFIG_STRICT_KERNEL_RWX + static DEFINE_PER_CPU(struct vm_struct *, text_poke_area); + ++static int map_patch_area(void *addr, unsigned long text_poke_addr); ++static void unmap_patch_area(unsigned long addr); ++ + static int text_area_cpu_up(unsigned int cpu) + { + struct vm_struct *area; ++ unsigned long addr; ++ int err; + + area = get_vm_area(PAGE_SIZE, VM_ALLOC); + if (!area) { +@@ -56,6 +61,15 @@ static int text_area_cpu_up(unsigned int cpu) + cpu); + return -1; + } ++ ++ // Map/unmap the area to ensure all page tables are pre-allocated ++ addr = (unsigned long)area->addr; ++ err = map_patch_area(empty_zero_page, addr); ++ if (err) ++ return err; ++ ++ unmap_patch_area(addr); ++ + this_cpu_write(text_poke_area, area); + + return 0; +-- +2.35.1 + diff --git a/queue-4.19/powerpc-dts-t104xrdb-fix-phy-type-for-fman-4-5.patch b/queue-4.19/powerpc-dts-t104xrdb-fix-phy-type-for-fman-4-5.patch new file mode 100644 index 00000000000..57cef860d94 --- /dev/null +++ b/queue-4.19/powerpc-dts-t104xrdb-fix-phy-type-for-fman-4-5.patch @@ -0,0 +1,47 @@ +From a0c7aa76e459a176988a430663deb4da52ee1554 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 30 Dec 2021 18:11:21 +0300 +Subject: powerpc: dts: t104xrdb: fix phy type for FMAN 4/5 + +From: Maxim Kiselev + +[ Upstream commit 17846485dff91acce1ad47b508b633dffc32e838 ] + +T1040RDB has two RTL8211E-VB phys which requires setting +of internal delays for correct work. + +Changing the phy-connection-type property to `rgmii-id` +will fix this issue. + +Signed-off-by: Maxim Kiselev +Reviewed-by: Maxim Kochetkov +Reviewed-by: Vladimir Oltean +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211230151123.1258321-1-bigunclemax@gmail.com +Signed-off-by: Sasha Levin +--- + arch/powerpc/boot/dts/fsl/t104xrdb.dtsi | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi b/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi +index 099a598c74c0..bfe1ed5be337 100644 +--- a/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi ++++ b/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi +@@ -139,12 +139,12 @@ + fman@400000 { + ethernet@e6000 { + phy-handle = <&phy_rgmii_0>; +- phy-connection-type = "rgmii"; ++ phy-connection-type = "rgmii-id"; + }; + + ethernet@e8000 { + phy-handle = <&phy_rgmii_1>; +- phy-connection-type = "rgmii"; ++ phy-connection-type = "rgmii-id"; + }; + + mdio0: mdio@fc000 { +-- +2.35.1 + diff --git a/queue-4.19/powerpc-set-crashkernel-offset-to-mid-of-rma-region.patch b/queue-4.19/powerpc-set-crashkernel-offset-to-mid-of-rma-region.patch new file mode 100644 index 00000000000..25567a17f43 --- /dev/null +++ b/queue-4.19/powerpc-set-crashkernel-offset-to-mid-of-rma-region.patch @@ -0,0 +1,90 @@ +From 49a8cc045ffd2fd9345ded38dbfb8c16cc9ca7a8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 4 Feb 2022 14:26:01 +0530 +Subject: powerpc: Set crashkernel offset to mid of RMA region + +From: Sourabh Jain + +[ Upstream commit 7c5ed82b800d8615cdda00729e7b62e5899f0b13 ] + +On large config LPARs (having 192 and more cores), Linux fails to boot +due to insufficient memory in the first memblock. It is due to the +memory reservation for the crash kernel which starts at 128MB offset of +the first memblock. This memory reservation for the crash kernel doesn't +leave enough space in the first memblock to accommodate other essential +system resources. + +The crash kernel start address was set to 128MB offset by default to +ensure that the crash kernel get some memory below the RMA region which +is used to be of size 256MB. But given that the RMA region size can be +512MB or more, setting the crash kernel offset to mid of RMA size will +leave enough space for the kernel to allocate memory for other system +resources. + +Since the above crash kernel offset change is only applicable to the LPAR +platform, the LPAR feature detection is pushed before the crash kernel +reservation. The rest of LPAR specific initialization will still +be done during pseries_probe_fw_features as usual. + +This patch is dependent on changes to paca allocation for boot CPU. It +expect boot CPU to discover 1T segment support which is introduced by +the patch posted here: +https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/239175.html + +Reported-by: Abdul haleem +Signed-off-by: Sourabh Jain +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20220204085601.107257-1-sourabhjain@linux.ibm.com +Signed-off-by: Sasha Levin +--- + arch/powerpc/kernel/machine_kexec.c | 15 +++++++++++---- + arch/powerpc/kernel/rtas.c | 6 ++++++ + 2 files changed, 17 insertions(+), 4 deletions(-) + +diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c +index 094c37fb07a9..437c50bfe4e6 100644 +--- a/arch/powerpc/kernel/machine_kexec.c ++++ b/arch/powerpc/kernel/machine_kexec.c +@@ -148,11 +148,18 @@ void __init reserve_crashkernel(void) + if (!crashk_res.start) { + #ifdef CONFIG_PPC64 + /* +- * On 64bit we split the RMO in half but cap it at half of +- * a small SLB (128MB) since the crash kernel needs to place +- * itself and some stacks to be in the first segment. ++ * On the LPAR platform place the crash kernel to mid of ++ * RMA size (512MB or more) to ensure the crash kernel ++ * gets enough space to place itself and some stack to be ++ * in the first segment. At the same time normal kernel ++ * also get enough space to allocate memory for essential ++ * system resource in the first segment. Keep the crash ++ * kernel starts at 128MB offset on other platforms. + */ +- crashk_res.start = min(0x8000000ULL, (ppc64_rma_size / 2)); ++ if (firmware_has_feature(FW_FEATURE_LPAR)) ++ crashk_res.start = ppc64_rma_size / 2; ++ else ++ crashk_res.start = min(0x8000000ULL, (ppc64_rma_size / 2)); + #else + crashk_res.start = KDUMP_KERNELBASE; + #endif +diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c +index b3aa0cea6283..362c20c8c22f 100644 +--- a/arch/powerpc/kernel/rtas.c ++++ b/arch/powerpc/kernel/rtas.c +@@ -1357,6 +1357,12 @@ int __init early_init_dt_scan_rtas(unsigned long node, + entryp = of_get_flat_dt_prop(node, "linux,rtas-entry", NULL); + sizep = of_get_flat_dt_prop(node, "rtas-size", NULL); + ++#ifdef CONFIG_PPC64 ++ /* need this feature to decide the crashkernel offset */ ++ if (of_get_flat_dt_prop(node, "ibm,hypertas-functions", NULL)) ++ powerpc_firmware_features |= FW_FEATURE_LPAR; ++#endif ++ + if (basep && entryp && sizep) { + rtas.base = *basep; + rtas.entry = *entryp; +-- +2.35.1 + diff --git a/queue-4.19/ptp-replace-snprintf-with-sysfs_emit.patch b/queue-4.19/ptp-replace-snprintf-with-sysfs_emit.patch new file mode 100644 index 00000000000..4854fa35526 --- /dev/null +++ b/queue-4.19/ptp-replace-snprintf-with-sysfs_emit.patch @@ -0,0 +1,52 @@ +From 6ea8fdae5a01ca0e36503c1b0336832888c5ce41 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Jan 2022 08:02:36 +0800 +Subject: ptp: replace snprintf with sysfs_emit + +From: Yang Guang + +[ Upstream commit e2cf07654efb0fd7bbcb475c6f74be7b5755a8fd ] + +coccinelle report: +./drivers/ptp/ptp_sysfs.c:17:8-16: +WARNING: use scnprintf or sprintf +./drivers/ptp/ptp_sysfs.c:390:8-16: +WARNING: use scnprintf or sprintf + +Use sysfs_emit instead of scnprintf or sprintf makes more sense. + +Reported-by: Zeal Robot +Signed-off-by: Yang Guang +Signed-off-by: David Yang +Acked-by: Richard Cochran +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/ptp/ptp_sysfs.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c +index 48401dfcd999..f97a5eefa2e2 100644 +--- a/drivers/ptp/ptp_sysfs.c ++++ b/drivers/ptp/ptp_sysfs.c +@@ -26,7 +26,7 @@ static ssize_t clock_name_show(struct device *dev, + struct device_attribute *attr, char *page) + { + struct ptp_clock *ptp = dev_get_drvdata(dev); +- return snprintf(page, PAGE_SIZE-1, "%s\n", ptp->info->name); ++ return sysfs_emit(page, "%s\n", ptp->info->name); + } + static DEVICE_ATTR_RO(clock_name); + +@@ -240,7 +240,7 @@ static ssize_t ptp_pin_show(struct device *dev, struct device_attribute *attr, + + mutex_unlock(&ptp->pincfg_mux); + +- return snprintf(page, PAGE_SIZE, "%u %u\n", func, chan); ++ return sysfs_emit(page, "%u %u\n", func, chan); + } + + static ssize_t ptp_pin_store(struct device *dev, struct device_attribute *attr, +-- +2.35.1 + diff --git a/queue-4.19/riscv-module-remove-noload.patch b/queue-4.19/riscv-module-remove-noload.patch new file mode 100644 index 00000000000..96b612be8ec --- /dev/null +++ b/queue-4.19/riscv-module-remove-noload.patch @@ -0,0 +1,53 @@ +From 3866936c0f344b42ca79604fcae2f9839a9e1317 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 21 Mar 2022 18:26:17 -0700 +Subject: riscv module: remove (NOLOAD) + +From: Fangrui Song + +[ Upstream commit 60210a3d86dc57ce4a76a366e7841dda746a33f7 ] + +On ELF, (NOLOAD) sets the section type to SHT_NOBITS[1]. It is conceptually +inappropriate for .plt, .got, and .got.plt sections which are always +SHT_PROGBITS. + +In GNU ld, if PLT entries are needed, .plt will be SHT_PROGBITS anyway +and (NOLOAD) will be essentially ignored. In ld.lld, since +https://reviews.llvm.org/D118840 ("[ELF] Support (TYPE=) to +customize the output section type"), ld.lld will report a `section type +mismatch` error (later changed to a warning). Just remove (NOLOAD) to +fix the warning. + +[1] https://lld.llvm.org/ELF/linker_script.html As of today, "The +section should be marked as not loadable" on +https://sourceware.org/binutils/docs/ld/Output-Section-Type.html is +outdated for ELF. + +Link: https://github.com/ClangBuiltLinux/linux/issues/1597 +Fixes: ab1ef68e5401 ("RISC-V: Add sections of PLT and GOT for kernel module") +Reported-by: Nathan Chancellor +Signed-off-by: Fangrui Song +Signed-off-by: Palmer Dabbelt +Signed-off-by: Sasha Levin +--- + arch/riscv/kernel/module.lds | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/arch/riscv/kernel/module.lds b/arch/riscv/kernel/module.lds +index 295ecfb341a2..18ec719899e2 100644 +--- a/arch/riscv/kernel/module.lds ++++ b/arch/riscv/kernel/module.lds +@@ -2,7 +2,7 @@ + /* Copyright (C) 2017 Andes Technology Corporation */ + + SECTIONS { +- .plt (NOLOAD) : { BYTE(0) } +- .got (NOLOAD) : { BYTE(0) } +- .got.plt (NOLOAD) : { BYTE(0) } ++ .plt : { BYTE(0) } ++ .got : { BYTE(0) } ++ .got.plt : { BYTE(0) } + } +-- +2.35.1 + diff --git a/queue-4.19/rtc-wm8350-handle-error-for-wm8350_register_irq.patch b/queue-4.19/rtc-wm8350-handle-error-for-wm8350_register_irq.patch new file mode 100644 index 00000000000..42164e45505 --- /dev/null +++ b/queue-4.19/rtc-wm8350-handle-error-for-wm8350_register_irq.patch @@ -0,0 +1,55 @@ +From 92a4860ce50c0bb7b5ec63cf20dcbfda7af4677b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 3 Mar 2022 16:50:30 +0800 +Subject: rtc: wm8350: Handle error for wm8350_register_irq + +From: Jiasheng Jiang + +[ Upstream commit 43f0269b6b89c1eec4ef83c48035608f4dcdd886 ] + +As the potential failure of the wm8350_register_irq(), +it should be better to check it and return error if fails. +Also, it need not free 'wm_rtc->rtc' since it will be freed +automatically. + +Fixes: 077eaf5b40ec ("rtc: rtc-wm8350: add support for WM8350 RTC") +Signed-off-by: Jiasheng Jiang +Acked-by: Charles Keepax +Signed-off-by: Alexandre Belloni +Link: https://lore.kernel.org/r/20220303085030.291793-1-jiasheng@iscas.ac.cn +Signed-off-by: Sasha Levin +--- + drivers/rtc/rtc-wm8350.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +diff --git a/drivers/rtc/rtc-wm8350.c b/drivers/rtc/rtc-wm8350.c +index 483c7993516b..ed874e5c5fc8 100644 +--- a/drivers/rtc/rtc-wm8350.c ++++ b/drivers/rtc/rtc-wm8350.c +@@ -441,14 +441,21 @@ static int wm8350_rtc_probe(struct platform_device *pdev) + return ret; + } + +- wm8350_register_irq(wm8350, WM8350_IRQ_RTC_SEC, ++ ret = wm8350_register_irq(wm8350, WM8350_IRQ_RTC_SEC, + wm8350_rtc_update_handler, 0, + "RTC Seconds", wm8350); ++ if (ret) ++ return ret; ++ + wm8350_mask_irq(wm8350, WM8350_IRQ_RTC_SEC); + +- wm8350_register_irq(wm8350, WM8350_IRQ_RTC_ALM, ++ ret = wm8350_register_irq(wm8350, WM8350_IRQ_RTC_ALM, + wm8350_rtc_alarm_handler, 0, + "RTC Alarm", wm8350); ++ if (ret) { ++ wm8350_free_irq(wm8350, WM8350_IRQ_RTC_SEC, wm8350); ++ return ret; ++ } + + return 0; + } +-- +2.35.1 + diff --git a/queue-4.19/scsi-aha152x-fix-aha152x_setup-__setup-handler-retur.patch b/queue-4.19/scsi-aha152x-fix-aha152x_setup-__setup-handler-retur.patch new file mode 100644 index 00000000000..6f8a1efeb5c --- /dev/null +++ b/queue-4.19/scsi-aha152x-fix-aha152x_setup-__setup-handler-retur.patch @@ -0,0 +1,52 @@ +From 82999a2b96272a1810955381b7391e90f2ae794f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Feb 2022 16:06:23 -0800 +Subject: scsi: aha152x: Fix aha152x_setup() __setup handler return value + +From: Randy Dunlap + +[ Upstream commit cc8294ec4738d25e2bb2d71f7d82a9bf7f4a157b ] + +__setup() handlers should return 1 if the command line option is handled +and 0 if not (or maybe never return 0; doing so just pollutes init's +environment with strings that are not init arguments/parameters). + +Return 1 from aha152x_setup() to indicate that the boot option has been +handled. + +Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru +Link: https://lore.kernel.org/r/20220223000623.5920-1-rdunlap@infradead.org +Cc: "Juergen E. Fischer" +Cc: "James E.J. Bottomley" +Cc: "Martin K. Petersen" +Reported-by: Igor Zhbanov +Signed-off-by: Randy Dunlap +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/aha152x.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +diff --git a/drivers/scsi/aha152x.c b/drivers/scsi/aha152x.c +index 4d7b0e0adbf7..2690098d4411 100644 +--- a/drivers/scsi/aha152x.c ++++ b/drivers/scsi/aha152x.c +@@ -3379,13 +3379,11 @@ static int __init aha152x_setup(char *str) + setup[setup_count].synchronous = ints[0] >= 6 ? ints[6] : 1; + setup[setup_count].delay = ints[0] >= 7 ? ints[7] : DELAY_DEFAULT; + setup[setup_count].ext_trans = ints[0] >= 8 ? ints[8] : 0; +- if (ints[0] > 8) { /*}*/ ++ if (ints[0] > 8) + printk(KERN_NOTICE "aha152x: usage: aha152x=[,[," + "[,[,[,[,[,]]]]]]]\n"); +- } else { ++ else + setup_count++; +- return 0; +- } + + return 1; + } +-- +2.35.1 + diff --git a/queue-4.19/scsi-bfa-replace-snprintf-with-sysfs_emit.patch b/queue-4.19/scsi-bfa-replace-snprintf-with-sysfs_emit.patch new file mode 100644 index 00000000000..9dd9920cd3e --- /dev/null +++ b/queue-4.19/scsi-bfa-replace-snprintf-with-sysfs_emit.patch @@ -0,0 +1,169 @@ +From 07fdec8b7fffc5bb76068fe2ec31c3d5cdb07ba9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Jan 2022 08:03:46 +0800 +Subject: scsi: bfa: Replace snprintf() with sysfs_emit() + +From: Yang Guang + +[ Upstream commit 2245ea91fd3a04cafbe2f54911432a8657528c3b ] + +coccinelle report: +./drivers/scsi/bfa/bfad_attr.c:908:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:860:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:888:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:853:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:808:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:728:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:822:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:927:9-17: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:900:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:874:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:714:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/bfa/bfad_attr.c:839:8-16: +WARNING: use scnprintf or sprintf + +Use sysfs_emit() instead of scnprintf() or sprintf(). + +Link: https://lore.kernel.org/r/def83ff75faec64ba592b867a8499b1367bae303.1643181468.git.yang.guang5@zte.com.cn +Reported-by: Zeal Robot +Signed-off-by: Yang Guang +Signed-off-by: David Yang +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/bfa/bfad_attr.c | 26 +++++++++++++------------- + 1 file changed, 13 insertions(+), 13 deletions(-) + +diff --git a/drivers/scsi/bfa/bfad_attr.c b/drivers/scsi/bfa/bfad_attr.c +index 3b84290cf0a7..eaab423a5fd0 100644 +--- a/drivers/scsi/bfa/bfad_attr.c ++++ b/drivers/scsi/bfa/bfad_attr.c +@@ -719,7 +719,7 @@ bfad_im_serial_num_show(struct device *dev, struct device_attribute *attr, + char serial_num[BFA_ADAPTER_SERIAL_NUM_LEN]; + + bfa_get_adapter_serial_num(&bfad->bfa, serial_num); +- return snprintf(buf, PAGE_SIZE, "%s\n", serial_num); ++ return sysfs_emit(buf, "%s\n", serial_num); + } + + static ssize_t +@@ -733,7 +733,7 @@ bfad_im_model_show(struct device *dev, struct device_attribute *attr, + char model[BFA_ADAPTER_MODEL_NAME_LEN]; + + bfa_get_adapter_model(&bfad->bfa, model); +- return snprintf(buf, PAGE_SIZE, "%s\n", model); ++ return sysfs_emit(buf, "%s\n", model); + } + + static ssize_t +@@ -813,7 +813,7 @@ bfad_im_model_desc_show(struct device *dev, struct device_attribute *attr, + snprintf(model_descr, BFA_ADAPTER_MODEL_DESCR_LEN, + "Invalid Model"); + +- return snprintf(buf, PAGE_SIZE, "%s\n", model_descr); ++ return sysfs_emit(buf, "%s\n", model_descr); + } + + static ssize_t +@@ -827,7 +827,7 @@ bfad_im_node_name_show(struct device *dev, struct device_attribute *attr, + u64 nwwn; + + nwwn = bfa_fcs_lport_get_nwwn(port->fcs_port); +- return snprintf(buf, PAGE_SIZE, "0x%llx\n", cpu_to_be64(nwwn)); ++ return sysfs_emit(buf, "0x%llx\n", cpu_to_be64(nwwn)); + } + + static ssize_t +@@ -844,7 +844,7 @@ bfad_im_symbolic_name_show(struct device *dev, struct device_attribute *attr, + bfa_fcs_lport_get_attr(&bfad->bfa_fcs.fabric.bport, &port_attr); + strlcpy(symname, port_attr.port_cfg.sym_name.symname, + BFA_SYMNAME_MAXLEN); +- return snprintf(buf, PAGE_SIZE, "%s\n", symname); ++ return sysfs_emit(buf, "%s\n", symname); + } + + static ssize_t +@@ -858,14 +858,14 @@ bfad_im_hw_version_show(struct device *dev, struct device_attribute *attr, + char hw_ver[BFA_VERSION_LEN]; + + bfa_get_pci_chip_rev(&bfad->bfa, hw_ver); +- return snprintf(buf, PAGE_SIZE, "%s\n", hw_ver); ++ return sysfs_emit(buf, "%s\n", hw_ver); + } + + static ssize_t + bfad_im_drv_version_show(struct device *dev, struct device_attribute *attr, + char *buf) + { +- return snprintf(buf, PAGE_SIZE, "%s\n", BFAD_DRIVER_VERSION); ++ return sysfs_emit(buf, "%s\n", BFAD_DRIVER_VERSION); + } + + static ssize_t +@@ -879,7 +879,7 @@ bfad_im_optionrom_version_show(struct device *dev, + char optrom_ver[BFA_VERSION_LEN]; + + bfa_get_adapter_optrom_ver(&bfad->bfa, optrom_ver); +- return snprintf(buf, PAGE_SIZE, "%s\n", optrom_ver); ++ return sysfs_emit(buf, "%s\n", optrom_ver); + } + + static ssize_t +@@ -893,7 +893,7 @@ bfad_im_fw_version_show(struct device *dev, struct device_attribute *attr, + char fw_ver[BFA_VERSION_LEN]; + + bfa_get_adapter_fw_ver(&bfad->bfa, fw_ver); +- return snprintf(buf, PAGE_SIZE, "%s\n", fw_ver); ++ return sysfs_emit(buf, "%s\n", fw_ver); + } + + static ssize_t +@@ -905,7 +905,7 @@ bfad_im_num_of_ports_show(struct device *dev, struct device_attribute *attr, + (struct bfad_im_port_s *) shost->hostdata[0]; + struct bfad_s *bfad = im_port->bfad; + +- return snprintf(buf, PAGE_SIZE, "%d\n", ++ return sysfs_emit(buf, "%d\n", + bfa_get_nports(&bfad->bfa)); + } + +@@ -913,7 +913,7 @@ static ssize_t + bfad_im_drv_name_show(struct device *dev, struct device_attribute *attr, + char *buf) + { +- return snprintf(buf, PAGE_SIZE, "%s\n", BFAD_DRIVER_NAME); ++ return sysfs_emit(buf, "%s\n", BFAD_DRIVER_NAME); + } + + static ssize_t +@@ -932,14 +932,14 @@ bfad_im_num_of_discovered_ports_show(struct device *dev, + rports = kcalloc(nrports, sizeof(struct bfa_rport_qualifier_s), + GFP_ATOMIC); + if (rports == NULL) +- return snprintf(buf, PAGE_SIZE, "Failed\n"); ++ return sysfs_emit(buf, "Failed\n"); + + spin_lock_irqsave(&bfad->bfad_lock, flags); + bfa_fcs_lport_get_rport_quals(port->fcs_port, rports, &nrports); + spin_unlock_irqrestore(&bfad->bfad_lock, flags); + kfree(rports); + +- return snprintf(buf, PAGE_SIZE, "%d\n", nrports); ++ return sysfs_emit(buf, "%d\n", nrports); + } + + static DEVICE_ATTR(serial_number, S_IRUGO, +-- +2.35.1 + diff --git a/queue-4.19/scsi-libfc-fix-use-after-free-in-fc_exch_abts_resp.patch b/queue-4.19/scsi-libfc-fix-use-after-free-in-fc_exch_abts_resp.patch new file mode 100644 index 00000000000..4363ae5fa72 --- /dev/null +++ b/queue-4.19/scsi-libfc-fix-use-after-free-in-fc_exch_abts_resp.patch @@ -0,0 +1,39 @@ +From 509a63f14c32f682b2457a3749ead2aa82711bcb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 3 Mar 2022 09:51:15 +0800 +Subject: scsi: libfc: Fix use after free in fc_exch_abts_resp() + +From: Jianglei Nie + +[ Upstream commit 271add11994ba1a334859069367e04d2be2ebdd4 ] + +fc_exch_release(ep) will decrease the ep's reference count. When the +reference count reaches zero, it is freed. But ep is still used in the +following code, which will lead to a use after free. + +Return after the fc_exch_release() call to avoid use after free. + +Link: https://lore.kernel.org/r/20220303015115.459778-1-niejianglei2021@163.com +Reviewed-by: Hannes Reinecke +Signed-off-by: Jianglei Nie +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/libfc/fc_exch.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c +index 384458d1f73c..9fa0aa235cb4 100644 +--- a/drivers/scsi/libfc/fc_exch.c ++++ b/drivers/scsi/libfc/fc_exch.c +@@ -1709,6 +1709,7 @@ static void fc_exch_abts_resp(struct fc_exch *ep, struct fc_frame *fp) + if (cancel_delayed_work_sync(&ep->timeout_work)) { + FC_EXCH_DBG(ep, "Exchange timer canceled due to ABTS response\n"); + fc_exch_release(ep); /* release from pending timer hold */ ++ return; + } + + spin_lock_bh(&ep->ex_lock); +-- +2.35.1 + diff --git a/queue-4.19/scsi-mvsas-replace-snprintf-with-sysfs_emit.patch b/queue-4.19/scsi-mvsas-replace-snprintf-with-sysfs_emit.patch new file mode 100644 index 00000000000..629d8869e75 --- /dev/null +++ b/queue-4.19/scsi-mvsas-replace-snprintf-with-sysfs_emit.patch @@ -0,0 +1,52 @@ +From 8dc748827a7469b61c7010cdfd3024f4b79fc984 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Jan 2022 08:00:59 +0800 +Subject: scsi: mvsas: Replace snprintf() with sysfs_emit() + +From: Yang Guang + +[ Upstream commit 0ad3867b0f13e45cfee5a1298bfd40eef096116c ] + +coccinelle report: +./drivers/scsi/mvsas/mv_init.c:699:8-16: +WARNING: use scnprintf or sprintf +./drivers/scsi/mvsas/mv_init.c:747:8-16: +WARNING: use scnprintf or sprintf + +Use sysfs_emit() instead of scnprintf() or sprintf(). + +Link: https://lore.kernel.org/r/c1711f7cf251730a8ceb5bdfc313bf85662b3395.1643182948.git.yang.guang5@zte.com.cn +Reported-by: Zeal Robot +Signed-off-by: Yang Guang +Signed-off-by: David Yang +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/mvsas/mv_init.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c +index 98d6608068ab..9c48394ac68a 100644 +--- a/drivers/scsi/mvsas/mv_init.c ++++ b/drivers/scsi/mvsas/mv_init.c +@@ -729,7 +729,7 @@ static ssize_t + mvs_show_driver_version(struct device *cdev, + struct device_attribute *attr, char *buffer) + { +- return snprintf(buffer, PAGE_SIZE, "%s\n", DRV_VERSION); ++ return sysfs_emit(buffer, "%s\n", DRV_VERSION); + } + + static DEVICE_ATTR(driver_version, +@@ -781,7 +781,7 @@ mvs_store_interrupt_coalescing(struct device *cdev, + static ssize_t mvs_show_interrupt_coalescing(struct device *cdev, + struct device_attribute *attr, char *buffer) + { +- return snprintf(buffer, PAGE_SIZE, "%d\n", interrupt_coalescing); ++ return sysfs_emit(buffer, "%d\n", interrupt_coalescing); + } + + static DEVICE_ATTR(interrupt_coalescing, +-- +2.35.1 + diff --git a/queue-4.19/scsi-pm8001-fix-pm8001_mpi_task_abort_resp.patch b/queue-4.19/scsi-pm8001-fix-pm8001_mpi_task_abort_resp.patch new file mode 100644 index 00000000000..549b0beba07 --- /dev/null +++ b/queue-4.19/scsi-pm8001-fix-pm8001_mpi_task_abort_resp.patch @@ -0,0 +1,46 @@ +From 2790956141a85dc017aa277e86f051ca2b016c29 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 20 Feb 2022 12:17:57 +0900 +Subject: scsi: pm8001: Fix pm8001_mpi_task_abort_resp() + +From: Damien Le Moal + +[ Upstream commit 7e6b7e740addcea450041b5be8e42f0a4ceece0f ] + +The call to pm8001_ccb_task_free() at the end of +pm8001_mpi_task_abort_resp() already frees the ccb tag. So when the device +NCQ_ABORT_ALL_FLAG is set, the tag should not be freed again. Also change +the hardcoded 0xBFFFFFFF value to ~NCQ_ABORT_ALL_FLAG as it ought to be. + +Link: https://lore.kernel.org/r/20220220031810.738362-19-damien.lemoal@opensource.wdc.com +Reviewed-by: Jack Wang +Signed-off-by: Damien Le Moal +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/pm8001/pm8001_hwi.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +diff --git a/drivers/scsi/pm8001/pm8001_hwi.c b/drivers/scsi/pm8001/pm8001_hwi.c +index 5eabea5ca6a7..d532230c62f3 100644 +--- a/drivers/scsi/pm8001/pm8001_hwi.c ++++ b/drivers/scsi/pm8001/pm8001_hwi.c +@@ -3777,12 +3777,11 @@ int pm8001_mpi_task_abort_resp(struct pm8001_hba_info *pm8001_ha, void *piomb) + mb(); + + if (pm8001_dev->id & NCQ_ABORT_ALL_FLAG) { +- pm8001_tag_free(pm8001_ha, tag); + sas_free_task(t); +- /* clear the flag */ +- pm8001_dev->id &= 0xBFFFFFFF; +- } else ++ pm8001_dev->id &= ~NCQ_ABORT_ALL_FLAG; ++ } else { + t->task_done(t); ++ } + + return 0; + } +-- +2.35.1 + diff --git a/queue-4.19/serial-samsung_tty-do-not-unlock-port-lock-for-uart_.patch b/queue-4.19/serial-samsung_tty-do-not-unlock-port-lock-for-uart_.patch new file mode 100644 index 00000000000..384cfb7f841 --- /dev/null +++ b/queue-4.19/serial-samsung_tty-do-not-unlock-port-lock-for-uart_.patch @@ -0,0 +1,53 @@ +From 400bd0f044dbd43e7e7cde866e07cc2ea26ccaf1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Mar 2022 12:51:53 +0100 +Subject: serial: samsung_tty: do not unlock port->lock for uart_write_wakeup() + +From: Jiri Slaby + +[ Upstream commit 988c7c00691008ea1daaa1235680a0da49dab4e8 ] + +The commit c15c3747ee32 (serial: samsung: fix potential soft lockup +during uart write) added an unlock of port->lock before +uart_write_wakeup() and a lock after it. It was always problematic to +write data from tty_ldisc_ops::write_wakeup and it was even documented +that way. We fixed the line disciplines to conform to this recently. +So if there is still a missed one, we should fix them instead of this +workaround. + +On the top of that, s3c24xx_serial_tx_dma_complete() in this driver +still holds the port->lock while calling uart_write_wakeup(). + +So revert the wrap added by the commit above. + +Cc: Thomas Abraham +Cc: Kyungmin Park +Cc: Hyeonkook Kim +Signed-off-by: Jiri Slaby +Link: https://lore.kernel.org/r/20220308115153.4225-1-jslaby@suse.cz +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/samsung.c | 5 +---- + 1 file changed, 1 insertion(+), 4 deletions(-) + +diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c +index 1528a7ba2bf4..49661cef5469 100644 +--- a/drivers/tty/serial/samsung.c ++++ b/drivers/tty/serial/samsung.c +@@ -761,11 +761,8 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, void *id) + goto out; + } + +- if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) { +- spin_unlock(&port->lock); ++ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) + uart_write_wakeup(port); +- spin_lock(&port->lock); +- } + + if (uart_circ_empty(xmit)) + s3c24xx_serial_stop_tx(port); +-- +2.35.1 + diff --git a/queue-4.19/series b/queue-4.19/series index 4eb80a7de8a..ccedb8cc1c9 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -253,3 +253,51 @@ arm-dts-spear13xx-update-spi-dma-properties.patch um-fix-uml_mconsole-stop-go.patch openvswitch-fixed-nd-target-mask-field-in-the-flow-dump.patch kvm-x86-forbid-vmm-to-set-synic-stimer-msrs-when-synic-wasn-t-activated.patch +ubifs-rectify-space-amount-budget-for-mkdir-tmpfile-.patch +rtc-wm8350-handle-error-for-wm8350_register_irq.patch +riscv-module-remove-noload.patch +arm-9187-1-jive-fix-return-value-of-__setup-handler.patch +kvm-x86-svm-clear-reserved-bits-written-to-perfevtse.patch +drm-add-orientation-quirk-for-gpd-win-max.patch +ath5k-fix-oob-in-ath5k_eeprom_read_pcal_info_5111.patch +drm-amd-amdgpu-amdgpu_cs-fix-refcount-leak-of-a-dma_.patch +ptp-replace-snprintf-with-sysfs_emit.patch +powerpc-dts-t104xrdb-fix-phy-type-for-fman-4-5.patch +scsi-mvsas-replace-snprintf-with-sysfs_emit.patch +scsi-bfa-replace-snprintf-with-sysfs_emit.patch +power-supply-axp20x_battery-properly-report-current-.patch +powerpc-set-crashkernel-offset-to-mid-of-rma-region.patch +pci-aardvark-fix-support-for-msi-interrupts.patch +iommu-arm-smmu-v3-fix-event-handling-soft-lockup.patch +usb-ehci-add-pci-device-support-for-aspeed-platforms.patch +pci-pciehp-add-qualcomm-quirk-for-command-completed-.patch +ipv4-invalidate-neighbour-for-broadcast-address-upon.patch +dm-ioctl-prevent-potential-spectre-v1-gadget.patch +drm-amdkfd-make-crat-table-missing-message-informati.patch +scsi-pm8001-fix-pm8001_mpi_task_abort_resp.patch +scsi-aha152x-fix-aha152x_setup-__setup-handler-retur.patch +net-smc-correct-settings-of-rmb-window-update-limit.patch +macvtap-advertise-link-netns-via-netlink.patch +bnxt_en-eliminate-unintended-link-toggle-during-fw-r.patch +mips-fix-fortify-panic-when-copying-asm-exception-ha.patch +powerpc-code-patching-pre-map-patch-area.patch +scsi-libfc-fix-use-after-free-in-fc_exch_abts_resp.patch +usb-dwc3-omap-fix-unbalanced-disables-for-smps10_out.patch +xtensa-fix-dtc-warning-unit_address_format.patch +bluetooth-fix-use-after-free-in-hci_send_acl.patch +init-main.c-return-1-from-handled-__setup-functions.patch +minix-fix-bug-when-opening-a-file-with-o_direct.patch +w1-w1_therm-fixes-w1_seq-for-ds28ea00-sensors.patch +nfsv4-protect-the-state-recovery-thread-against-dire.patch +xen-delay-xen_hvm_init_time_ops-if-kdump-is-boot-on-.patch +clk-enforce-that-disjoints-limits-are-invalid.patch +sunrpc-call_alloc-async-tasks-mustn-t-block-waiting-.patch +nfs-swap-io-handling-is-slightly-different-for-o_dir.patch +nfs-swap-out-must-always-use-stable-writes.patch +serial-samsung_tty-do-not-unlock-port-lock-for-uart_.patch +virtio_console-eliminate-anonymous-module_init-modul.patch +jfs-prevent-null-deref-in-difree.patch +parisc-fix-cpu-affinity-for-lasi-wax-and-dino-chips.patch +net-add-missing-sof_timestamping_opt_id-support.patch +mm-fix-race-between-madv_free-reclaim-and-blkdev-dir.patch +kvm-arm64-check-arm64_get_bp_hardening_data-didn-t-r.patch diff --git a/queue-4.19/sunrpc-call_alloc-async-tasks-mustn-t-block-waiting-.patch b/queue-4.19/sunrpc-call_alloc-async-tasks-mustn-t-block-waiting-.patch new file mode 100644 index 00000000000..adc656779e6 --- /dev/null +++ b/queue-4.19/sunrpc-call_alloc-async-tasks-mustn-t-block-waiting-.patch @@ -0,0 +1,65 @@ +From ef3e218a3404c1d381c6ae099176098d3c05c4bb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 7 Mar 2022 10:41:44 +1100 +Subject: SUNRPC/call_alloc: async tasks mustn't block waiting for memory + +From: NeilBrown + +[ Upstream commit c487216bec83b0c5a8803e5c61433d33ad7b104d ] + +When memory is short, new worker threads cannot be created and we depend +on the minimum one rpciod thread to be able to handle everything. +So it must not block waiting for memory. + +mempools are particularly a problem as memory can only be released back +to the mempool by an async rpc task running. If all available +workqueue threads are waiting on the mempool, no thread is available to +return anything. + +rpc_malloc() can block, and this might cause deadlocks. +So check RPC_IS_ASYNC(), rather than RPC_IS_SWAPPER() to determine if +blocking is acceptable. + +Signed-off-by: NeilBrown +Signed-off-by: Trond Myklebust +Signed-off-by: Sasha Levin +--- + net/sunrpc/sched.c | 4 +++- + net/sunrpc/xprtrdma/transport.c | 4 +++- + 2 files changed, 6 insertions(+), 2 deletions(-) + +diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c +index e339f8da1b0a..e36ae4d4b540 100644 +--- a/net/sunrpc/sched.c ++++ b/net/sunrpc/sched.c +@@ -893,8 +893,10 @@ int rpc_malloc(struct rpc_task *task) + struct rpc_buffer *buf; + gfp_t gfp = GFP_NOIO | __GFP_NOWARN; + ++ if (RPC_IS_ASYNC(task)) ++ gfp = GFP_NOWAIT | __GFP_NOWARN; + if (RPC_IS_SWAPPER(task)) +- gfp = __GFP_MEMALLOC | GFP_NOWAIT | __GFP_NOWARN; ++ gfp |= __GFP_MEMALLOC; + + size += sizeof(struct rpc_buffer); + if (size <= RPC_BUFFER_MAXSIZE) +diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c +index fdd14908eacb..e87a79be7ef0 100644 +--- a/net/sunrpc/xprtrdma/transport.c ++++ b/net/sunrpc/xprtrdma/transport.c +@@ -665,8 +665,10 @@ xprt_rdma_allocate(struct rpc_task *task) + gfp_t flags; + + flags = RPCRDMA_DEF_GFP; ++ if (RPC_IS_ASYNC(task)) ++ flags = GFP_NOWAIT | __GFP_NOWARN; + if (RPC_IS_SWAPPER(task)) +- flags = __GFP_MEMALLOC | GFP_NOWAIT | __GFP_NOWARN; ++ flags |= __GFP_MEMALLOC; + + if (!rpcrdma_get_sendbuf(r_xprt, req, rqst->rq_callsize, flags)) + goto out_fail; +-- +2.35.1 + diff --git a/queue-4.19/ubifs-rectify-space-amount-budget-for-mkdir-tmpfile-.patch b/queue-4.19/ubifs-rectify-space-amount-budget-for-mkdir-tmpfile-.patch new file mode 100644 index 00000000000..08417528e80 --- /dev/null +++ b/queue-4.19/ubifs-rectify-space-amount-budget-for-mkdir-tmpfile-.patch @@ -0,0 +1,71 @@ +From 68bfce0872ddcd7f14c4ffd167f9b725d9fe6dca Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 27 Dec 2021 11:22:38 +0800 +Subject: ubifs: Rectify space amount budget for mkdir/tmpfile operations + +From: Zhihao Cheng + +[ Upstream commit a6dab6607d4681d227905d5198710b575dbdb519 ] + +UBIFS should make sure the flash has enough space to store dirty (Data +that is newer than disk) data (in memory), space budget is exactly +designed to do that. If space budget calculates less data than we need, +'make_reservation()' will do more work(return -ENOSPC if no free space +lelf, sometimes we can see "cannot reserve xxx bytes in jhead xxx, error +-28" in ubifs error messages) with ubifs inodes locked, which may effect +other syscalls. + +A simple way to decide how much space do we need when make a budget: +See how much space is needed by 'make_reservation()' in ubifs_jnl_xxx() +function according to corresponding operation. + +It's better to report ENOSPC in ubifs_budget_space(), as early as we can. + +Fixes: 474b93704f32163 ("ubifs: Implement O_TMPFILE") +Fixes: 1e51764a3c2ac05 ("UBIFS: add new flash file system") +Signed-off-by: Zhihao Cheng +Signed-off-by: Richard Weinberger +Signed-off-by: Sasha Levin +--- + fs/ubifs/dir.c | 12 ++++++++---- + 1 file changed, 8 insertions(+), 4 deletions(-) + +diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c +index 9e466eb30dcb..111905ddbfc2 100644 +--- a/fs/ubifs/dir.c ++++ b/fs/ubifs/dir.c +@@ -373,15 +373,18 @@ static int do_tmpfile(struct inode *dir, struct dentry *dentry, + { + struct inode *inode; + struct ubifs_info *c = dir->i_sb->s_fs_info; +- struct ubifs_budget_req req = { .new_ino = 1, .new_dent = 1}; ++ struct ubifs_budget_req req = { .new_ino = 1, .new_dent = 1, ++ .dirtied_ino = 1}; + struct ubifs_budget_req ino_req = { .dirtied_ino = 1 }; + struct ubifs_inode *ui, *dir_ui = ubifs_inode(dir); + int err, instantiated = 0; + struct fscrypt_name nm; + + /* +- * Budget request settings: new dirty inode, new direntry, +- * budget for dirtied inode will be released via writeback. ++ * Budget request settings: new inode, new direntry, changing the ++ * parent directory inode. ++ * Allocate budget separately for new dirtied inode, the budget will ++ * be released via writeback. + */ + + dbg_gen("dent '%pd', mode %#hx in dir ino %lu", +@@ -973,7 +976,8 @@ static int ubifs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode) + struct ubifs_inode *dir_ui = ubifs_inode(dir); + struct ubifs_info *c = dir->i_sb->s_fs_info; + int err, sz_change; +- struct ubifs_budget_req req = { .new_ino = 1, .new_dent = 1 }; ++ struct ubifs_budget_req req = { .new_ino = 1, .new_dent = 1, ++ .dirtied_ino = 1}; + struct fscrypt_name nm; + + /* +-- +2.35.1 + diff --git a/queue-4.19/usb-dwc3-omap-fix-unbalanced-disables-for-smps10_out.patch b/queue-4.19/usb-dwc3-omap-fix-unbalanced-disables-for-smps10_out.patch new file mode 100644 index 00000000000..9afe210bdd3 --- /dev/null +++ b/queue-4.19/usb-dwc3-omap-fix-unbalanced-disables-for-smps10_out.patch @@ -0,0 +1,75 @@ +From 9be9f41dcb103f7b4400e5abfbbec0213d295d9c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Mar 2022 14:03:37 +0100 +Subject: usb: dwc3: omap: fix "unbalanced disables for smps10_out1" on + omap5evm + +From: H. Nikolaus Schaller + +[ Upstream commit ac01df343e5a6c6bcead2ed421af1fde30f73e7e ] + +Usually, the vbus_regulator (smps10 on omap5evm) boots up disabled. + +Hence calling regulator_disable() indirectly through dwc3_omap_set_mailbox() +during probe leads to: + +[ 10.332764] WARNING: CPU: 0 PID: 1628 at drivers/regulator/core.c:2853 _regulator_disable+0x40/0x164 +[ 10.351919] unbalanced disables for smps10_out1 +[ 10.361298] Modules linked in: dwc3_omap(+) clk_twl6040 at24 gpio_twl6040 palmas_gpadc palmas_pwrbutton +industrialio snd_soc_omap_mcbsp(+) snd_soc_ti_sdma display_connector ti_tpd12s015 drm leds_gpio +drm_panel_orientation_quirks ip_tables x_tables ipv6 autofs4 +[ 10.387818] CPU: 0 PID: 1628 Comm: systemd-udevd Not tainted 5.17.0-rc1-letux-lpae+ #8139 +[ 10.405129] Hardware name: Generic OMAP5 (Flattened Device Tree) +[ 10.411455] unwind_backtrace from show_stack+0x10/0x14 +[ 10.416970] show_stack from dump_stack_lvl+0x40/0x4c +[ 10.422313] dump_stack_lvl from __warn+0xb8/0x170 +[ 10.427377] __warn from warn_slowpath_fmt+0x70/0x9c +[ 10.432595] warn_slowpath_fmt from _regulator_disable+0x40/0x164 +[ 10.439037] _regulator_disable from regulator_disable+0x30/0x64 +[ 10.445382] regulator_disable from dwc3_omap_set_mailbox+0x8c/0xf0 [dwc3_omap] +[ 10.453116] dwc3_omap_set_mailbox [dwc3_omap] from dwc3_omap_probe+0x2b8/0x394 [dwc3_omap] +[ 10.467021] dwc3_omap_probe [dwc3_omap] from platform_probe+0x58/0xa8 +[ 10.481762] platform_probe from really_probe+0x168/0x2fc +[ 10.481782] really_probe from __driver_probe_device+0xc4/0xd8 +[ 10.481782] __driver_probe_device from driver_probe_device+0x24/0xa4 +[ 10.503762] driver_probe_device from __driver_attach+0xc4/0xd8 +[ 10.510018] __driver_attach from bus_for_each_dev+0x64/0xa0 +[ 10.516001] bus_for_each_dev from bus_add_driver+0x148/0x1a4 +[ 10.524880] bus_add_driver from driver_register+0xb4/0xf8 +[ 10.530678] driver_register from do_one_initcall+0x90/0x1c4 +[ 10.536661] do_one_initcall from do_init_module+0x4c/0x200 +[ 10.536683] do_init_module from load_module+0x13dc/0x1910 +[ 10.551159] load_module from sys_finit_module+0xc8/0xd8 +[ 10.561319] sys_finit_module from __sys_trace_return+0x0/0x18 +[ 10.561336] Exception stack(0xc344bfa8 to 0xc344bff0) +[ 10.561341] bfa0: b6fb5778 b6fab8d8 00000007 b6ecfbb8 00000000 b6ed0398 +[ 10.561341] bfc0: b6fb5778 b6fab8d8 855c0500 0000017b 00020000 b6f9a3cc 00000000 b6fb5778 +[ 10.595500] bfe0: bede18f8 bede18e8 b6ec9aeb b6dda1c2 +[ 10.601345] ---[ end trace 0000000000000000 ]--- + +Fix this unnecessary warning by checking if the regulator is enabled. + +Signed-off-by: H. Nikolaus Schaller +Link: https://lore.kernel.org/r/af3b750dc2265d875deaabcf5f80098c9645da45.1646744616.git.hns@goldelico.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/usb/dwc3/dwc3-omap.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c +index 0dfb710f48b5..0b800bc6150d 100644 +--- a/drivers/usb/dwc3/dwc3-omap.c ++++ b/drivers/usb/dwc3/dwc3-omap.c +@@ -237,7 +237,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap, + break; + + case OMAP_DWC3_ID_FLOAT: +- if (omap->vbus_reg) ++ if (omap->vbus_reg && regulator_is_enabled(omap->vbus_reg)) + regulator_disable(omap->vbus_reg); + val = dwc3_omap_read_utmi_ctrl(omap); + val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG; +-- +2.35.1 + diff --git a/queue-4.19/usb-ehci-add-pci-device-support-for-aspeed-platforms.patch b/queue-4.19/usb-ehci-add-pci-device-support-for-aspeed-platforms.patch new file mode 100644 index 00000000000..b54628faddd --- /dev/null +++ b/queue-4.19/usb-ehci-add-pci-device-support-for-aspeed-platforms.patch @@ -0,0 +1,52 @@ +From dda0ea2b57c65c62732d05268963a193a41a9e94 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Feb 2022 18:16:57 +0800 +Subject: usb: ehci: add pci device support for Aspeed platforms + +From: Neal Liu + +[ Upstream commit c3c9cee592828528fd228b01d312c7526c584a42 ] + +Enable Aspeed quirks in commit 7f2d73788d90 ("usb: ehci: +handshake CMD_RUN instead of STS_HALT") to support Aspeed +ehci-pci device. + +Acked-by: Alan Stern +Signed-off-by: Neal Liu +Link: https://lore.kernel.org/r/20220208101657.76459-1-neal_liu@aspeedtech.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/usb/host/ehci-pci.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c +index 56e6fd0f0482..42ace9f92ce9 100644 +--- a/drivers/usb/host/ehci-pci.c ++++ b/drivers/usb/host/ehci-pci.c +@@ -21,6 +21,9 @@ static const char hcd_name[] = "ehci-pci"; + /* defined here to avoid adding to pci_ids.h for single instance use */ + #define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70 + ++#define PCI_VENDOR_ID_ASPEED 0x1a03 ++#define PCI_DEVICE_ID_ASPEED_EHCI 0x2603 ++ + /*-------------------------------------------------------------------------*/ + #define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC 0x0939 + static inline bool is_intel_quark_x1000(struct pci_dev *pdev) +@@ -223,6 +226,12 @@ static int ehci_pci_setup(struct usb_hcd *hcd) + ehci->has_synopsys_hc_bug = 1; + } + break; ++ case PCI_VENDOR_ID_ASPEED: ++ if (pdev->device == PCI_DEVICE_ID_ASPEED_EHCI) { ++ ehci_info(ehci, "applying Aspeed HC workaround\n"); ++ ehci->is_aspeed = 1; ++ } ++ break; + } + + /* optional debug port, normally in the first BAR */ +-- +2.35.1 + diff --git a/queue-4.19/virtio_console-eliminate-anonymous-module_init-modul.patch b/queue-4.19/virtio_console-eliminate-anonymous-module_init-modul.patch new file mode 100644 index 00000000000..96c385abfd9 --- /dev/null +++ b/queue-4.19/virtio_console-eliminate-anonymous-module_init-modul.patch @@ -0,0 +1,76 @@ +From c712405f022b473df1c4281072ff51b337070e28 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 16 Mar 2022 12:20:03 -0700 +Subject: virtio_console: eliminate anonymous module_init & module_exit + +From: Randy Dunlap + +[ Upstream commit fefb8a2a941338d871e2d83fbd65fbfa068857bd ] + +Eliminate anonymous module_init() and module_exit(), which can lead to +confusion or ambiguity when reading System.map, crashes/oops/bugs, +or an initcall_debug log. + +Give each of these init and exit functions unique driver-specific +names to eliminate the anonymous names. + +Example 1: (System.map) + ffffffff832fc78c t init + ffffffff832fc79e t init + ffffffff832fc8f8 t init + +Example 2: (initcall_debug log) + calling init+0x0/0x12 @ 1 + initcall init+0x0/0x12 returned 0 after 15 usecs + calling init+0x0/0x60 @ 1 + initcall init+0x0/0x60 returned 0 after 2 usecs + calling init+0x0/0x9a @ 1 + initcall init+0x0/0x9a returned 0 after 74 usecs + +Signed-off-by: Randy Dunlap +Reviewed-by: Amit Shah +Cc: virtualization@lists.linux-foundation.org +Cc: Arnd Bergmann +Link: https://lore.kernel.org/r/20220316192010.19001-3-rdunlap@infradead.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/char/virtio_console.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c +index ac0b84afabe7..d3937d690400 100644 +--- a/drivers/char/virtio_console.c ++++ b/drivers/char/virtio_console.c +@@ -2265,7 +2265,7 @@ static struct virtio_driver virtio_rproc_serial = { + .remove = virtcons_remove, + }; + +-static int __init init(void) ++static int __init virtio_console_init(void) + { + int err; + +@@ -2302,7 +2302,7 @@ static int __init init(void) + return err; + } + +-static void __exit fini(void) ++static void __exit virtio_console_fini(void) + { + reclaim_dma_bufs(); + +@@ -2312,8 +2312,8 @@ static void __exit fini(void) + class_destroy(pdrvdata.class); + debugfs_remove_recursive(pdrvdata.debugfs_dir); + } +-module_init(init); +-module_exit(fini); ++module_init(virtio_console_init); ++module_exit(virtio_console_fini); + + MODULE_DESCRIPTION("Virtio console driver"); + MODULE_LICENSE("GPL"); +-- +2.35.1 + diff --git a/queue-4.19/w1-w1_therm-fixes-w1_seq-for-ds28ea00-sensors.patch b/queue-4.19/w1-w1_therm-fixes-w1_seq-for-ds28ea00-sensors.patch new file mode 100644 index 00000000000..daade6bd114 --- /dev/null +++ b/queue-4.19/w1-w1_therm-fixes-w1_seq-for-ds28ea00-sensors.patch @@ -0,0 +1,52 @@ +From 137553d0526b043c9310be7ce0619d5a2dede876 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 23 Feb 2022 11:35:55 +0000 +Subject: w1: w1_therm: fixes w1_seq for ds28ea00 sensors + +From: Lucas Denefle + +[ Upstream commit 41a92a89eee819298f805c40187ad8b02bb53426 ] + +w1_seq was failing due to several devices responding to the +CHAIN_DONE at the same time. Now properly selects the current +device in the chain with MATCH_ROM. Also acknowledgment was +read twice. + +Signed-off-by: Lucas Denefle +Link: https://lore.kernel.org/r/20220223113558.232750-1-lucas.denefle@converge.io +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/w1/slaves/w1_therm.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c +index 3c350dfbcd0b..aba727294bc8 100644 +--- a/drivers/w1/slaves/w1_therm.c ++++ b/drivers/w1/slaves/w1_therm.c +@@ -693,16 +693,20 @@ static ssize_t w1_seq_show(struct device *device, + if (sl->reg_num.id == reg_num->id) + seq = i; + ++ if (w1_reset_bus(sl->master)) ++ goto error; ++ ++ /* Put the device into chain DONE state */ ++ w1_write_8(sl->master, W1_MATCH_ROM); ++ w1_write_block(sl->master, (u8 *)&rn, 8); + w1_write_8(sl->master, W1_42_CHAIN); + w1_write_8(sl->master, W1_42_CHAIN_DONE); + w1_write_8(sl->master, W1_42_CHAIN_DONE_INV); +- w1_read_block(sl->master, &ack, sizeof(ack)); + + /* check for acknowledgment */ + ack = w1_read_8(sl->master); + if (ack != W1_42_SUCCESS_CONFIRM_BYTE) + goto error; +- + } + + /* Exit from CHAIN state */ +-- +2.35.1 + diff --git a/queue-4.19/xen-delay-xen_hvm_init_time_ops-if-kdump-is-boot-on-.patch b/queue-4.19/xen-delay-xen_hvm_init_time_ops-if-kdump-is-boot-on-.patch new file mode 100644 index 00000000000..e4ba0cd4b47 --- /dev/null +++ b/queue-4.19/xen-delay-xen_hvm_init_time_ops-if-kdump-is-boot-on-.patch @@ -0,0 +1,123 @@ +From e4c4232f53045c0c0d6b331746c2fe4cbfd22a08 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 2 Mar 2022 08:40:32 -0800 +Subject: xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32 + +From: Dongli Zhang + +[ Upstream commit eed05744322da07dd7e419432dcedf3c2e017179 ] + +The sched_clock() can be used very early since commit 857baa87b642 +("sched/clock: Enable sched clock early"). In addition, with commit +38669ba205d1 ("x86/xen/time: Output xen sched_clock time from 0"), kdump +kernel in Xen HVM guest may panic at very early stage when accessing +&__this_cpu_read(xen_vcpu)->time as in below: + +setup_arch() + -> init_hypervisor_platform() + -> x86_init.hyper.init_platform = xen_hvm_guest_init() + -> xen_hvm_init_time_ops() + -> xen_clocksource_read() + -> src = &__this_cpu_read(xen_vcpu)->time; + +This is because Xen HVM supports at most MAX_VIRT_CPUS=32 'vcpu_info' +embedded inside 'shared_info' during early stage until xen_vcpu_setup() is +used to allocate/relocate 'vcpu_info' for boot cpu at arbitrary address. + +However, when Xen HVM guest panic on vcpu >= 32, since +xen_vcpu_info_reset(0) would set per_cpu(xen_vcpu, cpu) = NULL when +vcpu >= 32, xen_clocksource_read() on vcpu >= 32 would panic. + +This patch calls xen_hvm_init_time_ops() again later in +xen_hvm_smp_prepare_boot_cpu() after the 'vcpu_info' for boot vcpu is +registered when the boot vcpu is >= 32. + +This issue can be reproduced on purpose via below command at the guest +side when kdump/kexec is enabled: + +"taskset -c 33 echo c > /proc/sysrq-trigger" + +The bugfix for PVM is not implemented due to the lack of testing +environment. + +[boris: xen_hvm_init_time_ops() returns on errors instead of jumping to end] + +Cc: Joe Jin +Signed-off-by: Dongli Zhang +Reviewed-by: Boris Ostrovsky +Link: https://lore.kernel.org/r/20220302164032.14569-3-dongli.zhang@oracle.com +Signed-off-by: Boris Ostrovsky +Signed-off-by: Sasha Levin +--- + arch/x86/xen/smp_hvm.c | 6 ++++++ + arch/x86/xen/time.c | 24 +++++++++++++++++++++++- + 2 files changed, 29 insertions(+), 1 deletion(-) + +diff --git a/arch/x86/xen/smp_hvm.c b/arch/x86/xen/smp_hvm.c +index f8d39440b292..e5bd9eb42191 100644 +--- a/arch/x86/xen/smp_hvm.c ++++ b/arch/x86/xen/smp_hvm.c +@@ -18,6 +18,12 @@ static void __init xen_hvm_smp_prepare_boot_cpu(void) + */ + xen_vcpu_setup(0); + ++ /* ++ * Called again in case the kernel boots on vcpu >= MAX_VIRT_CPUS. ++ * Refer to comments in xen_hvm_init_time_ops(). ++ */ ++ xen_hvm_init_time_ops(); ++ + /* + * The alternative logic (which patches the unlock/lock) runs before + * the smp bootup up code is activated. Hence we need to set this up +diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c +index 01dcccf9185f..9809de9f2310 100644 +--- a/arch/x86/xen/time.c ++++ b/arch/x86/xen/time.c +@@ -547,6 +547,11 @@ static void xen_hvm_setup_cpu_clockevents(void) + + void __init xen_hvm_init_time_ops(void) + { ++ static bool hvm_time_initialized; ++ ++ if (hvm_time_initialized) ++ return; ++ + /* + * vector callback is needed otherwise we cannot receive interrupts + * on cpu > 0 and at this point we don't know how many cpus are +@@ -556,7 +561,22 @@ void __init xen_hvm_init_time_ops(void) + return; + + if (!xen_feature(XENFEAT_hvm_safe_pvclock)) { +- pr_info("Xen doesn't support pvclock on HVM, disable pv timer"); ++ pr_info_once("Xen doesn't support pvclock on HVM, disable pv timer"); ++ return; ++ } ++ ++ /* ++ * Only MAX_VIRT_CPUS 'vcpu_info' are embedded inside 'shared_info'. ++ * The __this_cpu_read(xen_vcpu) is still NULL when Xen HVM guest ++ * boots on vcpu >= MAX_VIRT_CPUS (e.g., kexec), To access ++ * __this_cpu_read(xen_vcpu) via xen_clocksource_read() will panic. ++ * ++ * The xen_hvm_init_time_ops() should be called again later after ++ * __this_cpu_read(xen_vcpu) is available. ++ */ ++ if (!__this_cpu_read(xen_vcpu)) { ++ pr_info("Delay xen_init_time_common() as kernel is running on vcpu=%d\n", ++ xen_vcpu_nr(0)); + return; + } + +@@ -568,5 +588,7 @@ void __init xen_hvm_init_time_ops(void) + x86_platform.calibrate_tsc = xen_tsc_khz; + x86_platform.get_wallclock = xen_get_wallclock; + x86_platform.set_wallclock = xen_set_wallclock; ++ ++ hvm_time_initialized = true; + } + #endif +-- +2.35.1 + diff --git a/queue-4.19/xtensa-fix-dtc-warning-unit_address_format.patch b/queue-4.19/xtensa-fix-dtc-warning-unit_address_format.patch new file mode 100644 index 00000000000..44aee889b9f --- /dev/null +++ b/queue-4.19/xtensa-fix-dtc-warning-unit_address_format.patch @@ -0,0 +1,103 @@ +From 604b7f3246c9c52112d5715228d036ba386f3bf3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 17 Mar 2022 02:49:41 -0700 +Subject: xtensa: fix DTC warning unit_address_format + +From: Max Filippov + +[ Upstream commit e85d29ba4b24f68e7a78cb85c55e754362eeb2de ] + +DTC issues the following warnings when building xtfpga device trees: + + /soc/flash@00000000/partition@0x0: unit name should not have leading "0x" + /soc/flash@00000000/partition@0x6000000: unit name should not have leading "0x" + /soc/flash@00000000/partition@0x6800000: unit name should not have leading "0x" + /soc/flash@00000000/partition@0x7fe0000: unit name should not have leading "0x" + +Drop leading 0x from flash partition unit names. + +Signed-off-by: Max Filippov +Signed-off-by: Sasha Levin +--- + arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi | 8 ++++---- + arch/xtensa/boot/dts/xtfpga-flash-16m.dtsi | 8 ++++---- + arch/xtensa/boot/dts/xtfpga-flash-4m.dtsi | 4 ++-- + 3 files changed, 10 insertions(+), 10 deletions(-) + +diff --git a/arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi b/arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi +index 9bf8bad1dd18..c33932568aa7 100644 +--- a/arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi ++++ b/arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi +@@ -8,19 +8,19 @@ + reg = <0x00000000 0x08000000>; + bank-width = <2>; + device-width = <2>; +- partition@0x0 { ++ partition@0 { + label = "data"; + reg = <0x00000000 0x06000000>; + }; +- partition@0x6000000 { ++ partition@6000000 { + label = "boot loader area"; + reg = <0x06000000 0x00800000>; + }; +- partition@0x6800000 { ++ partition@6800000 { + label = "kernel image"; + reg = <0x06800000 0x017e0000>; + }; +- partition@0x7fe0000 { ++ partition@7fe0000 { + label = "boot environment"; + reg = <0x07fe0000 0x00020000>; + }; +diff --git a/arch/xtensa/boot/dts/xtfpga-flash-16m.dtsi b/arch/xtensa/boot/dts/xtfpga-flash-16m.dtsi +index 40c2f81f7cb6..7bde2ab2d6fb 100644 +--- a/arch/xtensa/boot/dts/xtfpga-flash-16m.dtsi ++++ b/arch/xtensa/boot/dts/xtfpga-flash-16m.dtsi +@@ -8,19 +8,19 @@ + reg = <0x08000000 0x01000000>; + bank-width = <2>; + device-width = <2>; +- partition@0x0 { ++ partition@0 { + label = "boot loader area"; + reg = <0x00000000 0x00400000>; + }; +- partition@0x400000 { ++ partition@400000 { + label = "kernel image"; + reg = <0x00400000 0x00600000>; + }; +- partition@0xa00000 { ++ partition@a00000 { + label = "data"; + reg = <0x00a00000 0x005e0000>; + }; +- partition@0xfe0000 { ++ partition@fe0000 { + label = "boot environment"; + reg = <0x00fe0000 0x00020000>; + }; +diff --git a/arch/xtensa/boot/dts/xtfpga-flash-4m.dtsi b/arch/xtensa/boot/dts/xtfpga-flash-4m.dtsi +index fb8d3a9f33c2..0655b868749a 100644 +--- a/arch/xtensa/boot/dts/xtfpga-flash-4m.dtsi ++++ b/arch/xtensa/boot/dts/xtfpga-flash-4m.dtsi +@@ -8,11 +8,11 @@ + reg = <0x08000000 0x00400000>; + bank-width = <2>; + device-width = <2>; +- partition@0x0 { ++ partition@0 { + label = "boot loader area"; + reg = <0x00000000 0x003f0000>; + }; +- partition@0x3f0000 { ++ partition@3f0000 { + label = "boot environment"; + reg = <0x003f0000 0x00010000>; + }; +-- +2.35.1 +