August 2025 - Linux-stable-mirror

[PATCH] riscv: Only allow LTO with CMODEL_MEDANY

by Nathan Chancellor

When building with CONFIG_CMODEL_MEDLOW and CONFIG_LTO_CLANG, there is a series of errors due to some files being unconditionally compiled with '-mcmodel=medany', mismatching with the rest of the kernel built with '-mcmodel=medlow': ld.lld: error: Function Import: link error: linking module flags 'Code Model': IDs have conflicting values: 'i32 3' from vmlinux.a(init.o at 899908), and 'i32 1' from vmlinux.a(net-traces.o at 1014628) Only allow LTO to be performed when CONFIG_CMODEL_MEDANY is enabled to ensure there will be no code model mismatch errors. An alternative solution would be disabling LTO for the files with a different code model than the main kernel like some specialized areas of the kernel do but doing that for individual files is not as sustainable than forbidding the combination altogether. Cc: stable(a)vger.kernel.org Fixes: 021d23428bdb ("RISC-V: build: Allow LTO to be selected") Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506290255.KBVM83vZ-lkp@intel.com/ Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- arch/riscv/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 36061f4732b7..4eee737a050f 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -68,7 +68,7 @@ config RISCV select ARCH_SUPPORTS_HUGE_PFNMAP if TRANSPARENT_HUGEPAGE select ARCH_SUPPORTS_HUGETLBFS if MMU # LLD >= 14: https://github.com/llvm/llvm-project/issues/50505 - select ARCH_SUPPORTS_LTO_CLANG if LLD_VERSION >= 140000 + select ARCH_SUPPORTS_LTO_CLANG if LLD_VERSION >= 140000 && CMODEL_MEDANY select ARCH_SUPPORTS_LTO_CLANG_THIN if LLD_VERSION >= 140000 select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS if 64BIT && MMU select ARCH_SUPPORTS_PAGE_TABLE_CHECK if MMU --- base-commit: fda589c286040d9ba2d72a0eaf0a13945fc48026 change-id: 20250710-riscv-restrict-lto-to-medany-f1b7dd5c9bba Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

6 days, 2 hours

2
3
0 0

[PATCH AUTOSEL 6.16-5.4] kconfig: gconf: avoid hardcoding model2 in on_treeview2_cursor_changed()

by Sasha Levin

