From 2f3bb3645afcfbbde80294daf014e15dff05b23b Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Fri, 23 Feb 2024 12:44:27 -0500 Subject: [PATCH] Fixes for 4.19 Signed-off-by: Sasha Levin --- ...1166-correct-count-of-reported-ports.patch | 52 +++++++ ...engine-shdma-increase-size-of-dev_id.patch | 53 +++++++ ...ating-blocks-from-corrupted-group-in.patch | 65 +++++++++ ...-blocks-from-corrupted-group-in.patch-4129 | 54 ++++++++ ...ge-error-out-if-pixclock-equals-zero.patch | 45 ++++++ ...is-error-out-if-pixclock-equals-zero.patch | 43 ++++++ ...nd-bus-reset-promptly-on-gap-count-e.patch | 129 ++++++++++++++++++ ...enlarge-per-package-core-count-limit.patch | 43 ++++++ ...gulator-add-validity-checks-in-conti.patch | 43 ++++++ ...et-core-add-tmf-to-tmr_list-handling.patch | 88 ++++++++++++ queue-4.19/series | 13 ++ ...e-no-requests-in-virtqueues-before-d.patch | 64 +++++++++ ...-fix-missing-interfaces-when-dumping.patch | 71 ++++++++++ ...x-race-condition-on-enabling-fast-xm.patch | 53 +++++++ 14 files changed, 816 insertions(+) create mode 100644 queue-4.19/ahci-asm1166-correct-count-of-reported-ports.patch create mode 100644 queue-4.19/dmaengine-shdma-increase-size-of-dev_id.patch create mode 100644 queue-4.19/ext4-avoid-allocating-blocks-from-corrupted-group-in.patch create mode 100644 queue-4.19/ext4-avoid-allocating-blocks-from-corrupted-group-in.patch-4129 create mode 100644 queue-4.19/fbdev-savage-error-out-if-pixclock-equals-zero.patch create mode 100644 queue-4.19/fbdev-sis-error-out-if-pixclock-equals-zero.patch create mode 100644 queue-4.19/firewire-core-send-bus-reset-promptly-on-gap-count-e.patch create mode 100644 queue-4.19/hwmon-coretemp-enlarge-per-package-core-count-limit.patch create mode 100644 queue-4.19/regulator-pwm-regulator-add-validity-checks-in-conti.patch create mode 100644 queue-4.19/scsi-target-core-add-tmf-to-tmr_list-handling.patch create mode 100644 queue-4.19/virtio-blk-ensure-no-requests-in-virtqueues-before-d.patch create mode 100644 queue-4.19/wifi-cfg80211-fix-missing-interfaces-when-dumping.patch create mode 100644 queue-4.19/wifi-mac80211-fix-race-condition-on-enabling-fast-xm.patch diff --git a/queue-4.19/ahci-asm1166-correct-count-of-reported-ports.patch b/queue-4.19/ahci-asm1166-correct-count-of-reported-ports.patch new file mode 100644 index 00000000000..53d74672f16 --- /dev/null +++ b/queue-4.19/ahci-asm1166-correct-count-of-reported-ports.patch @@ -0,0 +1,52 @@ +From 54723aa30809ffc61353dc784e6ac42a26ffb2a6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 23 Jan 2024 19:30:02 +0100 +Subject: ahci: asm1166: correct count of reported ports + +From: Conrad Kostecki + +[ Upstream commit 0077a504e1a4468669fd2e011108db49133db56e ] + +The ASM1166 SATA host controller always reports wrongly, +that it has 32 ports. But in reality, it only has six ports. + +This seems to be a hardware issue, as all tested ASM1166 +SATA host controllers reports such high count of ports. + +Example output: ahci 0000:09:00.0: AHCI 0001.0301 +32 slots 32 ports 6 Gbps 0xffffff3f impl SATA mode. + +By adjusting the port_map, the count is limited to six ports. + +New output: ahci 0000:09:00.0: AHCI 0001.0301 +32 slots 32 ports 6 Gbps 0x3f impl SATA mode. + +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=211873 +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218346 +Signed-off-by: Conrad Kostecki +Reviewed-by: Hans de Goede +Signed-off-by: Niklas Cassel +Signed-off-by: Sasha Levin +--- + drivers/ata/ahci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c +index ab3ea47ecce3a..abdfd440987b4 100644 +--- a/drivers/ata/ahci.c ++++ b/drivers/ata/ahci.c +@@ -634,6 +634,11 @@ MODULE_PARM_DESC(mobile_lpm_policy, "Default LPM policy for mobile chipsets"); + static void ahci_pci_save_initial_config(struct pci_dev *pdev, + struct ahci_host_priv *hpriv) + { ++ if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA && pdev->device == 0x1166) { ++ dev_info(&pdev->dev, "ASM1166 has only six ports\n"); ++ hpriv->saved_port_map = 0x3f; ++ } ++ + if (pdev->vendor == PCI_VENDOR_ID_JMICRON && pdev->device == 0x2361) { + dev_info(&pdev->dev, "JMB361 has only one port\n"); + hpriv->force_port_map = 1; +-- +2.43.0 + diff --git a/queue-4.19/dmaengine-shdma-increase-size-of-dev_id.patch b/queue-4.19/dmaengine-shdma-increase-size-of-dev_id.patch new file mode 100644 index 00000000000..2645a453ab4 --- /dev/null +++ b/queue-4.19/dmaengine-shdma-increase-size-of-dev_id.patch @@ -0,0 +1,53 @@ +From 809c3f417cffc97eaeac946d8a939201b805470b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 19 Jan 2024 18:10:44 +0530 +Subject: dmaengine: shdma: increase size of 'dev_id' +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Vinod Koul + +[ Upstream commit 404290240827c3bb5c4e195174a8854eef2f89ac ] + +We seem to have hit warnings of 'output may be truncated' which is fixed +by increasing the size of 'dev_id' + +drivers/dma/sh/shdmac.c: In function ‘sh_dmae_probe’: +drivers/dma/sh/shdmac.c:541:34: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 9 [-Werror=format-truncation=] + 541 | "sh-dmae%d.%d", pdev->id, id); + | ^~ +In function ‘sh_dmae_chan_probe’, + inlined from ‘sh_dmae_probe’ at drivers/dma/sh/shdmac.c:845:9: +drivers/dma/sh/shdmac.c:541:26: note: directive argument in the range [0, 2147483647] + 541 | "sh-dmae%d.%d", pdev->id, id); + | ^~~~~~~~~~~~~~ +drivers/dma/sh/shdmac.c:541:26: note: directive argument in the range [0, 19] +drivers/dma/sh/shdmac.c:540:17: note: ‘snprintf’ output between 11 and 21 bytes into a destination of size 16 + 540 | snprintf(sh_chan->dev_id, sizeof(sh_chan->dev_id), + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 541 | "sh-dmae%d.%d", pdev->id, id); + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Signed-off-by: Vinod Koul +Signed-off-by: Sasha Levin +--- + drivers/dma/sh/shdma.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/dma/sh/shdma.h b/drivers/dma/sh/shdma.h +index 2c0a969adc9fb..35987a35a8480 100644 +--- a/drivers/dma/sh/shdma.h ++++ b/drivers/dma/sh/shdma.h +@@ -29,7 +29,7 @@ struct sh_dmae_chan { + const struct sh_dmae_slave_config *config; /* Slave DMA configuration */ + int xmit_shift; /* log_2(bytes_per_xfer) */ + void __iomem *base; +- char dev_id[16]; /* unique name per DMAC of channel */ ++ char dev_id[32]; /* unique name per DMAC of channel */ + int pm_error; + dma_addr_t slave_addr; + }; +-- +2.43.0 + diff --git a/queue-4.19/ext4-avoid-allocating-blocks-from-corrupted-group-in.patch b/queue-4.19/ext4-avoid-allocating-blocks-from-corrupted-group-in.patch new file mode 100644 index 00000000000..954c7ea6334 --- /dev/null +++ b/queue-4.19/ext4-avoid-allocating-blocks-from-corrupted-group-in.patch @@ -0,0 +1,65 @@ +From e8d535b84ddc853a99aea6ef837cd32f966e4f5c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 4 Jan 2024 22:20:38 +0800 +Subject: ext4: avoid allocating blocks from corrupted group in + ext4_mb_try_best_found() + +From: Baokun Li + +[ Upstream commit 4530b3660d396a646aad91a787b6ab37cf604b53 ] + +Determine if the group block bitmap is corrupted before using ac_b_ex in +ext4_mb_try_best_found() to avoid allocating blocks from a group with a +corrupted block bitmap in the following concurrency and making the +situation worse. + +ext4_mb_regular_allocator + ext4_lock_group(sb, group) + ext4_mb_good_group + // check if the group bbitmap is corrupted + ext4_mb_complex_scan_group + // Scan group gets ac_b_ex but doesn't use it + ext4_unlock_group(sb, group) + ext4_mark_group_bitmap_corrupted(group) + // The block bitmap was corrupted during + // the group unlock gap. + ext4_mb_try_best_found + ext4_lock_group(ac->ac_sb, group) + ext4_mb_use_best_found + mb_mark_used + // Allocating blocks in block bitmap corrupted group + +Signed-off-by: Baokun Li +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20240104142040.2835097-7-libaokun1@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + fs/ext4/mballoc.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c +index df390979058fd..e0dd01cb1a0e7 100644 +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -1802,6 +1802,9 @@ int ext4_mb_try_best_found(struct ext4_allocation_context *ac, + return err; + + ext4_lock_group(ac->ac_sb, group); ++ if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) ++ goto out; ++ + max = mb_find_extent(e4b, ex.fe_start, ex.fe_len, &ex); + + if (max > 0) { +@@ -1809,6 +1812,7 @@ int ext4_mb_try_best_found(struct ext4_allocation_context *ac, + ext4_mb_use_best_found(ac, e4b); + } + ++out: + ext4_unlock_group(ac->ac_sb, group); + ext4_mb_unload_buddy(e4b); + +-- +2.43.0 + diff --git a/queue-4.19/ext4-avoid-allocating-blocks-from-corrupted-group-in.patch-4129 b/queue-4.19/ext4-avoid-allocating-blocks-from-corrupted-group-in.patch-4129 new file mode 100644 index 00000000000..54485f24e67 --- /dev/null +++ b/queue-4.19/ext4-avoid-allocating-blocks-from-corrupted-group-in.patch-4129 @@ -0,0 +1,54 @@ +From 18da577e654e8cfb5af7a1cfba4ac63680474132 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 4 Jan 2024 22:20:39 +0800 +Subject: ext4: avoid allocating blocks from corrupted group in + ext4_mb_find_by_goal() + +From: Baokun Li + +[ Upstream commit 832698373a25950942c04a512daa652c18a9b513 ] + +Places the logic for checking if the group's block bitmap is corrupt under +the protection of the group lock to avoid allocating blocks from the group +with a corrupted block bitmap. + +Signed-off-by: Baokun Li +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20240104142040.2835097-8-libaokun1@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + fs/ext4/mballoc.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c +index e0dd01cb1a0e7..5af5ad53e0ada 100644 +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -1839,12 +1839,10 @@ int ext4_mb_find_by_goal(struct ext4_allocation_context *ac, + if (err) + return err; + +- if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) { +- ext4_mb_unload_buddy(e4b); +- return 0; +- } +- + ext4_lock_group(ac->ac_sb, group); ++ if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) ++ goto out; ++ + max = mb_find_extent(e4b, ac->ac_g_ex.fe_start, + ac->ac_g_ex.fe_len, &ex); + ex.fe_logical = 0xDEADFA11; /* debug value */ +@@ -1877,6 +1875,7 @@ int ext4_mb_find_by_goal(struct ext4_allocation_context *ac, + ac->ac_b_ex = ex; + ext4_mb_use_best_found(ac, e4b); + } ++out: + ext4_unlock_group(ac->ac_sb, group); + ext4_mb_unload_buddy(e4b); + +-- +2.43.0 + diff --git a/queue-4.19/fbdev-savage-error-out-if-pixclock-equals-zero.patch b/queue-4.19/fbdev-savage-error-out-if-pixclock-equals-zero.patch new file mode 100644 index 00000000000..a26aa360c3d --- /dev/null +++ b/queue-4.19/fbdev-savage-error-out-if-pixclock-equals-zero.patch @@ -0,0 +1,45 @@ +From f0b2833f25fcc5a45c0e68aa3f499a96ce198d60 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Jan 2024 11:49:40 +0800 +Subject: fbdev: savage: Error out if pixclock equals zero + +From: Fullway Wang + +[ Upstream commit 04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288 ] + +The userspace program could pass any values to the driver through +ioctl() interface. If the driver doesn't check the value of pixclock, +it may cause divide-by-zero error. + +Although pixclock is checked in savagefb_decode_var(), but it is not +checked properly in savagefb_probe(). Fix this by checking whether +pixclock is zero in the function savagefb_check_var() before +info->var.pixclock is used as the divisor. + +This is similar to CVE-2022-3061 in i740fb which was fixed by +commit 15cf0b8. + +Signed-off-by: Fullway Wang +Signed-off-by: Helge Deller +Signed-off-by: Sasha Levin +--- + drivers/video/fbdev/savage/savagefb_driver.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/video/fbdev/savage/savagefb_driver.c b/drivers/video/fbdev/savage/savagefb_driver.c +index c09d7426cd925..d9eafdb89ceaf 100644 +--- a/drivers/video/fbdev/savage/savagefb_driver.c ++++ b/drivers/video/fbdev/savage/savagefb_driver.c +@@ -869,6 +869,9 @@ static int savagefb_check_var(struct fb_var_screeninfo *var, + + DBG("savagefb_check_var"); + ++ if (!var->pixclock) ++ return -EINVAL; ++ + var->transp.offset = 0; + var->transp.length = 0; + switch (var->bits_per_pixel) { +-- +2.43.0 + diff --git a/queue-4.19/fbdev-sis-error-out-if-pixclock-equals-zero.patch b/queue-4.19/fbdev-sis-error-out-if-pixclock-equals-zero.patch new file mode 100644 index 00000000000..6d5a996ac36 --- /dev/null +++ b/queue-4.19/fbdev-sis-error-out-if-pixclock-equals-zero.patch @@ -0,0 +1,43 @@ +From 3d576383a5d1ab74eaa5984b774fbf341d462b8e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Jan 2024 14:24:43 +0800 +Subject: fbdev: sis: Error out if pixclock equals zero + +From: Fullway Wang + +[ Upstream commit e421946be7d9bf545147bea8419ef8239cb7ca52 ] + +The userspace program could pass any values to the driver through +ioctl() interface. If the driver doesn't check the value of pixclock, +it may cause divide-by-zero error. + +In sisfb_check_var(), var->pixclock is used as a divisor to caculate +drate before it is checked against zero. Fix this by checking it +at the beginning. + +This is similar to CVE-2022-3061 in i740fb which was fixed by +commit 15cf0b8. + +Signed-off-by: Fullway Wang +Signed-off-by: Helge Deller +Signed-off-by: Sasha Levin +--- + drivers/video/fbdev/sis/sis_main.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/video/fbdev/sis/sis_main.c b/drivers/video/fbdev/sis/sis_main.c +index 20aff90059781..b7f9da690db27 100644 +--- a/drivers/video/fbdev/sis/sis_main.c ++++ b/drivers/video/fbdev/sis/sis_main.c +@@ -1488,6 +1488,8 @@ sisfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info) + + vtotal = var->upper_margin + var->lower_margin + var->vsync_len; + ++ if (!var->pixclock) ++ return -EINVAL; + pixclock = var->pixclock; + + if((var->vmode & FB_VMODE_MASK) == FB_VMODE_NONINTERLACED) { +-- +2.43.0 + diff --git a/queue-4.19/firewire-core-send-bus-reset-promptly-on-gap-count-e.patch b/queue-4.19/firewire-core-send-bus-reset-promptly-on-gap-count-e.patch new file mode 100644 index 00000000000..876074d32ab --- /dev/null +++ b/queue-4.19/firewire-core-send-bus-reset-promptly-on-gap-count-e.patch @@ -0,0 +1,129 @@ +From a865b94229818a953b486070702ac8127341b076 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 7 Feb 2024 08:01:17 +0900 +Subject: firewire: core: send bus reset promptly on gap count error + +From: Takashi Sakamoto + +[ Upstream commit 7ed4380009e96d9e9c605e12822e987b35b05648 ] + +If we are bus manager and the bus has inconsistent gap counts, send a +bus reset immediately instead of trying to read the root node's config +ROM first. Otherwise, we could spend a lot of time trying to read the +config ROM but never succeeding. + +This eliminates a 50+ second delay before the FireWire bus is usable after +a newly connected device is powered on in certain circumstances. + +The delay occurs if a gap count inconsistency occurs, we are not the root +node, and we become bus manager. One scenario that causes this is with a TI +XIO2213B OHCI, the first time a Sony DSR-25 is powered on after being +connected to the FireWire cable. In this configuration, the Linux box will +not receive the initial PHY configuration packet sent by the DSR-25 as IRM, +resulting in the DSR-25 having a gap count of 44 while the Linux box has a +gap count of 63. + +FireWire devices have a gap count parameter, which is set to 63 on power-up +and can be changed with a PHY configuration packet. This determines the +duration of the subaction and arbitration gaps. For reliable communication, +all nodes on a FireWire bus must have the same gap count. + +A node may have zero or more of the following roles: root node, bus manager +(BM), isochronous resource manager (IRM), and cycle master. Unless a root +node was forced with a PHY configuration packet, any node might become root +node after a bus reset. Only the root node can become cycle master. If the +root node is not cycle master capable, the BM or IRM should force a change +of root node. + +After a bus reset, each node sends a self-ID packet, which contains its +current gap count. A single bus reset does not change the gap count, but +two bus resets in a row will set the gap count to 63. Because a consistent +gap count is required for reliable communication, IEEE 1394a-2000 requires +that the bus manager generate a bus reset if it detects that the gap count +is inconsistent. + +When the gap count is inconsistent, build_tree() will notice this after the +self identification process. It will set card->gap_count to the invalid +value 0. If we become bus master, this will force bm_work() to send a bus +reset when it performs gap count optimization. + +After a bus reset, there is no bus manager. We will almost always try to +become bus manager. Once we become bus manager, we will first determine +whether the root node is cycle master capable. Then, we will determine if +the gap count should be changed. If either the root node or the gap count +should be changed, we will generate a bus reset. + +To determine if the root node is cycle master capable, we read its +configuration ROM. bm_work() will wait until we have finished trying to +read the configuration ROM. + +However, an inconsistent gap count can make this take a long time. +read_config_rom() will read the first few quadlets from the config ROM. Due +to the gap count inconsistency, eventually one of the reads will time out. +When read_config_rom() fails, fw_device_init() calls it again until +MAX_RETRIES is reached. This takes 50+ seconds. + +Once we give up trying to read the configuration ROM, bm_work() will wake +up, assume that the root node is not cycle master capable, and do a bus +reset. Hopefully, this will resolve the gap count inconsistency. + +This change makes bm_work() check for an inconsistent gap count before +waiting for the root node's configuration ROM. If the gap count is +inconsistent, bm_work() will immediately do a bus reset. This eliminates +the 50+ second delay and rapidly brings the bus to a working state. + +I considered that if the gap count is inconsistent, a PHY configuration +packet might not be successful, so it could be desirable to skip the PHY +configuration packet before the bus reset in this case. However, IEEE +1394a-2000 and IEEE 1394-2008 say that the bus manager may transmit a PHY +configuration packet before a bus reset when correcting a gap count error. +Since the standard endorses this, I decided it's safe to retain the PHY +configuration packet transmission. + +Normally, after a topology change, we will reset the bus a maximum of 5 +times to change the root node and perform gap count optimization. However, +if there is a gap count inconsistency, we must always generate a bus reset. +Otherwise the gap count inconsistency will persist and communication will +be unreliable. For that reason, if there is a gap count inconstency, we +generate a bus reset even if we already reached the 5 reset limit. + +Signed-off-by: Adam Goldman +Reference: https://sourceforge.net/p/linux1394/mailman/message/58727806/ +Signed-off-by: Takashi Sakamoto +Signed-off-by: Sasha Levin +--- + drivers/firewire/core-card.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +diff --git a/drivers/firewire/core-card.c b/drivers/firewire/core-card.c +index 11c634125c7df..0e6f96c0e3957 100644 +--- a/drivers/firewire/core-card.c ++++ b/drivers/firewire/core-card.c +@@ -442,7 +442,23 @@ static void bm_work(struct work_struct *work) + */ + card->bm_generation = generation; + +- if (root_device == NULL) { ++ if (card->gap_count == 0) { ++ /* ++ * If self IDs have inconsistent gap counts, do a ++ * bus reset ASAP. The config rom read might never ++ * complete, so don't wait for it. However, still ++ * send a PHY configuration packet prior to the ++ * bus reset. The PHY configuration packet might ++ * fail, but 1394-2008 8.4.5.2 explicitly permits ++ * it in this case, so it should be safe to try. ++ */ ++ new_root_id = local_id; ++ /* ++ * We must always send a bus reset if the gap count ++ * is inconsistent, so bypass the 5-reset limit. ++ */ ++ card->bm_retries = 0; ++ } else if (root_device == NULL) { + /* + * Either link_on is false, or we failed to read the + * config rom. In either case, pick another root. +-- +2.43.0 + diff --git a/queue-4.19/hwmon-coretemp-enlarge-per-package-core-count-limit.patch b/queue-4.19/hwmon-coretemp-enlarge-per-package-core-count-limit.patch new file mode 100644 index 00000000000..8cd94f3747a --- /dev/null +++ b/queue-4.19/hwmon-coretemp-enlarge-per-package-core-count-limit.patch @@ -0,0 +1,43 @@ +From 39a17007ee293d054ef6c9a513a11b91ee42d294 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 2 Feb 2024 17:21:36 +0800 +Subject: hwmon: (coretemp) Enlarge per package core count limit + +From: Zhang Rui + +[ Upstream commit 34cf8c657cf0365791cdc658ddbca9cc907726ce ] + +Currently, coretemp driver supports only 128 cores per package. +This loses some core temperature information on systems that have more +than 128 cores per package. + [ 58.685033] coretemp coretemp.0: Adding Core 128 failed + [ 58.692009] coretemp coretemp.0: Adding Core 129 failed + ... + +Enlarge the limitation to 512 because there are platforms with more than +256 cores per package. + +Signed-off-by: Zhang Rui +Link: https://lore.kernel.org/r/20240202092144.71180-4-rui.zhang@intel.com +Signed-off-by: Guenter Roeck +Signed-off-by: Sasha Levin +--- + drivers/hwmon/coretemp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c +index d06e884775885..01c6518fe5654 100644 +--- a/drivers/hwmon/coretemp.c ++++ b/drivers/hwmon/coretemp.c +@@ -53,7 +53,7 @@ MODULE_PARM_DESC(tjmax, "TjMax value in degrees Celsius"); + + #define PKG_SYSFS_ATTR_NO 1 /* Sysfs attribute for package temp */ + #define BASE_SYSFS_ATTR_NO 2 /* Sysfs Base attr no for coretemp */ +-#define NUM_REAL_CORES 128 /* Number of Real cores per cpu */ ++#define NUM_REAL_CORES 512 /* Number of Real cores per cpu */ + #define CORETEMP_NAME_LENGTH 28 /* String Length of attrs */ + #define MAX_CORE_ATTRS 4 /* Maximum no of basic attrs */ + #define TOTAL_ATTRS (MAX_CORE_ATTRS + 1) +-- +2.43.0 + diff --git a/queue-4.19/regulator-pwm-regulator-add-validity-checks-in-conti.patch b/queue-4.19/regulator-pwm-regulator-add-validity-checks-in-conti.patch new file mode 100644 index 00000000000..07edb7a346c --- /dev/null +++ b/queue-4.19/regulator-pwm-regulator-add-validity-checks-in-conti.patch @@ -0,0 +1,43 @@ +From a212098af32f82d4609f3966e63811e4b6702ed2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 13 Jan 2024 23:46:26 +0100 +Subject: regulator: pwm-regulator: Add validity checks in continuous + .get_voltage +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Martin Blumenstingl + +[ Upstream commit c92688cac239794e4a1d976afa5203a4d3a2ac0e ] + +Continuous regulators can be configured to operate only in a certain +duty cycle range (for example from 0..91%). Add a check to error out if +the duty cycle translates to an unsupported (or out of range) voltage. + +Suggested-by: Uwe Kleine-König +Signed-off-by: Martin Blumenstingl +Link: https://msgid.link/r/20240113224628.377993-2-martin.blumenstingl@googlemail.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + drivers/regulator/pwm-regulator.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c +index 34f3b9778ffa1..215581dfd3330 100644 +--- a/drivers/regulator/pwm-regulator.c ++++ b/drivers/regulator/pwm-regulator.c +@@ -164,6 +164,9 @@ static int pwm_regulator_get_voltage(struct regulator_dev *rdev) + pwm_get_state(drvdata->pwm, &pstate); + + voltage = pwm_get_relative_duty_cycle(&pstate, duty_unit); ++ if (voltage < min(max_uV_duty, min_uV_duty) || ++ voltage > max(max_uV_duty, min_uV_duty)) ++ return -ENOTRECOVERABLE; + + /* + * The dutycycle for min_uV might be greater than the one for max_uV. +-- +2.43.0 + diff --git a/queue-4.19/scsi-target-core-add-tmf-to-tmr_list-handling.patch b/queue-4.19/scsi-target-core-add-tmf-to-tmr_list-handling.patch new file mode 100644 index 00000000000..b20ab5e3905 --- /dev/null +++ b/queue-4.19/scsi-target-core-add-tmf-to-tmr_list-handling.patch @@ -0,0 +1,88 @@ +From 5c33a15044a841f195f3827fbc78b340999421da Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 11 Jan 2024 15:59:41 +0300 +Subject: scsi: target: core: Add TMF to tmr_list handling + +From: Dmitry Bogdanov + +[ Upstream commit 83ab68168a3d990d5ff39ab030ad5754cbbccb25 ] + +An abort that is responded to by iSCSI itself is added to tmr_list but does +not go to target core. A LUN_RESET that goes through tmr_list takes a +refcounter on the abort and waits for completion. However, the abort will +be never complete because it was not started in target core. + + Unable to locate ITT: 0x05000000 on CID: 0 + Unable to locate RefTaskTag: 0x05000000 on CID: 0. + wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop + wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop +... + INFO: task kworker/0:2:49 blocked for more than 491 seconds. + task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 + Workqueue: events target_tmr_work [target_core_mod] +Call Trace: + __switch_to+0x2c4/0x470 + _schedule+0x314/0x1730 + schedule+0x64/0x130 + schedule_timeout+0x168/0x430 + wait_for_completion+0x140/0x270 + target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] + core_tmr_lun_reset+0x30/0xa0 [target_core_mod] + target_tmr_work+0xc8/0x1b0 [target_core_mod] + process_one_work+0x2d4/0x5d0 + worker_thread+0x78/0x6c0 + +To fix this, only add abort to tmr_list if it will be handled by target +core. + +Signed-off-by: Dmitry Bogdanov +Link: https://lore.kernel.org/r/20240111125941.8688-1-d.bogdanov@yadro.com +Reviewed-by: Mike Christie +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/target/target_core_device.c | 5 ----- + drivers/target/target_core_transport.c | 4 ++++ + 2 files changed, 4 insertions(+), 5 deletions(-) + +diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c +index a23dcbe79e14a..3ed43a5f1fd39 100644 +--- a/drivers/target/target_core_device.c ++++ b/drivers/target/target_core_device.c +@@ -164,7 +164,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64 unpacked_lun) + struct se_session *se_sess = se_cmd->se_sess; + struct se_node_acl *nacl = se_sess->se_node_acl; + struct se_tmr_req *se_tmr = se_cmd->se_tmr_req; +- unsigned long flags; + + rcu_read_lock(); + deve = target_nacl_find_deve(nacl, unpacked_lun); +@@ -195,10 +194,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64 unpacked_lun) + se_cmd->se_dev = rcu_dereference_raw(se_lun->lun_se_dev); + se_tmr->tmr_dev = rcu_dereference_raw(se_lun->lun_se_dev); + +- spin_lock_irqsave(&se_tmr->tmr_dev->se_tmr_lock, flags); +- list_add_tail(&se_tmr->tmr_list, &se_tmr->tmr_dev->dev_tmr_list); +- spin_unlock_irqrestore(&se_tmr->tmr_dev->se_tmr_lock, flags); +- + return 0; + } + EXPORT_SYMBOL(transport_lookup_tmr_lun); +diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c +index 64481a3a34d44..f8ba730fa1cfe 100644 +--- a/drivers/target/target_core_transport.c ++++ b/drivers/target/target_core_transport.c +@@ -3463,6 +3463,10 @@ int transport_generic_handle_tmr( + unsigned long flags; + bool aborted = false; + ++ spin_lock_irqsave(&cmd->se_dev->se_tmr_lock, flags); ++ list_add_tail(&cmd->se_tmr_req->tmr_list, &cmd->se_dev->dev_tmr_list); ++ spin_unlock_irqrestore(&cmd->se_dev->se_tmr_lock, flags); ++ + spin_lock_irqsave(&cmd->t_state_lock, flags); + if (cmd->transport_state & CMD_T_ABORTED) { + aborted = true; +-- +2.43.0 + diff --git a/queue-4.19/series b/queue-4.19/series index 8f362f45a34..2e967aa596e 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -9,3 +9,16 @@ userfaultfd-fix-mmap_changing-checking-in-mfill_atomic_hugetlb.patch sched-rt-fix-sysctl_sched_rr_timeslice-intial-value.patch sched-rt-sysctl_sched_rr_timeslice-show-default-timeslice-after-reset.patch sched-rt-disallow-writing-invalid-values-to-sched_rt_period_us.patch +scsi-target-core-add-tmf-to-tmr_list-handling.patch +dmaengine-shdma-increase-size-of-dev_id.patch +wifi-cfg80211-fix-missing-interfaces-when-dumping.patch +wifi-mac80211-fix-race-condition-on-enabling-fast-xm.patch +fbdev-savage-error-out-if-pixclock-equals-zero.patch +fbdev-sis-error-out-if-pixclock-equals-zero.patch +ahci-asm1166-correct-count-of-reported-ports.patch +ext4-avoid-allocating-blocks-from-corrupted-group-in.patch +ext4-avoid-allocating-blocks-from-corrupted-group-in.patch-4129 +regulator-pwm-regulator-add-validity-checks-in-conti.patch +hwmon-coretemp-enlarge-per-package-core-count-limit.patch +firewire-core-send-bus-reset-promptly-on-gap-count-e.patch +virtio-blk-ensure-no-requests-in-virtqueues-before-d.patch diff --git a/queue-4.19/virtio-blk-ensure-no-requests-in-virtqueues-before-d.patch b/queue-4.19/virtio-blk-ensure-no-requests-in-virtqueues-before-d.patch new file mode 100644 index 00000000000..c8aee23d023 --- /dev/null +++ b/queue-4.19/virtio-blk-ensure-no-requests-in-virtqueues-before-d.patch @@ -0,0 +1,64 @@ +From c84d932b6cbafd516b9f2d6b689c78bc00a6c4e9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 29 Jan 2024 16:52:50 +0800 +Subject: virtio-blk: Ensure no requests in virtqueues before deleting vqs. + +From: Yi Sun + +[ Upstream commit 4ce6e2db00de8103a0687fb0f65fd17124a51aaa ] + +Ensure no remaining requests in virtqueues before resetting vdev and +deleting virtqueues. Otherwise these requests will never be completed. +It may cause the system to become unresponsive. + +Function blk_mq_quiesce_queue() can ensure that requests have become +in_flight status, but it cannot guarantee that requests have been +processed by the device. Virtqueues should never be deleted before +all requests become complete status. + +Function blk_mq_freeze_queue() ensure that all requests in virtqueues +become complete status. And no requests can enter in virtqueues. + +Signed-off-by: Yi Sun +Reviewed-by: Stefan Hajnoczi +Link: https://lore.kernel.org/r/20240129085250.1550594-1-yi.sun@unisoc.com +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + drivers/block/virtio_blk.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c +index 8b3bf11329ba0..8e4c431efc6cc 100644 +--- a/drivers/block/virtio_blk.c ++++ b/drivers/block/virtio_blk.c +@@ -943,14 +943,15 @@ static int virtblk_freeze(struct virtio_device *vdev) + { + struct virtio_blk *vblk = vdev->priv; + ++ /* Ensure no requests in virtqueues before deleting vqs. */ ++ blk_mq_freeze_queue(vblk->disk->queue); ++ + /* Ensure we don't receive any more interrupts */ + vdev->config->reset(vdev); + + /* Make sure no work handler is accessing the device. */ + flush_work(&vblk->config_work); + +- blk_mq_quiesce_queue(vblk->disk->queue); +- + vdev->config->del_vqs(vdev); + kfree(vblk->vqs); + +@@ -968,7 +969,7 @@ static int virtblk_restore(struct virtio_device *vdev) + + virtio_device_ready(vdev); + +- blk_mq_unquiesce_queue(vblk->disk->queue); ++ blk_mq_unfreeze_queue(vblk->disk->queue); + return 0; + } + #endif +-- +2.43.0 + diff --git a/queue-4.19/wifi-cfg80211-fix-missing-interfaces-when-dumping.patch b/queue-4.19/wifi-cfg80211-fix-missing-interfaces-when-dumping.patch new file mode 100644 index 00000000000..1485ae4cc3c --- /dev/null +++ b/queue-4.19/wifi-cfg80211-fix-missing-interfaces-when-dumping.patch @@ -0,0 +1,71 @@ +From 6b0cc679c24fe001457b21021fd11163b2491cb7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 16 Jan 2024 14:22:57 +0000 +Subject: wifi: cfg80211: fix missing interfaces when dumping + +From: Michal Kazior + +[ Upstream commit a6e4f85d3820d00694ed10f581f4c650445dbcda ] + +The nl80211_dump_interface() supports resumption +in case nl80211_send_iface() doesn't have the +resources to complete its work. + +The logic would store the progress as iteration +offsets for rdev and wdev loops. + +However the logic did not properly handle +resumption for non-last rdev. Assuming a system +with 2 rdevs, with 2 wdevs each, this could +happen: + + dump(cb=[0, 0]): + if_start=cb[1] (=0) + send rdev0.wdev0 -> ok + send rdev0.wdev1 -> yield + cb[1] = 1 + + dump(cb=[0, 1]): + if_start=cb[1] (=1) + send rdev0.wdev1 -> ok + // since if_start=1 the rdev0.wdev0 got skipped + // through if_idx < if_start + send rdev1.wdev1 -> ok + +The if_start needs to be reset back to 0 upon wdev +loop end. + +The problem is actually hard to hit on a desktop, +and even on most routers. The prerequisites for +this manifesting was: + - more than 1 wiphy + - a few handful of interfaces + - dump without rdev or wdev filter + +I was seeing this with 4 wiphys 9 interfaces each. +It'd miss 6 interfaces from the last wiphy +reported to userspace. + +Signed-off-by: Michal Kazior +Link: https://msgid.link/20240116142340.89678-1-kazikcz@gmail.com +Signed-off-by: Johannes Berg +Signed-off-by: Sasha Levin +--- + net/wireless/nl80211.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c +index e33c1175b1582..f79700e5d801a 100644 +--- a/net/wireless/nl80211.c ++++ b/net/wireless/nl80211.c +@@ -2994,6 +2994,7 @@ static int nl80211_dump_interface(struct sk_buff *skb, struct netlink_callback * + if_idx++; + } + ++ if_start = 0; + wp_idx++; + } + out: +-- +2.43.0 + diff --git a/queue-4.19/wifi-mac80211-fix-race-condition-on-enabling-fast-xm.patch b/queue-4.19/wifi-mac80211-fix-race-condition-on-enabling-fast-xm.patch new file mode 100644 index 00000000000..97a3d3a732a --- /dev/null +++ b/queue-4.19/wifi-mac80211-fix-race-condition-on-enabling-fast-xm.patch @@ -0,0 +1,53 @@ +From 3300c376e98716c21b44ae3d4ff2a6c7a84ad8ea Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 4 Jan 2024 19:10:59 +0100 +Subject: wifi: mac80211: fix race condition on enabling fast-xmit + +From: Felix Fietkau + +[ Upstream commit bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f ] + +fast-xmit must only be enabled after the sta has been uploaded to the driver, +otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls +to the driver, leading to potential crashes because of uninitialized drv_priv +data. +Add a missing sta->uploaded check and re-check fast xmit after inserting a sta. + +Signed-off-by: Felix Fietkau +Link: https://msgid.link/20240104181059.84032-1-nbd@nbd.name +Signed-off-by: Johannes Berg +Signed-off-by: Sasha Levin +--- + net/mac80211/sta_info.c | 2 ++ + net/mac80211/tx.c | 2 +- + 2 files changed, 3 insertions(+), 1 deletion(-) + +diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c +index 5c209f72de701..714d0b01ea629 100644 +--- a/net/mac80211/sta_info.c ++++ b/net/mac80211/sta_info.c +@@ -629,6 +629,8 @@ static int sta_info_insert_finish(struct sta_info *sta) __acquires(RCU) + if (ieee80211_vif_is_mesh(&sdata->vif)) + mesh_accept_plinks_update(sdata); + ++ ieee80211_check_fast_xmit(sta); ++ + return 0; + out_remove: + sta_info_hash_del(local, sta); +diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c +index 3a0aadf881fc9..89500b1fe3016 100644 +--- a/net/mac80211/tx.c ++++ b/net/mac80211/tx.c +@@ -2868,7 +2868,7 @@ void ieee80211_check_fast_xmit(struct sta_info *sta) + sdata->vif.type == NL80211_IFTYPE_STATION) + goto out; + +- if (!test_sta_flag(sta, WLAN_STA_AUTHORIZED)) ++ if (!test_sta_flag(sta, WLAN_STA_AUTHORIZED) || !sta->uploaded) + goto out; + + if (test_sta_flag(sta, WLAN_STA_PS_STA) || +-- +2.43.0 + -- 2.47.2