From: Sasha Levin Date: Tue, 29 Apr 2025 01:39:19 +0000 (-0400) Subject: Fixes for 5.10 X-Git-Tag: v5.4.293~48 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=cd26141109f2888ab0182653477dafd7114eafc6;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.10 Signed-off-by: Sasha Levin --- diff --git a/queue-5.10/acpi-pptt-fix-coding-mistakes-in-a-couple-of-sizeof-.patch b/queue-5.10/acpi-pptt-fix-coding-mistakes-in-a-couple-of-sizeof-.patch new file mode 100644 index 0000000000..5029b4fbe3 --- /dev/null +++ b/queue-5.10/acpi-pptt-fix-coding-mistakes-in-a-couple-of-sizeof-.patch @@ -0,0 +1,46 @@ +From f6a60245ff0a3473f317eec015b0894d2fbe5f15 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Apr 2025 17:15:42 -0700 +Subject: ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls + +From: Jean-Marc Eurin + +[ Upstream commit 7ab4f0e37a0f4207e742a8de69be03984db6ebf0 ] + +The end of table checks should be done with the structure size, +but 2 of the 3 similar calls use the pointer size. + +Signed-off-by: Jean-Marc Eurin +Link: https://patch.msgid.link/20250402001542.2600671-1-jmeurin@google.com +[ rjw: Subject edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/acpi/pptt.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c +index 4ae93350b70de..38581001811b4 100644 +--- a/drivers/acpi/pptt.c ++++ b/drivers/acpi/pptt.c +@@ -217,7 +217,7 @@ static int acpi_pptt_leaf_node(struct acpi_table_header *table_hdr, + node_entry = ACPI_PTR_DIFF(node, table_hdr); + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, + sizeof(struct acpi_table_pptt)); +- proc_sz = sizeof(struct acpi_pptt_processor *); ++ proc_sz = sizeof(struct acpi_pptt_processor); + + while ((unsigned long)entry + proc_sz < table_end) { + cpu_node = (struct acpi_pptt_processor *)entry; +@@ -258,7 +258,7 @@ static struct acpi_pptt_processor *acpi_find_processor_node(struct acpi_table_he + table_end = (unsigned long)table_hdr + table_hdr->length; + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, + sizeof(struct acpi_table_pptt)); +- proc_sz = sizeof(struct acpi_pptt_processor *); ++ proc_sz = sizeof(struct acpi_pptt_processor); + + /* find the processor structure associated with this cpuid */ + while ((unsigned long)entry + proc_sz < table_end) { +-- +2.39.5 + diff --git a/queue-5.10/clk-check-for-disabled-clock-provider-in-of_clk_get_.patch b/queue-5.10/clk-check-for-disabled-clock-provider-in-of_clk_get_.patch new file mode 100644 index 0000000000..40d4ffd17d --- /dev/null +++ b/queue-5.10/clk-check-for-disabled-clock-provider-in-of_clk_get_.patch @@ -0,0 +1,61 @@ +From 925d5a65f693350df4a5c36781f0ae724c25a591 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 22 Feb 2025 23:37:33 +0100 +Subject: clk: check for disabled clock-provider in + of_clk_get_hw_from_clkspec() + +From: Heiko Stuebner + +[ Upstream commit b20150d499b3ee5c2d632fbc5ac94f98dd33accf ] + +of_clk_get_hw_from_clkspec() checks all available clock-providers by +comparing their of nodes to the one from the clkspec. If no matching +clock provider is found, the function returns -EPROBE_DEFER to cause a +re-check at a later date. If a matching clock provider is found, an +authoritative answer can be retrieved from it whether the clock exists +or not. + +This does not take into account that the clock-provider may never +appear, because it's node is disabled. This can happen when a clock is +optional, provided by a separate block which never gets enabled. + +One example of this happening is the rk3588's VOP, which has optional +additional display clocks coming from PLLs inside the hdmiphy blocks. +These can be used for better rates, but the system will also work +without them. + +The problem around that is described in the followups to[1]. As we +already know the of node of the presumed clock provider, add a check via +of_device_is_available() whether this is a "valid" device node. This +prevents eternal defer loops. + +Link: https://lore.kernel.org/dri-devel/20250215-vop2-hdmi1-disp-modes-v1-3-81962a7151d6@collabora.com/ [1] +Reviewed-by: Sebastian Reichel +Tested-by: Cristian Ciocaltea +Signed-off-by: Heiko Stuebner +Link: https://lore.kernel.org/r/20250222223733.2990179-1-heiko@sntech.de +[sboyd@kernel.org: Reword commit text a bit] +Signed-off-by: Stephen Boyd +Signed-off-by: Sasha Levin +--- + drivers/clk/clk.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c +index 7dc3b0cca252a..950dfa059a209 100644 +--- a/drivers/clk/clk.c ++++ b/drivers/clk/clk.c +@@ -4858,6 +4858,10 @@ of_clk_get_hw_from_clkspec(struct of_phandle_args *clkspec) + if (!clkspec) + return ERR_PTR(-EINVAL); + ++ /* Check if node in clkspec is in disabled/fail state */ ++ if (!of_device_is_available(clkspec->np)) ++ return ERR_PTR(-ENOENT); ++ + mutex_lock(&of_clk_mutex); + list_for_each_entry(provider, &of_clk_providers, link) { + if (provider->node == clkspec->np) { +-- +2.39.5 + diff --git a/queue-5.10/crypto-null-use-spin-lock-instead-of-mutex.patch b/queue-5.10/crypto-null-use-spin-lock-instead-of-mutex.patch new file mode 100644 index 0000000000..e1420f9d2e --- /dev/null +++ b/queue-5.10/crypto-null-use-spin-lock-instead-of-mutex.patch @@ -0,0 +1,101 @@ +From e00176f43b6ea8dd868a077a16ee66449dd7c0c4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Feb 2025 14:10:07 +0800 +Subject: crypto: null - Use spin lock instead of mutex + +From: Herbert Xu + +[ Upstream commit dcc47a028c24e793ce6d6efebfef1a1e92f80297 ] + +As the null algorithm may be freed in softirq context through +af_alg, use spin locks instead of mutexes to protect the default +null algorithm. + +Reported-by: syzbot+b3e02953598f447d4d2a@syzkaller.appspotmail.com +Signed-off-by: Herbert Xu +Signed-off-by: Sasha Levin +--- + crypto/crypto_null.c | 39 ++++++++++++++++++++++++++------------- + 1 file changed, 26 insertions(+), 13 deletions(-) + +diff --git a/crypto/crypto_null.c b/crypto/crypto_null.c +index 5b84b0f7cc178..3378670286535 100644 +--- a/crypto/crypto_null.c ++++ b/crypto/crypto_null.c +@@ -17,10 +17,10 @@ + #include + #include + #include +-#include ++#include + #include + +-static DEFINE_MUTEX(crypto_default_null_skcipher_lock); ++static DEFINE_SPINLOCK(crypto_default_null_skcipher_lock); + static struct crypto_sync_skcipher *crypto_default_null_skcipher; + static int crypto_default_null_skcipher_refcnt; + +@@ -152,23 +152,32 @@ MODULE_ALIAS_CRYPTO("cipher_null"); + + struct crypto_sync_skcipher *crypto_get_default_null_skcipher(void) + { ++ struct crypto_sync_skcipher *ntfm = NULL; + struct crypto_sync_skcipher *tfm; + +- mutex_lock(&crypto_default_null_skcipher_lock); ++ spin_lock_bh(&crypto_default_null_skcipher_lock); + tfm = crypto_default_null_skcipher; + + if (!tfm) { +- tfm = crypto_alloc_sync_skcipher("ecb(cipher_null)", 0, 0); +- if (IS_ERR(tfm)) +- goto unlock; +- +- crypto_default_null_skcipher = tfm; ++ spin_unlock_bh(&crypto_default_null_skcipher_lock); ++ ++ ntfm = crypto_alloc_sync_skcipher("ecb(cipher_null)", 0, 0); ++ if (IS_ERR(ntfm)) ++ return ntfm; ++ ++ spin_lock_bh(&crypto_default_null_skcipher_lock); ++ tfm = crypto_default_null_skcipher; ++ if (!tfm) { ++ tfm = ntfm; ++ ntfm = NULL; ++ crypto_default_null_skcipher = tfm; ++ } + } + + crypto_default_null_skcipher_refcnt++; ++ spin_unlock_bh(&crypto_default_null_skcipher_lock); + +-unlock: +- mutex_unlock(&crypto_default_null_skcipher_lock); ++ crypto_free_sync_skcipher(ntfm); + + return tfm; + } +@@ -176,12 +185,16 @@ EXPORT_SYMBOL_GPL(crypto_get_default_null_skcipher); + + void crypto_put_default_null_skcipher(void) + { +- mutex_lock(&crypto_default_null_skcipher_lock); ++ struct crypto_sync_skcipher *tfm = NULL; ++ ++ spin_lock_bh(&crypto_default_null_skcipher_lock); + if (!--crypto_default_null_skcipher_refcnt) { +- crypto_free_sync_skcipher(crypto_default_null_skcipher); ++ tfm = crypto_default_null_skcipher; + crypto_default_null_skcipher = NULL; + } +- mutex_unlock(&crypto_default_null_skcipher_lock); ++ spin_unlock_bh(&crypto_default_null_skcipher_lock); ++ ++ crypto_free_sync_skcipher(tfm); + } + EXPORT_SYMBOL_GPL(crypto_put_default_null_skcipher); + +-- +2.39.5 + diff --git a/queue-5.10/dmaengine-dmatest-fix-dmatest-waiting-less-when-inte.patch b/queue-5.10/dmaengine-dmatest-fix-dmatest-waiting-less-when-inte.patch new file mode 100644 index 0000000000..aac1cbcc97 --- /dev/null +++ b/queue-5.10/dmaengine-dmatest-fix-dmatest-waiting-less-when-inte.patch @@ -0,0 +1,51 @@ +From 5aef04bed0ab5957879f26667987af6753f31048 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 5 Mar 2025 15:00:06 -0800 +Subject: dmaengine: dmatest: Fix dmatest waiting less when interrupted + +From: Vinicius Costa Gomes + +[ Upstream commit e87ca16e99118ab4e130a41bdf12abbf6a87656c ] + +Change the "wait for operation finish" logic to take interrupts into +account. + +When using dmatest with idxd DMA engine, it's possible that during +longer tests, the interrupt notifying the finish of an operation +happens during wait_event_freezable_timeout(), which causes dmatest to +cleanup all the resources, some of which might still be in use. + +This fix ensures that the wait logic correctly handles interrupts, +preventing premature cleanup of resources. + +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-lkp/202502171134.8c403348-lkp@intel.com +Signed-off-by: Vinicius Costa Gomes +Reviewed-by: Dave Jiang +Link: https://lore.kernel.org/r/20250305230007.590178-1-vinicius.gomes@intel.com +Signed-off-by: Vinod Koul +Signed-off-by: Sasha Levin +--- + drivers/dma/dmatest.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c +index a3a172173e345..915724fd7ea6f 100644 +--- a/drivers/dma/dmatest.c ++++ b/drivers/dma/dmatest.c +@@ -825,9 +825,9 @@ static int dmatest_func(void *data) + } else { + dma_async_issue_pending(chan); + +- wait_event_freezable_timeout(thread->done_wait, +- done->done, +- msecs_to_jiffies(params->timeout)); ++ wait_event_timeout(thread->done_wait, ++ done->done, ++ msecs_to_jiffies(params->timeout)); + + status = dma_async_is_tx_complete(chan, cookie, NULL, + NULL); +-- +2.39.5 + diff --git a/queue-5.10/ext4-make-block-validity-check-resistent-to-sb-bh-co.patch b/queue-5.10/ext4-make-block-validity-check-resistent-to-sb-bh-co.patch new file mode 100644 index 0000000000..da3c29a208 --- /dev/null +++ b/queue-5.10/ext4-make-block-validity-check-resistent-to-sb-bh-co.patch @@ -0,0 +1,78 @@ +From 339c58ffb72fcbf13e0070a9b9a5d392ceebf5e5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 28 Mar 2025 11:54:52 +0530 +Subject: ext4: make block validity check resistent to sb bh corruption + +From: Ojaswin Mujoo + +[ Upstream commit ccad447a3d331a239477c281533bacb585b54a98 ] + +Block validity checks need to be skipped in case they are called +for journal blocks since they are part of system's protected +zone. + +Currently, this is done by checking inode->ino against +sbi->s_es->s_journal_inum, which is a direct read from the ext4 sb +buffer head. If someone modifies this underneath us then the +s_journal_inum field might get corrupted. To prevent against this, +change the check to directly compare the inode with journal->j_inode. + +**Slight change in behavior**: During journal init path, +check_block_validity etc might be called for journal inode when +sbi->s_journal is not set yet. In this case we now proceed with +ext4_inode_block_valid() instead of returning early. Since systems zones +have not been set yet, it is okay to proceed so we can perform basic +checks on the blocks. + +Suggested-by: Baokun Li +Reviewed-by: Baokun Li +Reviewed-by: Jan Kara +Reviewed-by: Zhang Yi +Signed-off-by: Ojaswin Mujoo +Link: https://patch.msgid.link/0c06bc9ebfcd6ccfed84a36e79147bf45ff5adc1.1743142920.git.ojaswin@linux.ibm.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + fs/ext4/block_validity.c | 5 ++--- + fs/ext4/inode.c | 7 ++++--- + 2 files changed, 6 insertions(+), 6 deletions(-) + +diff --git a/fs/ext4/block_validity.c b/fs/ext4/block_validity.c +index 295e89d93295e..5d5befac5622b 100644 +--- a/fs/ext4/block_validity.c ++++ b/fs/ext4/block_validity.c +@@ -353,10 +353,9 @@ int ext4_check_blockref(const char *function, unsigned int line, + { + __le32 *bref = p; + unsigned int blk; ++ journal_t *journal = EXT4_SB(inode->i_sb)->s_journal; + +- if (ext4_has_feature_journal(inode->i_sb) && +- (inode->i_ino == +- le32_to_cpu(EXT4_SB(inode->i_sb)->s_es->s_journal_inum))) ++ if (journal && inode == journal->j_inode) + return 0; + + while (bref < p+max) { +diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c +index 52d68edb6a09b..15d020279d3bd 100644 +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -409,10 +409,11 @@ static int __check_block_validity(struct inode *inode, const char *func, + unsigned int line, + struct ext4_map_blocks *map) + { +- if (ext4_has_feature_journal(inode->i_sb) && +- (inode->i_ino == +- le32_to_cpu(EXT4_SB(inode->i_sb)->s_es->s_journal_inum))) ++ journal_t *journal = EXT4_SB(inode->i_sb)->s_journal; ++ ++ if (journal && inode == journal->j_inode) + return 0; ++ + if (!ext4_inode_block_valid(inode, map->m_pblk, map->m_len)) { + ext4_error_inode(inode, func, line, map->m_pblk, + "lblock %lu mapped to illegal pblock %llu " +-- +2.39.5 + diff --git a/queue-5.10/kvm-s390-don-t-use-pk-through-tracepoints.patch b/queue-5.10/kvm-s390-don-t-use-pk-through-tracepoints.patch new file mode 100644 index 0000000000..0b755cebbc --- /dev/null +++ b/queue-5.10/kvm-s390-don-t-use-pk-through-tracepoints.patch @@ -0,0 +1,53 @@ +From f16c2caa1659f35da80b76e23649e8d0d353da07 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 17 Feb 2025 14:13:56 +0100 +Subject: KVM: s390: Don't use %pK through tracepoints +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Weißschuh + +[ Upstream commit 6c9567e0850be2f0f94ab64fa6512413fd1a1eb1 ] + +Restricted pointers ("%pK") are not meant to be used through TP_format(). +It can unintentionally expose security sensitive, raw pointer values. + +Use regular pointer formatting instead. + +Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ +Signed-off-by: Thomas Weißschuh +Reviewed-by: Michael Mueller +Link: https://lore.kernel.org/r/20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa@linutronix.de +Signed-off-by: Janosch Frank +Message-ID: <20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa@linutronix.de> +Signed-off-by: Sasha Levin +--- + arch/s390/kvm/trace-s390.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/s390/kvm/trace-s390.h b/arch/s390/kvm/trace-s390.h +index 6f0209d45164f..9c5f546a2e1a3 100644 +--- a/arch/s390/kvm/trace-s390.h ++++ b/arch/s390/kvm/trace-s390.h +@@ -56,7 +56,7 @@ TRACE_EVENT(kvm_s390_create_vcpu, + __entry->sie_block = sie_block; + ), + +- TP_printk("create cpu %d at 0x%pK, sie block at 0x%pK", ++ TP_printk("create cpu %d at 0x%p, sie block at 0x%p", + __entry->id, __entry->vcpu, __entry->sie_block) + ); + +@@ -255,7 +255,7 @@ TRACE_EVENT(kvm_s390_enable_css, + __entry->kvm = kvm; + ), + +- TP_printk("enabling channel I/O support (kvm @ %pK)\n", ++ TP_printk("enabling channel I/O support (kvm @ %p)\n", + __entry->kvm) + ); + +-- +2.39.5 + diff --git a/queue-5.10/md-raid1-add-check-for-missing-source-disk-in-proces.patch b/queue-5.10/md-raid1-add-check-for-missing-source-disk-in-proces.patch new file mode 100644 index 0000000000..0c87daaec9 --- /dev/null +++ b/queue-5.10/md-raid1-add-check-for-missing-source-disk-in-proces.patch @@ -0,0 +1,77 @@ +From 636f4fb0546491c0f144e48159aba11b1c596e97 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Apr 2025 17:38:08 +0300 +Subject: md/raid1: Add check for missing source disk in process_checks() + +From: Meir Elisha + +[ Upstream commit b7c178d9e57c8fd4238ff77263b877f6f16182ba ] + +During recovery/check operations, the process_checks function loops +through available disks to find a 'primary' source with successfully +read data. + +If no suitable source disk is found after checking all possibilities, +the 'primary' index will reach conf->raid_disks * 2. Add an explicit +check for this condition after the loop. If no source disk was found, +print an error message and return early to prevent further processing +without a valid primary source. + +Link: https://lore.kernel.org/linux-raid/20250408143808.1026534-1-meir.elisha@volumez.com +Signed-off-by: Meir Elisha +Suggested-and-reviewed-by: Yu Kuai +Signed-off-by: Yu Kuai +Signed-off-by: Sasha Levin +--- + drivers/md/raid1.c | 26 ++++++++++++++++---------- + 1 file changed, 16 insertions(+), 10 deletions(-) + +diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c +index 3619db7e382a0..dada9b2258a61 100644 +--- a/drivers/md/raid1.c ++++ b/drivers/md/raid1.c +@@ -2034,14 +2034,9 @@ static int fix_sync_read_error(struct r1bio *r1_bio) + if (!rdev_set_badblocks(rdev, sect, s, 0)) + abort = 1; + } +- if (abort) { +- conf->recovery_disabled = +- mddev->recovery_disabled; +- set_bit(MD_RECOVERY_INTR, &mddev->recovery); +- md_done_sync(mddev, r1_bio->sectors, 0); +- put_buf(r1_bio); ++ if (abort) + return 0; +- } ++ + /* Try next page */ + sectors -= s; + sect += s; +@@ -2181,10 +2176,21 @@ static void sync_request_write(struct mddev *mddev, struct r1bio *r1_bio) + int disks = conf->raid_disks * 2; + struct bio *wbio; + +- if (!test_bit(R1BIO_Uptodate, &r1_bio->state)) +- /* ouch - failed to read all of that. */ +- if (!fix_sync_read_error(r1_bio)) ++ if (!test_bit(R1BIO_Uptodate, &r1_bio->state)) { ++ /* ++ * ouch - failed to read all of that. ++ * No need to fix read error for check/repair ++ * because all member disks are read. ++ */ ++ if (test_bit(MD_RECOVERY_REQUESTED, &mddev->recovery) || ++ !fix_sync_read_error(r1_bio)) { ++ conf->recovery_disabled = mddev->recovery_disabled; ++ set_bit(MD_RECOVERY_INTR, &mddev->recovery); ++ md_done_sync(mddev, r1_bio->sectors, 0); ++ put_buf(r1_bio); + return; ++ } ++ } + + if (test_bit(MD_RECOVERY_REQUESTED, &mddev->recovery)) + process_checks(r1_bio); +-- +2.39.5 + diff --git a/queue-5.10/mips-cm-detect-cm-quirks-from-device-tree.patch b/queue-5.10/mips-cm-detect-cm-quirks-from-device-tree.patch new file mode 100644 index 0000000000..95970765bc --- /dev/null +++ b/queue-5.10/mips-cm-detect-cm-quirks-from-device-tree.patch @@ -0,0 +1,107 @@ +From f0bc70167b2e60aed36ddf339a5046b4a023f08d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 23 Jan 2025 12:01:56 +0100 +Subject: MIPS: cm: Detect CM quirks from device tree + +From: Gregory CLEMENT + +[ Upstream commit e27fbe16af5cfc40639de4ced67d1a866a1953e9 ] + +Some information that should be retrieved at runtime for the Coherence +Manager can be either absent or wrong. This patch allows checking if +some of this information is available from the device tree and updates +the internal variable accordingly. + +For now, only the compatible string associated with the broken HCI is +being retrieved. + +Signed-off-by: Gregory CLEMENT +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Sasha Levin +--- + arch/mips/include/asm/mips-cm.h | 22 ++++++++++++++++++++++ + arch/mips/kernel/mips-cm.c | 14 ++++++++++++++ + 2 files changed, 36 insertions(+) + +diff --git a/arch/mips/include/asm/mips-cm.h b/arch/mips/include/asm/mips-cm.h +index 696b40beb774f..0f31324998c0a 100644 +--- a/arch/mips/include/asm/mips-cm.h ++++ b/arch/mips/include/asm/mips-cm.h +@@ -47,6 +47,16 @@ extern phys_addr_t __mips_cm_phys_base(void); + */ + extern int mips_cm_is64; + ++/* ++ * mips_cm_is_l2_hci_broken - determine if HCI is broken ++ * ++ * Some CM reports show that Hardware Cache Initialization is ++ * complete, but in reality it's not the case. They also incorrectly ++ * indicate that Hardware Cache Initialization is supported. This ++ * flags allows warning about this broken feature. ++ */ ++extern bool mips_cm_is_l2_hci_broken; ++ + /** + * mips_cm_error_report - Report CM cache errors + */ +@@ -85,6 +95,18 @@ static inline bool mips_cm_present(void) + #endif + } + ++/** ++ * mips_cm_update_property - update property from the device tree ++ * ++ * Retrieve the properties from the device tree if a CM node exist and ++ * update the internal variable based on this. ++ */ ++#ifdef CONFIG_MIPS_CM ++extern void mips_cm_update_property(void); ++#else ++static void mips_cm_update_property(void) {} ++#endif ++ + /** + * mips_cm_has_l2sync - determine whether an L2-only sync region is present + * +diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c +index 72c8374a39002..a0d9cde26dc5b 100644 +--- a/arch/mips/kernel/mips-cm.c ++++ b/arch/mips/kernel/mips-cm.c +@@ -5,6 +5,7 @@ + */ + + #include ++#include + #include + #include + +@@ -14,6 +15,7 @@ + void __iomem *mips_gcr_base; + void __iomem *mips_cm_l2sync_base; + int mips_cm_is64; ++bool mips_cm_is_l2_hci_broken; + + static char *cm2_tr[8] = { + "mem", "gcr", "gic", "mmio", +@@ -238,6 +240,18 @@ static void mips_cm_probe_l2sync(void) + mips_cm_l2sync_base = ioremap(addr, MIPS_CM_L2SYNC_SIZE); + } + ++void mips_cm_update_property(void) ++{ ++ struct device_node *cm_node; ++ ++ cm_node = of_find_compatible_node(of_root, NULL, "mobileye,eyeq6-cm"); ++ if (!cm_node) ++ return; ++ pr_info("HCI (Hardware Cache Init for the L2 cache) in GCR_L2_RAM_CONFIG from the CM3 is broken"); ++ mips_cm_is_l2_hci_broken = true; ++ of_node_put(cm_node); ++} ++ + int mips_cm_probe(void) + { + phys_addr_t addr; +-- +2.39.5 + diff --git a/queue-5.10/ntb-reduce-stack-usage-in-idt_scan_mws.patch b/queue-5.10/ntb-reduce-stack-usage-in-idt_scan_mws.patch new file mode 100644 index 0000000000..e37af5d195 --- /dev/null +++ b/queue-5.10/ntb-reduce-stack-usage-in-idt_scan_mws.patch @@ -0,0 +1,77 @@ +From 367683289233dd5d957c926cce416b3b270407a1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 21 Feb 2025 09:57:25 +0100 +Subject: ntb: reduce stack usage in idt_scan_mws + +From: Arnd Bergmann + +[ Upstream commit aff12700b8dd7422bfe2277696e192af4df9de8f ] + +idt_scan_mws() puts a large fixed-size array on the stack and copies +it into a smaller dynamically allocated array at the end. On 32-bit +targets, the fixed size can easily exceed the warning limit for +possible stack overflow: + +drivers/ntb/hw/idt/ntb_hw_idt.c:1041:27: error: stack frame size (1032) exceeds limit (1024) in 'idt_scan_mws' [-Werror,-Wframe-larger-than] + +Change it to instead just always use dynamic allocation for the +array from the start. It's too big for the stack, but not actually +all that much for a permanent allocation. + +Reported-by: kernel test robot +Closes: https://lore.kernel.org/all/202205111109.PiKTruEj-lkp@intel.com/ +Signed-off-by: Arnd Bergmann +Reviewed-by: Dave Jiang +Reviewed-by: Damien Le Moal +Signed-off-by: Jon Mason +Signed-off-by: Sasha Levin +--- + drivers/ntb/hw/idt/ntb_hw_idt.c | 18 +++++++----------- + 1 file changed, 7 insertions(+), 11 deletions(-) + +diff --git a/drivers/ntb/hw/idt/ntb_hw_idt.c b/drivers/ntb/hw/idt/ntb_hw_idt.c +index 99711dd0b6e8e..d39fc55f8b0cc 100644 +--- a/drivers/ntb/hw/idt/ntb_hw_idt.c ++++ b/drivers/ntb/hw/idt/ntb_hw_idt.c +@@ -1041,7 +1041,7 @@ static inline char *idt_get_mw_name(enum idt_mw_type mw_type) + static struct idt_mw_cfg *idt_scan_mws(struct idt_ntb_dev *ndev, int port, + unsigned char *mw_cnt) + { +- struct idt_mw_cfg mws[IDT_MAX_NR_MWS], *ret_mws; ++ struct idt_mw_cfg *mws; + const struct idt_ntb_bar *bars; + enum idt_mw_type mw_type; + unsigned char widx, bidx, en_cnt; +@@ -1049,6 +1049,11 @@ static struct idt_mw_cfg *idt_scan_mws(struct idt_ntb_dev *ndev, int port, + int aprt_size; + u32 data; + ++ mws = devm_kcalloc(&ndev->ntb.pdev->dev, IDT_MAX_NR_MWS, ++ sizeof(*mws), GFP_KERNEL); ++ if (!mws) ++ return ERR_PTR(-ENOMEM); ++ + /* Retrieve the array of the BARs registers */ + bars = portdata_tbl[port].bars; + +@@ -1103,16 +1108,7 @@ static struct idt_mw_cfg *idt_scan_mws(struct idt_ntb_dev *ndev, int port, + } + } + +- /* Allocate memory for memory window descriptors */ +- ret_mws = devm_kcalloc(&ndev->ntb.pdev->dev, *mw_cnt, sizeof(*ret_mws), +- GFP_KERNEL); +- if (!ret_mws) +- return ERR_PTR(-ENOMEM); +- +- /* Copy the info of detected memory windows */ +- memcpy(ret_mws, mws, (*mw_cnt)*sizeof(*ret_mws)); +- +- return ret_mws; ++ return mws; + } + + /* +-- +2.39.5 + diff --git a/queue-5.10/nvme-re-read-ana-log-page-after-ns-scan-completes.patch b/queue-5.10/nvme-re-read-ana-log-page-after-ns-scan-completes.patch new file mode 100644 index 0000000000..d6725050cc --- /dev/null +++ b/queue-5.10/nvme-re-read-ana-log-page-after-ns-scan-completes.patch @@ -0,0 +1,47 @@ +From e397d923df2da3f3e307448c5c9fac46eaaad11c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 3 Apr 2025 09:19:30 +0200 +Subject: nvme: re-read ANA log page after ns scan completes + +From: Hannes Reinecke + +[ Upstream commit 62baf70c327444338c34703c71aa8cc8e4189bd6 ] + +When scanning for new namespaces we might have missed an ANA AEN. + +The NVMe base spec (NVMe Base Specification v2.1, Figure 151 'Asynchonous +Event Information - Notice': Asymmetric Namespace Access Change) states: + + A controller shall not send this even if an Attached Namespace + Attribute Changed asynchronous event [...] is sent for the same event. + +so we need to re-read the ANA log page after we rescanned the namespace +list to update the ANA states of the new namespaces. + +Signed-off-by: Hannes Reinecke +Reviewed-by: Keith Busch +Signed-off-by: Christoph Hellwig +Signed-off-by: Sasha Levin +--- + drivers/nvme/host/core.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c +index 94225ffd4643d..5f22f8e8dce7c 100644 +--- a/drivers/nvme/host/core.c ++++ b/drivers/nvme/host/core.c +@@ -4270,6 +4270,11 @@ static void nvme_scan_work(struct work_struct *work) + /* Requeue if we have missed AENs */ + if (test_bit(NVME_AER_NOTICE_NS_CHANGED, &ctrl->events)) + nvme_queue_scan(ctrl); ++#ifdef CONFIG_NVME_MULTIPATH ++ else ++ /* Re-read the ANA log page to not miss updates */ ++ queue_work(nvme_wq, &ctrl->ana_work); ++#endif + } + + /* +-- +2.39.5 + diff --git a/queue-5.10/nvme-requeue-namespace-scan-on-missed-aens.patch b/queue-5.10/nvme-requeue-namespace-scan-on-missed-aens.patch new file mode 100644 index 0000000000..d3170d0910 --- /dev/null +++ b/queue-5.10/nvme-requeue-namespace-scan-on-missed-aens.patch @@ -0,0 +1,42 @@ +From e976cbc8dd1b9424805bd6ec8fef8fac2583bcbd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 3 Apr 2025 09:19:29 +0200 +Subject: nvme: requeue namespace scan on missed AENs + +From: Hannes Reinecke + +[ Upstream commit 9546ad1a9bda7362492114f5866b95b0ac4a100e ] + +Scanning for namespaces can take some time, so if the target is +reconfigured while the scan is running we may miss a Attached Namespace +Attribute Changed AEN. + +Check if the NVME_AER_NOTICE_NS_CHANGED bit is set once the scan has +finished, and requeue scanning to pick up any missed change. + +Signed-off-by: Hannes Reinecke +Reviewed-by: Keith Busch +Signed-off-by: Christoph Hellwig +Signed-off-by: Sasha Levin +--- + drivers/nvme/host/core.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c +index e63d3ca11cc9a..94225ffd4643d 100644 +--- a/drivers/nvme/host/core.c ++++ b/drivers/nvme/host/core.c +@@ -4266,6 +4266,10 @@ static void nvme_scan_work(struct work_struct *work) + if (nvme_scan_ns_list(ctrl) != 0) + nvme_scan_ns_sequential(ctrl); + mutex_unlock(&ctrl->scan_lock); ++ ++ /* Requeue if we have missed AENs */ ++ if (test_bit(NVME_AER_NOTICE_NS_CHANGED, &ctrl->events)) ++ nvme_queue_scan(ctrl); + } + + /* +-- +2.39.5 + diff --git a/queue-5.10/objtool-asoc-codecs-wcd934x-remove-potential-undefin.patch b/queue-5.10/objtool-asoc-codecs-wcd934x-remove-potential-undefin.patch new file mode 100644 index 0000000000..b13876a9d3 --- /dev/null +++ b/queue-5.10/objtool-asoc-codecs-wcd934x-remove-potential-undefin.patch @@ -0,0 +1,58 @@ +From b703f570c02c9c223b50456c1ff57fc79f89b67d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Mar 2025 14:56:09 -0700 +Subject: objtool, ASoC: codecs: wcd934x: Remove potential undefined behavior + in wcd934x_slim_irq_handler() + +From: Josh Poimboeuf + +[ Upstream commit 060aed9c0093b341480770457093449771cf1496 ] + +If 'port_id' is negative, the shift counts in wcd934x_slim_irq_handler() +also become negative, resulting in undefined behavior due to shift out +of bounds. + +If I'm reading the code correctly, that appears to be not possible, but +with KCOV enabled, Clang's range analysis isn't always able to determine +that and generates undefined behavior. + +As a result the code generation isn't optimal, and undefined behavior +should be avoided regardless. Improve code generation and remove the +undefined behavior by converting the signed variables to unsigned. + +Fixes the following warning with UBSAN: + + sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section + +Reported-by: kernel test robot +Signed-off-by: Josh Poimboeuf +Signed-off-by: Ingo Molnar +Acked-by: Mark Brown +Cc: Srinivas Kandagatla +Cc: Liam Girdwood +Cc: Jaroslav Kysela +Cc: Takashi Iwai +Cc: Linus Torvalds +Link: https://lore.kernel.org/r/7e863839ec7301bf9c0f429a03873d44e484c31c.1742852847.git.jpoimboe@kernel.org +Closes: https://lore.kernel.org/oe-kbuild-all/202503180044.oH9gyPeg-lkp@intel.com/ +Signed-off-by: Sasha Levin +--- + sound/soc/codecs/wcd934x.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/sound/soc/codecs/wcd934x.c b/sound/soc/codecs/wcd934x.c +index 104751ac6cd14..8580f5e95ccf6 100644 +--- a/sound/soc/codecs/wcd934x.c ++++ b/sound/soc/codecs/wcd934x.c +@@ -2188,7 +2188,7 @@ static irqreturn_t wcd934x_slim_irq_handler(int irq, void *data) + { + struct wcd934x_codec *wcd = data; + unsigned long status = 0; +- int i, j, port_id; ++ unsigned int i, j, port_id; + unsigned int val, int_val = 0; + irqreturn_t ret = IRQ_NONE; + bool tx; +-- +2.39.5 + diff --git a/queue-5.10/objtool-stop-unret-validation-on-ud2.patch b/queue-5.10/objtool-stop-unret-validation-on-ud2.patch new file mode 100644 index 0000000000..4aba4f61e5 --- /dev/null +++ b/queue-5.10/objtool-stop-unret-validation-on-ud2.patch @@ -0,0 +1,38 @@ +From 391e22f449f7779a5ef35486175b1ce79fdfa205 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Apr 2025 00:02:15 -0700 +Subject: objtool: Stop UNRET validation on UD2 + +From: Josh Poimboeuf + +[ Upstream commit 9f9cc012c2cbac4833746a0182e06a8eec940d19 ] + +In preparation for simplifying INSN_SYSCALL, make validate_unret() +terminate control flow on UD2 just like validate_branch() already does. + +Signed-off-by: Josh Poimboeuf +Signed-off-by: Ingo Molnar +Cc: Linus Torvalds +Link: https://lore.kernel.org/r/ce841269e7e28c8b7f32064464a9821034d724ff.1744095216.git.jpoimboe@kernel.org +Signed-off-by: Sasha Levin +--- + tools/objtool/check.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/tools/objtool/check.c b/tools/objtool/check.c +index bcc9948645a00..20ccdd60353be 100644 +--- a/tools/objtool/check.c ++++ b/tools/objtool/check.c +@@ -3249,6 +3249,9 @@ static int validate_entry(struct objtool_file *file, struct instruction *insn) + break; + } + ++ if (insn->dead_end) ++ return 0; ++ + if (!next) { + WARN_FUNC("teh end!", insn->sec, insn->offset); + return -1; +-- +2.39.5 + diff --git a/queue-5.10/parisc-pdt-fix-missing-prototype-warning.patch b/queue-5.10/parisc-pdt-fix-missing-prototype-warning.patch new file mode 100644 index 0000000000..f2250a809e --- /dev/null +++ b/queue-5.10/parisc-pdt-fix-missing-prototype-warning.patch @@ -0,0 +1,51 @@ +From 389d9a9b081d46032cbebc167e6f667462b56518 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 9 Feb 2025 01:43:04 +0800 +Subject: parisc: PDT: Fix missing prototype warning + +From: Yu-Chun Lin + +[ Upstream commit b899981750dcb958ceffa4462d903963ee494aa2 ] + +As reported by the kernel test robot, the following error occurs: + +arch/parisc/kernel/pdt.c:65:6: warning: no previous prototype for 'arch_report_meminfo' [-Wmissing-prototypes] + 65 | void arch_report_meminfo(struct seq_file *m) + | ^~~~~~~~~~~~~~~~~~~ + +arch_report_meminfo() is declared in include/linux/proc_fs.h and only +defined when CONFIG_PROC_FS is enabled. Wrap its definition in #ifdef +CONFIG_PROC_FS to fix the -Wmissing-prototypes warning. + +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-kbuild-all/202502082315.IPaHaTyM-lkp@intel.com/ +Signed-off-by: Yu-Chun Lin +Signed-off-by: Helge Deller +Signed-off-by: Sasha Levin +--- + arch/parisc/kernel/pdt.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/arch/parisc/kernel/pdt.c b/arch/parisc/kernel/pdt.c +index fcc761b0e11b9..d20e8283c5b8a 100644 +--- a/arch/parisc/kernel/pdt.c ++++ b/arch/parisc/kernel/pdt.c +@@ -62,6 +62,7 @@ static unsigned long pdt_entry[MAX_PDT_ENTRIES] __page_aligned_bss; + #define PDT_ADDR_PERM_ERR (pdt_type != PDT_PDC ? 2UL : 0UL) + #define PDT_ADDR_SINGLE_ERR 1UL + ++#ifdef CONFIG_PROC_FS + /* report PDT entries via /proc/meminfo */ + void arch_report_meminfo(struct seq_file *m) + { +@@ -73,6 +74,7 @@ void arch_report_meminfo(struct seq_file *m) + seq_printf(m, "PDT_cur_entries: %7lu\n", + pdt_status.pdt_entries); + } ++#endif + + static int get_info_pat_new(void) + { +-- +2.39.5 + diff --git a/queue-5.10/qibfs-fix-_another_-leak.patch b/queue-5.10/qibfs-fix-_another_-leak.patch new file mode 100644 index 0000000000..a812d18158 --- /dev/null +++ b/queue-5.10/qibfs-fix-_another_-leak.patch @@ -0,0 +1,36 @@ +From 5b74cba507c44a78bc425bb32d67ff05b4d8c88a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 May 2024 17:50:34 -0600 +Subject: qibfs: fix _another_ leak + +From: Al Viro + +[ Upstream commit bdb43af4fdb39f844ede401bdb1258f67a580a27 ] + +failure to allocate inode => leaked dentry... + +this one had been there since the initial merge; to be fair, +if we are that far OOM, the odds of failing at that particular +allocation are low... + +Signed-off-by: Al Viro +Signed-off-by: Sasha Levin +--- + drivers/infiniband/hw/qib/qib_fs.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/infiniband/hw/qib/qib_fs.c b/drivers/infiniband/hw/qib/qib_fs.c +index e336d778e076e..5ec67e3c2d03c 100644 +--- a/drivers/infiniband/hw/qib/qib_fs.c ++++ b/drivers/infiniband/hw/qib/qib_fs.c +@@ -56,6 +56,7 @@ static int qibfs_mknod(struct inode *dir, struct dentry *dentry, + struct inode *inode = new_inode(dir->i_sb); + + if (!inode) { ++ dput(dentry); + error = -EPERM; + goto bail; + } +-- +2.39.5 + diff --git a/queue-5.10/sched-isolation-make-config_cpu_isolation-depend-on-.patch b/queue-5.10/sched-isolation-make-config_cpu_isolation-depend-on-.patch new file mode 100644 index 0000000000..99dc8f6249 --- /dev/null +++ b/queue-5.10/sched-isolation-make-config_cpu_isolation-depend-on-.patch @@ -0,0 +1,46 @@ +From 408820d344bca91a492d7fdceeb7edcee797f164 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 30 Mar 2025 15:49:55 +0200 +Subject: sched/isolation: Make CONFIG_CPU_ISOLATION depend on CONFIG_SMP + +From: Oleg Nesterov + +[ Upstream commit 975776841e689dd8ba36df9fa72ac3eca3c2957a ] + +kernel/sched/isolation.c obviously makes no sense without CONFIG_SMP, but +the Kconfig entry we have right now: + + config CPU_ISOLATION + bool "CPU isolation" + depends on SMP || COMPILE_TEST + +allows the creation of pointless .config's which cause +build failures. + +Reported-by: kernel test robot +Signed-off-by: Oleg Nesterov +Signed-off-by: Ingo Molnar +Link: https://lore.kernel.org/r/20250330134955.GA7910@redhat.com + +Closes: https://lore.kernel.org/oe-kbuild-all/202503260646.lrUqD3j5-lkp@intel.com/ +Signed-off-by: Sasha Levin +--- + init/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/init/Kconfig b/init/Kconfig +index 4e7775279356d..233166e54df35 100644 +--- a/init/Kconfig ++++ b/init/Kconfig +@@ -656,7 +656,7 @@ endmenu # "CPU/Task time and stats accounting" + + config CPU_ISOLATION + bool "CPU isolation" +- depends on SMP || COMPILE_TEST ++ depends on SMP + default y + help + Make sure that CPUs running critical tasks are not disturbed by +-- +2.39.5 + diff --git a/queue-5.10/scsi-pm80xx-set-phy_attached-to-zero-when-device-is-.patch b/queue-5.10/scsi-pm80xx-set-phy_attached-to-zero-when-device-is-.patch new file mode 100644 index 0000000000..1a5653bdcd --- /dev/null +++ b/queue-5.10/scsi-pm80xx-set-phy_attached-to-zero-when-device-is-.patch @@ -0,0 +1,36 @@ +From b6c0e0da5f0d067036811b359b4271ef6f5a5048 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 19 Mar 2025 23:03:05 +0000 +Subject: scsi: pm80xx: Set phy_attached to zero when device is gone + +From: Igor Pylypiv + +[ Upstream commit f7b705c238d1483f0a766e2b20010f176e5c0fb7 ] + +When a fatal error occurs, a phy down event may not be received to set +phy->phy_attached to zero. + +Signed-off-by: Igor Pylypiv +Signed-off-by: Salomon Dushimirimana +Link: https://lore.kernel.org/r/20250319230305.3172920-1-salomondush@google.com +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/pm8001/pm8001_sas.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/scsi/pm8001/pm8001_sas.c b/drivers/scsi/pm8001/pm8001_sas.c +index a16ed0695f1ae..3244f30dffec2 100644 +--- a/drivers/scsi/pm8001/pm8001_sas.c ++++ b/drivers/scsi/pm8001/pm8001_sas.c +@@ -892,6 +892,7 @@ static void pm8001_dev_gone_notify(struct domain_device *dev) + spin_lock_irqsave(&pm8001_ha->lock, flags); + } + PM8001_CHIP_DISP->dereg_dev_req(pm8001_ha, device_id); ++ pm8001_ha->phy[pm8001_dev->attached_phy].phy_attached = 0; + pm8001_free_dev(pm8001_dev); + } else { + pm8001_dbg(pm8001_ha, DISC, "Found dev has gone.\n"); +-- +2.39.5 + diff --git a/queue-5.10/selftests-mincore-allow-read-ahead-pages-to-reach-th.patch b/queue-5.10/selftests-mincore-allow-read-ahead-pages-to-reach-th.patch new file mode 100644 index 0000000000..209a7588ec --- /dev/null +++ b/queue-5.10/selftests-mincore-allow-read-ahead-pages-to-reach-th.patch @@ -0,0 +1,62 @@ +From 2c5d71e0fce9d87b18a437262757f21c66d15fa3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Mar 2025 16:09:40 +0800 +Subject: selftests/mincore: Allow read-ahead pages to reach the end of the + file + +From: Qiuxu Zhuo + +[ Upstream commit 197c1eaa7ba633a482ed7588eea6fd4aa57e08d4 ] + +When running the mincore_selftest on a system with an XFS file system, it +failed the "check_file_mmap" test case due to the read-ahead pages reaching +the end of the file. The failure log is as below: + + RUN global.check_file_mmap ... + mincore_selftest.c:264:check_file_mmap:Expected i (1024) < vec_size (1024) + mincore_selftest.c:265:check_file_mmap:Read-ahead pages reached the end of the file + check_file_mmap: Test failed + FAIL global.check_file_mmap + +This is because the read-ahead window size of the XFS file system on this +machine is 4 MB, which is larger than the size from the #PF address to the +end of the file. As a result, all the pages for this file are populated. + + blockdev --getra /dev/nvme0n1p5 + 8192 + blockdev --getbsz /dev/nvme0n1p5 + 512 + +This issue can be fixed by extending the current FILE_SIZE 4MB to a larger +number, but it will still fail if the read-ahead window size of the file +system is larger enough. Additionally, in the real world, read-ahead pages +reaching the end of the file can happen and is an expected behavior. +Therefore, allowing read-ahead pages to reach the end of the file is a +better choice for the "check_file_mmap" test case. + +Link: https://lore.kernel.org/r/20250311080940.21413-1-qiuxu.zhuo@intel.com +Reported-by: Yi Lai +Signed-off-by: Qiuxu Zhuo +Signed-off-by: Shuah Khan +Signed-off-by: Sasha Levin +--- + tools/testing/selftests/mincore/mincore_selftest.c | 3 --- + 1 file changed, 3 deletions(-) + +diff --git a/tools/testing/selftests/mincore/mincore_selftest.c b/tools/testing/selftests/mincore/mincore_selftest.c +index 2cf6f2f277ab8..31820435825b1 100644 +--- a/tools/testing/selftests/mincore/mincore_selftest.c ++++ b/tools/testing/selftests/mincore/mincore_selftest.c +@@ -262,9 +262,6 @@ TEST(check_file_mmap) + TH_LOG("No read-ahead pages found in memory"); + } + +- EXPECT_LT(i, vec_size) { +- TH_LOG("Read-ahead pages reached the end of the file"); +- } + /* + * End of the readahead window. The rest of the pages shouldn't + * be in memory. +-- +2.39.5 + diff --git a/queue-5.10/selftests-ublk-fix-test_stripe_04.patch b/queue-5.10/selftests-ublk-fix-test_stripe_04.patch new file mode 100644 index 0000000000..8c4e395c02 --- /dev/null +++ b/queue-5.10/selftests-ublk-fix-test_stripe_04.patch @@ -0,0 +1,58 @@ +From 32a461703997c643631522cd228e7726f45e2d4b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 4 Apr 2025 08:18:49 +0800 +Subject: selftests: ublk: fix test_stripe_04 + +From: Ming Lei + +[ Upstream commit 72070e57b0a518ec8e562a2b68fdfc796ef5c040 ] + +Commit 57ed58c13256 ("selftests: ublk: enable zero copy for stripe target") +added test entry of test_stripe_04, but forgot to add the test script. + +So fix the test by adding the script file. + +Reported-by: Uday Shankar +Signed-off-by: Ming Lei +Reviewed-by: Uday Shankar +Link: https://lore.kernel.org/r/20250404001849.1443064-1-ming.lei@redhat.com +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + .../testing/selftests/ublk/test_stripe_04.sh | 24 +++++++++++++++++++ + 1 file changed, 24 insertions(+) + create mode 100755 tools/testing/selftests/ublk/test_stripe_04.sh + +diff --git a/tools/testing/selftests/ublk/test_stripe_04.sh b/tools/testing/selftests/ublk/test_stripe_04.sh +new file mode 100755 +index 0000000000000..1f2b642381d17 +--- /dev/null ++++ b/tools/testing/selftests/ublk/test_stripe_04.sh +@@ -0,0 +1,24 @@ ++#!/bin/bash ++# SPDX-License-Identifier: GPL-2.0 ++ ++. "$(cd "$(dirname "$0")" && pwd)"/test_common.sh ++ ++TID="stripe_04" ++ERR_CODE=0 ++ ++_prep_test "stripe" "mkfs & mount & umount on zero copy" ++ ++backfile_0=$(_create_backfile 256M) ++backfile_1=$(_create_backfile 256M) ++dev_id=$(_add_ublk_dev -t stripe -z -q 2 "$backfile_0" "$backfile_1") ++_check_add_dev $TID $? "$backfile_0" "$backfile_1" ++ ++_mkfs_mount_test /dev/ublkb"${dev_id}" ++ERR_CODE=$? ++ ++_cleanup_test "stripe" ++ ++_remove_backfile "$backfile_0" ++_remove_backfile "$backfile_1" ++ ++_show_result $TID $ERR_CODE +-- +2.39.5 + diff --git a/queue-5.10/series b/queue-5.10/series index 7eb3ba8f4b..696ac0720c 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -257,3 +257,28 @@ usb-dwc3-gadget-check-that-event-count-does-not-exceed-event-buffer-length.patch usb-quirks-add-delay_init-quirk-for-silicon-motion-flash-drive.patch usb-quirks-add-delay-init-quirk-for-sandisk-3.2gen1-flash-drive.patch usb-vli-disk-crashes-if-lpm-is-used.patch +mips-cm-detect-cm-quirks-from-device-tree.patch +crypto-null-use-spin-lock-instead-of-mutex.patch +clk-check-for-disabled-clock-provider-in-of_clk_get_.patch +parisc-pdt-fix-missing-prototype-warning.patch +x86-kconfig-make-config_pci_cnb20le_quirk-depend-on-.patch +usb-host-max3421-hcd-add-missing-spi_device_id-table.patch +dmaengine-dmatest-fix-dmatest-waiting-less-when-inte.patch +usb-gadget-aspeed-add-null-pointer-check-in-ast_vhub.patch +objtool-asoc-codecs-wcd934x-remove-potential-undefin.patch +qibfs-fix-_another_-leak.patch +ntb-reduce-stack-usage-in-idt_scan_mws.patch +sched-isolation-make-config_cpu_isolation-depend-on-.patch +kvm-s390-don-t-use-pk-through-tracepoints.patch +udmabuf-fix-a-buf-size-overflow-issue-during-udmabuf.patch +selftests-ublk-fix-test_stripe_04.patch +nvme-requeue-namespace-scan-on-missed-aens.patch +acpi-pptt-fix-coding-mistakes-in-a-couple-of-sizeof-.patch +nvme-re-read-ana-log-page-after-ns-scan-completes.patch +objtool-stop-unret-validation-on-ud2.patch +selftests-mincore-allow-read-ahead-pages-to-reach-th.patch +x86-bugs-use-sbpb-in-write_ibpb-if-applicable.patch +x86-bugs-don-t-fill-rsb-on-vmexit-with-eibrs-retpoli.patch +ext4-make-block-validity-check-resistent-to-sb-bh-co.patch +scsi-pm80xx-set-phy_attached-to-zero-when-device-is-.patch +md-raid1-add-check-for-missing-source-disk-in-proces.patch diff --git a/queue-5.10/udmabuf-fix-a-buf-size-overflow-issue-during-udmabuf.patch b/queue-5.10/udmabuf-fix-a-buf-size-overflow-issue-during-udmabuf.patch new file mode 100644 index 0000000000..ad15acdfc8 --- /dev/null +++ b/queue-5.10/udmabuf-fix-a-buf-size-overflow-issue-during-udmabuf.patch @@ -0,0 +1,38 @@ +From 466c3e31401b5591a293eac3893b147346143c71 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 21 Mar 2025 11:41:26 -0500 +Subject: udmabuf: fix a buf size overflow issue during udmabuf creation +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Xiaogang Chen + +[ Upstream commit 021ba7f1babd029e714d13a6bf2571b08af96d0f ] + +by casting size_limit_mb to u64 when calculate pglimit. + +Signed-off-by: Xiaogang Chen +Link: https://patchwork.freedesktop.org/patch/msgid/20250321164126.329638-1-xiaogang.chen@amd.com +Signed-off-by: Christian König +Signed-off-by: Sasha Levin +--- + drivers/dma-buf/udmabuf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c +index 14b79458ac7f4..597a92438afc1 100644 +--- a/drivers/dma-buf/udmabuf.c ++++ b/drivers/dma-buf/udmabuf.c +@@ -177,7 +177,7 @@ static long udmabuf_create(struct miscdevice *device, + if (!ubuf) + return -ENOMEM; + +- pglimit = (size_limit_mb * 1024 * 1024) >> PAGE_SHIFT; ++ pglimit = ((u64)size_limit_mb * 1024 * 1024) >> PAGE_SHIFT; + for (i = 0; i < head->count; i++) { + if (!IS_ALIGNED(list[i].offset, PAGE_SIZE)) + goto err; +-- +2.39.5 + diff --git a/queue-5.10/usb-gadget-aspeed-add-null-pointer-check-in-ast_vhub.patch b/queue-5.10/usb-gadget-aspeed-add-null-pointer-check-in-ast_vhub.patch new file mode 100644 index 0000000000..ae3729ae14 --- /dev/null +++ b/queue-5.10/usb-gadget-aspeed-add-null-pointer-check-in-ast_vhub.patch @@ -0,0 +1,41 @@ +From c184b75948cca0339fa54b54f7457b4ae6b0b51e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 10 Mar 2025 20:27:05 -0500 +Subject: usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() + +From: Chenyuan Yang + +[ Upstream commit 8c75f3e6a433d92084ad4e78b029ae680865420f ] + +The variable d->name, returned by devm_kasprintf(), could be NULL. +A pointer check is added to prevent potential NULL pointer dereference. +This is similar to the fix in commit 3027e7b15b02 +("ice: Fix some null pointer dereference issues in ice_ptp.c"). + +This issue is found by our static analysis tool + +Signed-off-by: Chenyuan Yang +Link: https://lore.kernel.org/r/20250311012705.1233829-1-chenyuan0y@gmail.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/usb/gadget/udc/aspeed-vhub/dev.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c +index d268306a7bfee..92755a2fe4ff7 100644 +--- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c ++++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c +@@ -543,6 +543,9 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx) + d->vhub = vhub; + d->index = idx; + d->name = devm_kasprintf(parent, GFP_KERNEL, "port%d", idx+1); ++ if (!d->name) ++ return -ENOMEM; ++ + d->regs = vhub->regs + 0x100 + 0x10 * idx; + + ast_vhub_init_ep0(vhub, &d->ep0, d); +-- +2.39.5 + diff --git a/queue-5.10/usb-host-max3421-hcd-add-missing-spi_device_id-table.patch b/queue-5.10/usb-host-max3421-hcd-add-missing-spi_device_id-table.patch new file mode 100644 index 0000000000..0fdef733e8 --- /dev/null +++ b/queue-5.10/usb-host-max3421-hcd-add-missing-spi_device_id-table.patch @@ -0,0 +1,51 @@ +From 6a83f13f972c0a43410b282f8e053a3b533e9873 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 28 Jan 2025 20:51:13 +0100 +Subject: usb: host: max3421-hcd: Add missing spi_device_id table + +From: Alexander Stein + +[ Upstream commit 41d5e3806cf589f658f92c75195095df0b66f66a ] + +"maxim,max3421" DT compatible is missing its SPI device ID entry, not +allowing module autoloading and leading to the following message: + "SPI driver max3421-hcd has no spi_device_id for maxim,max3421" + +Fix this by adding the spi_device_id table. + +Signed-off-by: Alexander Stein +Link: https://lore.kernel.org/r/20250128195114.56321-1-alexander.stein@mailbox.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/usb/host/max3421-hcd.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c +index 44a35629d68c6..db1b73486e90b 100644 +--- a/drivers/usb/host/max3421-hcd.c ++++ b/drivers/usb/host/max3421-hcd.c +@@ -1956,6 +1956,12 @@ max3421_remove(struct spi_device *spi) + return 0; + } + ++static const struct spi_device_id max3421_spi_ids[] = { ++ { "max3421" }, ++ { }, ++}; ++MODULE_DEVICE_TABLE(spi, max3421_spi_ids); ++ + static const struct of_device_id max3421_of_match_table[] = { + { .compatible = "maxim,max3421", }, + {}, +@@ -1965,6 +1971,7 @@ MODULE_DEVICE_TABLE(of, max3421_of_match_table); + static struct spi_driver max3421_driver = { + .probe = max3421_probe, + .remove = max3421_remove, ++ .id_table = max3421_spi_ids, + .driver = { + .name = "max3421-hcd", + .of_match_table = of_match_ptr(max3421_of_match_table), +-- +2.39.5 + diff --git a/queue-5.10/x86-bugs-don-t-fill-rsb-on-vmexit-with-eibrs-retpoli.patch b/queue-5.10/x86-bugs-don-t-fill-rsb-on-vmexit-with-eibrs-retpoli.patch new file mode 100644 index 0000000000..b8111a8ee1 --- /dev/null +++ b/queue-5.10/x86-bugs-don-t-fill-rsb-on-vmexit-with-eibrs-retpoli.patch @@ -0,0 +1,64 @@ +From 1321d061a45df76242a803ae2bb3edfc0b74ba0c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Apr 2025 14:47:33 -0700 +Subject: x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline + +From: Josh Poimboeuf + +[ Upstream commit 18bae0dfec15b24ec14ca17dc18603372f5f254f ] + +eIBRS protects against guest->host RSB underflow/poisoning attacks. +Adding retpoline to the mix doesn't change that. Retpoline has a +balanced CALL/RET anyway. + +So the current full RSB filling on VMEXIT with eIBRS+retpoline is +overkill. Disable it or do the VMEXIT_LITE mitigation if needed. + +Suggested-by: Pawan Gupta +Signed-off-by: Josh Poimboeuf +Signed-off-by: Ingo Molnar +Reviewed-by: Pawan Gupta +Reviewed-by: Amit Shah +Reviewed-by: Nikolay Borisov +Cc: Paolo Bonzini +Cc: Vitaly Kuznetsov +Cc: Sean Christopherson +Cc: David Woodhouse +Link: https://lore.kernel.org/r/84a1226e5c9e2698eae1b5ade861f1b8bf3677dc.1744148254.git.jpoimboe@kernel.org +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/cpu/bugs.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c +index 725f827718a71..045ab6d0a98bb 100644 +--- a/arch/x86/kernel/cpu/bugs.c ++++ b/arch/x86/kernel/cpu/bugs.c +@@ -1543,20 +1543,20 @@ static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_ + case SPECTRE_V2_NONE: + return; + +- case SPECTRE_V2_EIBRS_LFENCE: + case SPECTRE_V2_EIBRS: ++ case SPECTRE_V2_EIBRS_LFENCE: ++ case SPECTRE_V2_EIBRS_RETPOLINE: + if (boot_cpu_has_bug(X86_BUG_EIBRS_PBRSB)) { +- setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT_LITE); + pr_info("Spectre v2 / PBRSB-eIBRS: Retire a single CALL on VMEXIT\n"); ++ setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT_LITE); + } + return; + +- case SPECTRE_V2_EIBRS_RETPOLINE: + case SPECTRE_V2_RETPOLINE: + case SPECTRE_V2_LFENCE: + case SPECTRE_V2_IBRS: +- setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT); + pr_info("Spectre v2 / SpectreRSB : Filling RSB on VMEXIT\n"); ++ setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT); + return; + } + +-- +2.39.5 + diff --git a/queue-5.10/x86-bugs-use-sbpb-in-write_ibpb-if-applicable.patch b/queue-5.10/x86-bugs-use-sbpb-in-write_ibpb-if-applicable.patch new file mode 100644 index 0000000000..0ffbd29031 --- /dev/null +++ b/queue-5.10/x86-bugs-use-sbpb-in-write_ibpb-if-applicable.patch @@ -0,0 +1,41 @@ +From e3c9af02a48dee9042744e46a770e1e45624860c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Apr 2025 14:47:31 -0700 +Subject: x86/bugs: Use SBPB in write_ibpb() if applicable + +From: Josh Poimboeuf + +[ Upstream commit fc9fd3f98423367c79e0bd85a9515df26dc1b3cc ] + +write_ibpb() does IBPB, which (among other things) flushes branch type +predictions on AMD. If the CPU has SRSO_NO, or if the SRSO mitigation +has been disabled, branch type flushing isn't needed, in which case the +lighter-weight SBPB can be used. + +The 'x86_pred_cmd' variable already keeps track of whether IBPB or SBPB +should be used. Use that instead of hardcoding IBPB. + +Signed-off-by: Josh Poimboeuf +Signed-off-by: Ingo Molnar +Link: https://lore.kernel.org/r/17c5dcd14b29199b75199d67ff7758de9d9a4928.1744148254.git.jpoimboe@kernel.org +Signed-off-by: Sasha Levin +--- + arch/x86/entry/entry.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/x86/entry/entry.S b/arch/x86/entry/entry.S +index f4419afc7147d..bda217961172b 100644 +--- a/arch/x86/entry/entry.S ++++ b/arch/x86/entry/entry.S +@@ -16,7 +16,7 @@ + + SYM_FUNC_START(entry_ibpb) + movl $MSR_IA32_PRED_CMD, %ecx +- movl $PRED_CMD_IBPB, %eax ++ movl _ASM_RIP(x86_pred_cmd), %eax + xorl %edx, %edx + wrmsr + +-- +2.39.5 + diff --git a/queue-5.10/x86-kconfig-make-config_pci_cnb20le_quirk-depend-on-.patch b/queue-5.10/x86-kconfig-make-config_pci_cnb20le_quirk-depend-on-.patch new file mode 100644 index 0000000000..0ba16dfe21 --- /dev/null +++ b/queue-5.10/x86-kconfig-make-config_pci_cnb20le_quirk-depend-on-.patch @@ -0,0 +1,97 @@ +From 1e25e95318efbe250757b4da20f177a50ac0c3ea Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 21 Mar 2025 21:48:48 +0100 +Subject: x86/Kconfig: Make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Mateusz Jończyk + +[ Upstream commit d9f87802676bb23b9425aea8ad95c76ad9b50c6e ] + +I was unable to find a good description of the ServerWorks CNB20LE +chipset. However, it was probably exclusively used with the Pentium III +processor (this CPU model was used in all references to it that I +found where the CPU model was provided: dmesgs in [1] and [2]; +[3] page 2; [4]-[7]). + +As is widely known, the Pentium III processor did not support the 64-bit +mode, support for which was introduced by Intel a couple of years later. +So it is safe to assume that no systems with the CNB20LE chipset have +amd64 and the CONFIG_PCI_CNB20LE_QUIRK may now depend on X86_32. + +Additionally, I have determined that most computers with the CNB20LE +chipset did have ACPI support and this driver was inactive on them. +I have submitted a patch to remove this driver, but it was met with +resistance [8]. + +[1] Jim Studt, Re: Problem with ServerWorks CNB20LE and lost interrupts + Linux Kernel Mailing List, https://lkml.org/lkml/2002/1/11/111 + +[2] RedHat Bug 665109 - e100 problems on old Compaq Proliant DL320 + https://bugzilla.redhat.com/show_bug.cgi?id=665109 + +[3] R. Hughes-Jones, S. Dallison, G. Fairey, Performance Measurements on + Gigabit Ethernet NICs and Server Quality Motherboards, + http://datatag.web.cern.ch/papers/pfldnet2003-rhj.doc + +[4] "Hardware for Linux", + Probe #d6b5151873 of Intel STL2-bd A28808-302 Desktop Computer (STL2) + https://linux-hardware.org/?probe=d6b5151873 + +[5] "Hardware for Linux", Probe #0b5d843f10 of Compaq ProLiant DL380 + https://linux-hardware.org/?probe=0b5d843f10 + +[6] Ubuntu Forums, Dell Poweredge 2400 - Adaptec SCSI Bus AIC-7880 + https://ubuntuforums.org/showthread.php?t=1689552 + +[7] Ira W. Snyder, "BISECTED: 2.6.35 (and -git) fail to boot: APIC problems" + https://lkml.org/lkml/2010/8/13/220 + +[8] Bjorn Helgaas, "Re: [PATCH] x86/pci: drop ServerWorks / Broadcom + CNB20LE PCI host bridge driver" + https://lore.kernel.org/lkml/20220318165535.GA840063@bhelgaas/T/ + +Signed-off-by: Mateusz Jończyk +Signed-off-by: David Heideberg +Signed-off-by: Ingo Molnar +Cc: "H. Peter Anvin" +Cc: Linus Torvalds +Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-6-b0cbaa6fa338@ixit.cz +Signed-off-by: Sasha Levin +--- + arch/x86/Kconfig | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig +index 93a1f9937a9bb..f3a7e8fdc83c7 100644 +--- a/arch/x86/Kconfig ++++ b/arch/x86/Kconfig +@@ -2766,13 +2766,21 @@ config MMCONF_FAM10H + depends on X86_64 && PCI_MMCONFIG && ACPI + + config PCI_CNB20LE_QUIRK +- bool "Read CNB20LE Host Bridge Windows" if EXPERT +- depends on PCI ++ bool "Read PCI host bridge windows from the CNB20LE chipset" if EXPERT ++ depends on X86_32 && PCI + help + Read the PCI windows out of the CNB20LE host bridge. This allows + PCI hotplug to work on systems with the CNB20LE chipset which do + not have ACPI. + ++ The ServerWorks (later Broadcom) CNB20LE was a chipset designed ++ most probably only for Pentium III. ++ ++ To find out if you have such a chipset, search for a PCI device with ++ 1166:0009 PCI IDs, for example by executing ++ lspci -nn | grep '1166:0009' ++ The code is inactive if there is none. ++ + There's no public spec for this chipset, and this functionality + is known to be incomplete. + +-- +2.39.5 +