From: Masahiro Yamada <masahiroy(a)kernel.org> [ Upstream commit cae9cdbcd9af044810bcceeb43a87accca47c71d ] The on_treeview2_cursor_changed() handler is connected to both the left and right tree views, but it hardcodes model2 (the GtkTreeModel of the right tree view). This is incorrect. Get the associated model from the view. Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Let me check the commit you provided more carefully. Looking at the diff: The commit changes line 851-852 in the `on_treeview2_cursor_changed` function from: ```c if (gtk_tree_selection_get_selected(selection, &model2, &iter)) { gtk_tree_model_get(model2, &iter, COL_MENU, &menu, -1); ``` To: ```c if (gtk_tree_selection_get_selected(selection, &model, &iter)) { gtk_tree_model_get(model, &iter, COL_MENU, &menu, -1); ``` Where `model` is obtained from: `GtkTreeModel *model = gtk_tree_view_get_model(treeview);` This is indeed a bug fix. The function `on_treeview2_cursor_changed()` is connected as a signal handler to BOTH tree views (tree1_w and tree2_w), as shown in the connection code around lines 989 and 997. However, the old code hardcoded `model2` which is specifically the model for the right tree view. This would cause incorrect behavior when the handler is triggered from the left tree view (tree1_w). **Backport Status: YES** ## Extensive Analysis: ### Bug Description: The commit fixes a clear bug in the gconf GUI tool for kernel configuration. The `on_treeview2_cursor_changed()` function is used as a signal handler for cursor changes in both the left and right tree views of the configuration interface. However, the function incorrectly hardcoded `model2` (the GtkTreeModel for the right tree view) instead of dynamically getting the model from whichever view triggered the event. ### Code Analysis: 1. **Signal Connection** (lines 988-997 in the repository): - The same handler is connected to both tree views: ```c g_signal_connect(tree1_w, "cursor-changed", G_CALLBACK(on_treeview2_cursor_changed), NULL); g_signal_connect(tree2_w, "cursor-changed", G_CALLBACK(on_treeview2_cursor_changed), NULL); ``` 2. **The Bug**: When the cursor changes in tree1_w (left tree), the handler would incorrectly use model2 (right tree's model) to get the selected item, potentially causing: - Incorrect help text display - Crashes if the models have different structures - Undefined behavior when accessing invalid iterators 3. **The Fix**: The commit correctly obtains the model from the treeview parameter that triggered the event: ```c GtkTreeModel *model = gtk_tree_view_get_model(treeview); ``` This ensures the correct model is used regardless of which tree view triggered the event. ### Backport Justification: 1. **Clear Bug Fix**: This fixes an obvious programming error that affects functionality 2. **Small and Contained**: The change is minimal (2 lines modified) and localized to a single function 3. **Low Risk**: The fix is straightforward and correct - getting the model from the actual tree view instead of hardcoding 4. **User Impact**: This bug could affect users of the gconf configuration tool, potentially causing crashes or incorrect behavior 5. **No Architectural Changes**: This is a simple bug fix with no design changes 6. **No New Features**: Pure bug fix, no functionality additions This is an ideal candidate for stable backporting as it's a clear, minimal bug fix that improves reliability without introducing risk. scripts/kconfig/gconf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/scripts/kconfig/gconf.c b/scripts/kconfig/gconf.c index c0f46f189060..abe4cfe66b14 100644 --- a/scripts/kconfig/gconf.c +++ b/scripts/kconfig/gconf.c @@ -942,13 +942,14 @@ on_treeview2_key_press_event(GtkWidget * widget, void on_treeview2_cursor_changed(GtkTreeView * treeview, gpointer user_data) { + GtkTreeModel *model = gtk_tree_view_get_model(treeview); GtkTreeSelection *selection; GtkTreeIter iter; struct menu *menu; selection = gtk_tree_view_get_selection(treeview); - if (gtk_tree_selection_get_selected(selection, &model2, &iter)) { - gtk_tree_model_get(model2, &iter, COL_MENU, &menu, -1); + if (gtk_tree_selection_get_selected(selection, &model, &iter)) { + gtk_tree_model_get(model, &iter, COL_MENU, &menu, -1); text_insert_help(menu); } } -- 2.39.5

6 days, 2 hours

1
12
0 0

[PATCH 5.10] dma-buf: insert memory barrier before updating num_fences

by Jay Wang

From: Hyejeong Choi <hjeong.choi(a)samsung.com> commit 72c7d62583ebce7baeb61acce6057c361f73be4a upstream. smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered. Signed-off-by: Hyejeong Choi <hjeong.choi(a)samsung.com> Fixes: a590d0fdbaa5 ("dma-buf: Update reservation shared_count after adding the new fence") CC: stable(a)vger.kernel.org Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://lore.kernel.org/r/20250513020638.GA2329653@au1-maretx-p37.eng.sarc.… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Conflict resolved by applying changes from dma_resv_add_fence() in the original fix to dma_resv_add_shared_fence() in current code base] Signed-off-by: Jay Wang <wanjay(a)amazon.com> --- drivers/dma-buf/dma-resv.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 789f72db097f..16eb0b389e08 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -291,8 +291,9 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence *fence) replace: RCU_INIT_POINTER(fobj->shared[i], fence); - /* pointer update must be visible before we extend the shared_count */ - smp_store_mb(fobj->shared_count, count); + /* fence update must be visible before we extend the shared_count */ + smp_wmb(); + fobj->shared_count = count; write_seqcount_end(&obj->seq); dma_fence_put(old); -- 2.47.3

6 days, 3 hours

2
1
0 0

[PATCH i2c-host-fixes v4 0/5] i2c: rtl9300: Fix multi-byte I2C operations

by Sven Eckelmann

During the integration of the RTL8239 POE chip + its frontend MCU, it was noticed that multi-byte operations were basically broken in the current driver. Tests using SMBus Block Writes showed that the data (after the Wr maker + Ack) was mixed up on the wire. At first glance, it looked like an endianness problem. But for transfers where the number of count + data bytes was not divisible by 4, the last bytes were not looking like an endianness problem because they were in the wrong order but not for example 0 - which would be the case for an endianness problem with 32 bit registers. At the end, it turned out to be the way how i2c_write tried to add the bytes to the send registers. Each 32 bit register was used similar to a shift register - shifting the various bytes up the register while the next one is added to the least significant byte. But the I2C controller expects the first byte of the transmission in the least significant byte of the first register. And the last byte (assuming it is a 16 byte transfer) is expected in the most significant byte of the fourth register. While doing these tests, it was also observed that the count byte was missing from the SMBus Block Writes. The driver just removed them from the data->block (from the I2C subsystem). But the I2C controller DOES NOT automatically add this byte - for example by using the configured transmission length. The RTL8239 MCU is not actually an SMBus compliant device. Instead, it expects I2C Block Reads + I2C Block Writes. But according to the already identified bugs in the driver, it was clear that the I2C controller can simply be modified to not send the count byte for I2C_SMBUS_I2C_BLOCK_DATA. The receive part just needs to write the content of the receive buffer to the correct position in data->block. While the on-wire format was now correct, reads were still not possible against the MCU (for the RTL8239 POE chip). It was always timing out because the 2ms were not enough for sending the read request and then receiving the 12 byte answer. These changes were originally submitted to OpenWrt. But there are plans to migrate OpenWrt to the upstream Linux driver. As a result, the pull request was stopped and the changes were redone against this driver. For reasons of transparency: The work on I2C_SMBUS_I2C_BLOCK_DATA support for the RTL8239-MCU was done on RTL931xx. All problems were therefore detected with the patches from Jonas Jelonek [1] and not the vanilla Linux driver. But looking through the code, it seems like these are NOT regressions introduced by the RTL931x patchset. I've picked up Alex Guo's patch [2] to reduce conflicts between pending fixes. [1] https://patchwork.ozlabs.org/project/linux-i2c/cover/20250727114800.3046-1-… [2] https://lore.kernel.org/r/20250615235248.529019-1-alexguo1023@gmail.com Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- Changes in v4: - Provide only "write" examples for "i2c: rtl9300: Fix multi-byte I2C write" - drop the second initialization of vals in rtl9300_i2c_write() directly in the "Fix multi-byte I2C write" fix - indicate in target branch for each patch in PATCH prefix - minor commit message cleanups - Link to v3: https://lore.kernel.org/r/20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c… Changes in v3: - integrated patch https://lore.kernel.org/r/20250615235248.529019-1-alexguo1023@gmail.com to avoid conflicts in the I2C_SMBUS_BLOCK_DATA code - added Fixes and stable(a)vger.kernel.org to Alex Guo's patch - added Chris Packham's Reviewed-by/Acked-by - Link to v2: https://lore.kernel.org/r/20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6… Changes in v2: - add the missing transfer width and read length increase for the SMBus Write/Read - Link to v1: https://lore.kernel.org/r/20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2… --- Alex Guo (1): [i2c-host-fixes] i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer Harshal Gohel (2): [i2c-host-fixes] i2c: rtl9300: Fix multi-byte I2C write [i2c-host] i2c: rtl9300: Implement I2C block read and write Sven Eckelmann (2): [i2c-host-fixes] i2c: rtl9300: Increase timeout for transfer polling [i2c-host-fixes] i2c: rtl9300: Add missing count byte for SMBus Block Ops drivers/i2c/busses/i2c-rtl9300.c | 50 +++++++++++++++++++++++++++++++++------- 1 file changed, 42 insertions(+), 8 deletions(-) --- base-commit: 09eaa2a604ed1bfda7e6fb10488127ce8fdc8048 change-id: 20250802-i2c-rtl9300-multi-byte-edaa1fb0872c Best regards, -- Sven Eckelmann <sven(a)narfation.org>

6 days, 9 hours

2
5
0 0

Kernel warning on 5.15.187+ caused: net/sched: Always pass notifications when child class becomes empty

by Hauke Mehrtens

Hi, We see a kernel warning with kernel 5.15.187 and later in OpenWrt 23.05. When I revert this patch it is gone: commit e269f29e9395527bc00c213c6b15da04ebb35070 Author: Lion Ackermann <nnamrec(a)gmail.com> Date: Mon Jun 30 15:27:30 2025 +0200 net/sched: Always pass notifications when child class becomes empty [ Upstream commit 103406b38c600fec1fe375a77b27d87e314aea09 ] Link: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… Hauke Warning: [ 90.429594] ------------[ cut here ]------------ [ 90.429929] WARNING: CPU: 0 PID: 3667 at net/sched/sch_htb.c:609 0xffff800000d1b5dc [ 90.430561] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_compat nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack iptable_mangle iptable_filter ipt_REJECT ipt_ECN ip_tables xt_time xt_tcpudp xt_tcpmss xt_statistic xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY x_tables smsc slhc sfp sch_cake ravb nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mdio_i2c mdio_gpio mdio_bitbang libcrc32c e1000e atlantic sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact gpio_pca953x i2c_mux_pca954x i2c_mux i2c_dev [ 90.431030] sp805_wdt dwmac_sun8i dwmac_rk dwmac_imx nicvf nicpf thunder_bgx thunder_xcv dwmac_generic stmmac_platform stmmac rvu_nicvf rvu_nicpf rvu_af rvu_mbox mvpp2 mvneta vmxnet3 fec fsl_enetc fsl_enetc_mdio fsl_enetc_ierb fsl_dpaa2_eth ifb mdio_thunder mdio_cavium mdio_bcm_unimac xgmac_mdio pcs_lynx fsl_mc_dpio genet nls_utf8 nls_iso8859_1 nls_cp437 pcs_xpcs marvell10g marvell macsec sha512_generic seqiv jitterentropy_rng drbg hmac rtc_rx8025 vfat fat ptp realtek broadcom bcm_phy_lib aquantia hwmon crc_ccitt pps_core phylink mii [ 90.435728] CPU: 0 PID: 3667 Comm: tc Not tainted 5.15.189 #0 [ 90.436003] Hardware name: linux,dummy-virt (DT) [ 90.436306] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 90.436578] pc : 0xffff800000d1b5dc [ 90.436736] lr : qdisc_tree_reduce_backlog+0xa0/0x120 [ 90.436930] sp : ffff80000b73b6d0 [ 90.437053] x29: ffff80000b73b6d0 x28: ffff000003d81030 x27: ffff0000033bf800 [ 90.437335] x26: ffff0000033bf800 x25: ffff80000b73b8e0 x24: ffff000003677400 [ 90.437576] x23: ffff800000d1f5e0 x22: 0000000000000000 x21: 0000000000000000 [ 90.437816] x20: 0000000000000000 x19: ffff0000034f6800 x18: 0000000000000000 [ 90.438054] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffc7ffd278 [ 90.438299] x14: 000122a60001216d x13: 0001204400011f1c x12: 00011df300011cca [ 90.438548] x11: 00011b9100011a68 x10: 0001194000011817 x9 : 0000000000000000 [ 90.438794] x8 : ffff000003677e00 x7 : 0000000000000000 x6 : 0000000000000000 [ 90.439037] x5 : ffff0000029df000 x4 : 0000000000000003 x3 : ffff000003684000 [ 90.439277] x2 : ffff800000d1b5a0 x1 : 0000000000000000 x0 : ffff000003c64140 [ 90.439629] Call trace: [ 90.439859] 0xffff800000d1b5dc [ 90.440021] qdisc_tree_reduce_backlog+0xa0/0x120 [ 90.440184] 0xffff800000d1dd8c [ 90.440302] tc_ctl_tclass+0x15c/0x460 [ 90.440440] rtnetlink_rcv_msg+0x1b8/0x320 [ 90.440583] netlink_rcv_skb+0x5c/0x130 [ 90.440715] rtnetlink_rcv+0x18/0x2c [ 90.440841] netlink_unicast+0x214/0x310 [ 90.440975] netlink_sendmsg+0x1a0/0x3dc [ 90.441120] ____sys_sendmsg+0x1b8/0x220 [ 90.441257] ___sys_sendmsg+0x84/0xf0 [ 90.441385] __sys_sendmsg+0x48/0xb0 [ 90.441509] __arm64_sys_sendmsg+0x24/0x30 [ 90.441647] invoke_syscall.constprop.0+0x5c/0x110 [ 90.441811] do_el0_svc+0x6c/0x150 [ 90.441929] el0_svc+0x28/0xc0 [ 90.442039] el0t_64_sync_handler+0xe8/0x114 [ 90.442186] el0t_64_sync+0x1a4/0x1a8 [ 90.442408] ---[ end trace b27ff72c6be40920 ]---

6 days, 9 hours

4
4
0 0

[PATCH 1/3] KEYS: trusted_tpm1: Compare HMAC values in constant time

by Eric Biggers

To prevent timing attacks, HMAC value comparison needs to be constant time. Replace the memcmp() with the correct function, crypto_memneq(). Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- security/keys/trusted-keys/trusted_tpm1.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c index 89c9798d18007..e73f2c6c817a0 100644 --- a/security/keys/trusted-keys/trusted_tpm1.c +++ b/security/keys/trusted-keys/trusted_tpm1.c @@ -5,10 +5,11 @@ * * See Documentation/security/keys/trusted-encrypted.rst */ #include <crypto/hash_info.h> +#include <crypto/utils.h> #include <linux/init.h> #include <linux/slab.h> #include <linux/parser.h> #include <linux/string.h> #include <linux/err.h> @@ -239,11 +240,11 @@ int TSS_checkhmac1(unsigned char *buffer, TPM_NONCE_SIZE, enonce, TPM_NONCE_SIZE, ononce, 1, continueflag, 0, 0); if (ret < 0) goto out; - if (memcmp(testhmac, authdata, SHA1_DIGEST_SIZE)) + if (crypto_memneq(testhmac, authdata, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: kfree_sensitive(sdesc); return ret; } @@ -332,20 +333,20 @@ static int TSS_checkhmac2(unsigned char *buffer, ret = TSS_rawhmac(testhmac1, key1, keylen1, SHA1_DIGEST_SIZE, paramdigest, TPM_NONCE_SIZE, enonce1, TPM_NONCE_SIZE, ononce, 1, continueflag1, 0, 0); if (ret < 0) goto out; - if (memcmp(testhmac1, authdata1, SHA1_DIGEST_SIZE)) { + if (crypto_memneq(testhmac1, authdata1, SHA1_DIGEST_SIZE)) { ret = -EINVAL; goto out; } ret = TSS_rawhmac(testhmac2, key2, keylen2, SHA1_DIGEST_SIZE, paramdigest, TPM_NONCE_SIZE, enonce2, TPM_NONCE_SIZE, ononce, 1, continueflag2, 0, 0); if (ret < 0) goto out; - if (memcmp(testhmac2, authdata2, SHA1_DIGEST_SIZE)) + if (crypto_memneq(testhmac2, authdata2, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: kfree_sensitive(sdesc); return ret; } base-commit: d6084bb815c453de27af8071a23163a711586a6c -- 2.50.1

6 days, 9 hours

2
4
0 0

Qualcomm Inventory Updated

by Alan Ye

The following are all Qualcomm's stock, original and authentic. If you need them, please contact us. Snapdragon骁龙 WIFI-5G/6G MPN QTY date code MPN QTY date code SM-6225-0-PSP807-TR-00-0-AB 8000 22+ IPQ5018-0-MRQFN232-MT-01-0 36000 22+ PM-6225-0-FOWNSP144-TR-01-0 8000 22+ QCN6102-0-DRQFN116-TR-01-0 30000 22+ WCD9375-0-WLPSP55-TR-01-3 8000 22+ QCA8337-AL3C 25000 22+ WTR3925-2-106BWLPSP-TR-03-1 8000 22+ WCN-3950-0-58WLPSP-TR-05-2 8000 22+ IPQ-6000-0-FCBGA570-TR-00-0 10000 22+ QCA-8072-0-108DRQFN-MT-00-0 10000 22+ QCM-6490-1-PSP1287-TR-00-0-AA E 12000 23+ QCN-5022-0-DRQFN100B-TR-00-0 10000 22+ PMK-7325-1-1-FOWPSP36-MT-01-0 12000 23+ QCN-5052-0-DRQFN100B-TR-00-0 10000 22+ PM-7325-0-WLNSP120B-TR-00-0 12000 23+ PM-7350C-0-FOWNSP143-MT-02-0 12000 23+ IPQ-6010-0-FCBGA570-TR-00-0 8000 22+ PM-7250B-2-FOWPSP110-TR-00-0 12000 23+ QCA-8075-0-108DRQFN-MT-01-0 8000 22+ WCD-9370-0-WLPSP55-TR-01-0 12000 23+ QCN-5052-0-DRQFN100B-TR-00-0 8000 22+ PM-8008-0-WLPSP20-TR-X0-0 12000 23+ QCN-5021-0-DRQFN100B-TR-03-0 8000 22+ SDR-735-0-PSP219B-TR-001-0 12000 23+ WCN-6750-0-PSP229-TR-01-0 12000 23+ QCA-9886-0-100DRQFN-MT-04-0 14000 22+ QCA9563-AL3A 14000 22+ SDM-450-B-792NSP-TR-01-0-AA 20000 24+ QCA8334-AL3C 14000 22+ WTR-2965-0-59F0WNSP-TR-07-1 20000 24+ PMI-8952-0-144WLNSP-TR-02-0-00 20000 24+ IPQ-5322-0-MRQFN251-MT-00-0 6000 24+ WCN-3680B-0-79BWLNSP-TR-05-1 20000 24+ QCN-6274-0-MSP264-MT-01-0 6000 24+ PM-8953-0-187F0WNSP-TR-01-1 20000 24+ QCA-8385-0-DRQFN172-MT-00-0 6000 24 SDM-660-3-692NSP-TR-01-0-A 28000 23+ IPQ-4018-0-180DRQFN-MT-00-0 150000 22+ PM-660-0-219WLPSP-TR-01-1-01 28000 23+ QCA-8072-0-108DRQFN-MT-00-0 100000 22+ PM-660L-0-196WLPSP-TR-04-0-01 28000 23+ SDR-660-0-180WLPSP-TR-03-0 28000 23+ QCN-9024-0-MSP234-TR-01-0 5000 23+ QET-4101-0-12WLNSP-HR-00-0 28000 23+ QCN-6024-0-MSP234-MT-01-0 20000 22+ WCN-3980-0-82BWLPSP-TR-0B-0 28000 23+ QCA-8081-0-56MQFN-MT-02-0 28000 22+ QCN-9074-0-MSP234-TR-01-0 8000 23+ QCM-2290-0-NSP752-TR-00-0 10000 24+ QCA-9377-3-115WLNSP-TR-03-0 10000 22+ PM-8008-0-WLPSP20-TR-X0-0 10000 24+ QCA-1023-0-115WLNSP-TR-03-0 20000 24+ WCN-3950-0-58WLPSP-TR-05-3 10000 24+ QCC-5181-0-WLNSP99-TR-05-0 10000 24+ PM-4125-3-NSP194-TR-01-0 10000 24+ QCC-5127-0-124CSP-TR-00-0 8000 23+ CSR8670C-ICXT-R 10000 23+ MSM-8909-2-504NSP-TR-01-1-AA 50000 22+ CSR8675C-IBBH-R 10000 23+ WCN-3660B-0-79BWLNSP-TR-05-1 50000 22+ AR8033-AL1A 25000 23+ PM-8909-0-152NSP-TR-01-0-02 50000 22+ AR8035-AL1A 45000 22+ WTR-4905-1-60WLNSP-TR-01-1 50000 22+ AR8031-AL1B 15000 22+ If you have other MPN requirements, please let me know and I will check the latest inventory status for you. We also recycle Qualcomm's excess inventory to help you solve the depreciation risk faced by electronic components Best Secure your updates and feature insights at . Continue Product News Wish to step back? Quickly hit Control Contact Settings.

1 week

1
0
0 0

+ kho-warn-if-kho-is-disabled-due-to-an-error.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kho: warn if KHO is disabled due to an error has been added to the -mm mm-hotfixes-unstable branch. Its filename is kho-warn-if-kho-is-disabled-due-to-an-error.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Pasha Tatashin <pasha.tatashin(a)soleen.com> Subject: kho: warn if KHO is disabled due to an error Date: Fri, 8 Aug 2025 20:18:04 +0000 During boot scratch area is allocated based on command line parameters or auto calculated. However, scratch area may fail to allocate, and in that case KHO is disabled. Currently, no warning is printed that KHO is disabled, which makes it confusing for the end user to figure out why KHO is not available. Add the missing warning message. Link: https://lkml.kernel.org/r/20250808201804.772010-4-pasha.tatashin@soleen.com Signed-off-by: Pasha Tatashin <pasha.tatashin(a)soleen.com> Acked-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Acked-by: Pratyush Yadav <pratyush(a)kernel.org> Cc: Alexander Graf <graf(a)amazon.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Baoquan He <bhe(a)redhat.com> Cc: Changyuan Lyu <changyuanl(a)google.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: Dave Vasilevsky <dave(a)vasilevsky.ca> Cc: Eric Biggers <ebiggers(a)google.com> Cc: Kees Cook <kees(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/kexec_handover.c | 1 + 1 file changed, 1 insertion(+) --- a/kernel/kexec_handover.c~kho-warn-if-kho-is-disabled-due-to-an-error +++ a/kernel/kexec_handover.c @@ -564,6 +564,7 @@ err_free_scratch_areas: err_free_scratch_desc: memblock_free(kho_scratch, kho_scratch_cnt * sizeof(*kho_scratch)); err_disable_kho: + pr_warn("Failed to reserve scratch area, disabling kexec handover\n"); kho_enable = false; } _ Patches currently in -mm which might be from pasha.tatashin(a)soleen.com are kho-init-new_physxa-phys_bits-to-fix-lockdep.patch kho-mm-dont-allow-deferred-struct-page-with-kho.patch kho-warn-if-kho-is-disabled-due-to-an-error.patch

1 week

1
0
0 0

+ kho-mm-dont-allow-deferred-struct-page-with-kho.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kho: mm: don't allow deferred struct page with KHO has been added to the -mm mm-hotfixes-unstable branch. Its filename is kho-mm-dont-allow-deferred-struct-page-with-kho.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Pasha Tatashin <pasha.tatashin(a)soleen.com> Subject: kho: mm: don't allow deferred struct page with KHO Date: Fri, 8 Aug 2025 20:18:03 +0000 KHO uses struct pages for the preserved memory early in boot, however, with deferred struct page initialization, only a small portion of memory has properly initialized struct pages. This problem was detected where vmemmap is poisoned, and illegal flag combinations are detected. Don't allow them to be enabled together, and later we will have to teach KHO to work properly with deferred struct page init kernel feature. Link: https://lkml.kernel.org/r/20250808201804.772010-3-pasha.tatashin@soleen.com Fixes: 990a950fe8fd ("kexec: add config option for KHO") Signed-off-by: Pasha Tatashin <pasha.tatashin(a)soleen.com> Acked-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Acked-by: Pratyush Yadav <pratyush(a)kernel.org> Cc: Alexander Graf <graf(a)amazon.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Baoquan He <bhe(a)redhat.com> Cc: Changyuan Lyu <changyuanl(a)google.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: Dave Vasilevsky <dave(a)vasilevsky.ca> Cc: Eric Biggers <ebiggers(a)google.com> Cc: Kees Cook <kees(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/Kconfig.kexec | 1 + 1 file changed, 1 insertion(+) --- a/kernel/Kconfig.kexec~kho-mm-dont-allow-deferred-struct-page-with-kho +++ a/kernel/Kconfig.kexec @@ -97,6 +97,7 @@ config KEXEC_JUMP config KEXEC_HANDOVER bool "kexec handover" depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KEXEC_FILE + depends on !DEFERRED_STRUCT_PAGE_INIT select MEMBLOCK_KHO_SCRATCH select KEXEC_FILE select DEBUG_FS _ Patches currently in -mm which might be from pasha.tatashin(a)soleen.com are kho-init-new_physxa-phys_bits-to-fix-lockdep.patch kho-mm-dont-allow-deferred-struct-page-with-kho.patch kho-warn-if-kho-is-disabled-due-to-an-error.patch

1 week

1
0
0 0

+ kho-init-new_physxa-phys_bits-to-fix-lockdep.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kho: init new_physxa->phys_bits to fix lockdep has been added to the -mm mm-hotfixes-unstable branch. Its filename is kho-init-new_physxa-phys_bits-to-fix-lockdep.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Pasha Tatashin <pasha.tatashin(a)soleen.com> Subject: kho: init new_physxa->phys_bits to fix lockdep Date: Fri, 8 Aug 2025 20:18:02 +0000 Patch series "Several KHO Hotfixes". Three unrelated fixes for Kexec Handover. This patch (of 3): Lockdep shows the following warning: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. [<ffffffff810133a6>] dump_stack_lvl+0x66/0xa0 [<ffffffff8136012c>] assign_lock_key+0x10c/0x120 [<ffffffff81358bb4>] register_lock_class+0xf4/0x2f0 [<ffffffff813597ff>] __lock_acquire+0x7f/0x2c40 [<ffffffff81360cb0>] ? __pfx_hlock_conflict+0x10/0x10 [<ffffffff811707be>] ? native_flush_tlb_global+0x8e/0xa0 [<ffffffff8117096e>] ? __flush_tlb_all+0x4e/0xa0 [<ffffffff81172fc2>] ? __kernel_map_pages+0x112/0x140 [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0 [<ffffffff81359556>] lock_acquire+0xe6/0x280 [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0 [<ffffffff8100b9e0>] _raw_spin_lock+0x30/0x40 [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0 [<ffffffff813ec327>] xa_load_or_alloc+0x67/0xe0 [<ffffffff813eb4c0>] kho_preserve_folio+0x90/0x100 [<ffffffff813ebb7f>] __kho_finalize+0xcf/0x400 [<ffffffff813ebef4>] kho_finalize+0x34/0x70 This is becase xa has its own lock, that is not initialized in xa_load_or_alloc. Modifiy __kho_preserve_order(), to properly call xa_init(&new_physxa->phys_bits); Link: https://lkml.kernel.org/r/20250808201804.772010-2-pasha.tatashin@soleen.com Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation") Signed-off-by: Pasha Tatashin <pasha.tatashin(a)soleen.com> Acked-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Cc: Alexander Graf <graf(a)amazon.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Baoquan He <bhe(a)redhat.com> Cc: Changyuan Lyu <changyuanl(a)google.com> Cc: Coiby Xu <coxu(a)redhat.com> Cc: Dave Vasilevsky <dave(a)vasilevsky.ca> Cc: Eric Biggers <ebiggers(a)google.com> Cc: Kees Cook <kees(a)kernel.org> Cc: Pratyush Yadav <pratyush(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/kexec_handover.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) --- a/kernel/kexec_handover.c~kho-init-new_physxa-phys_bits-to-fix-lockdep +++ a/kernel/kexec_handover.c @@ -144,14 +144,34 @@ static int __kho_preserve_order(struct k unsigned int order) { struct kho_mem_phys_bits *bits; - struct kho_mem_phys *physxa; + struct kho_mem_phys *physxa, *new_physxa; const unsigned long pfn_high = pfn >> order; might_sleep(); - physxa = xa_load_or_alloc(&track->orders, order, sizeof(*physxa)); - if (IS_ERR(physxa)) - return PTR_ERR(physxa); + physxa = xa_load(&track->orders, order); + if (!physxa) { + int err; + + new_physxa = kzalloc(sizeof(*physxa), GFP_KERNEL); + if (!new_physxa) + return -ENOMEM; + + xa_init(&new_physxa->phys_bits); + physxa = xa_cmpxchg(&track->orders, order, NULL, new_physxa, + GFP_KERNEL); + + err = xa_err(physxa); + if (err || physxa) { + xa_destroy(&new_physxa->phys_bits); + kfree(new_physxa); + + if (err) + return err; + } else { + physxa = new_physxa; + } + } bits = xa_load_or_alloc(&physxa->phys_bits, pfn_high / PRESERVE_BITS, sizeof(*bits)); _ Patches currently in -mm which might be from pasha.tatashin(a)soleen.com are kho-init-new_physxa-phys_bits-to-fix-lockdep.patch kho-mm-dont-allow-deferred-struct-page-with-kho.patch kho-warn-if-kho-is-disabled-due-to-an-error.patch

1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025