6.16.6-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 133/183 nouveau: Membar before between semaphore writes and the interrupt
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Faith Ekstrand <[email protected]>
commit 2cb66ae6040fd3cb058c3391b180f378fc0e3e2f upstream.
This ensures that the memory write and the interrupt are properly ordered and we won't wake up the kernel before the semaphore write has hit memory.
--- drivers/gpu/drm/nouveau/gv100_fence.c | 7 +- .../drm/nouveau/include/nvhw/class/clc36f.h | 85 +++++++++++++++++++ 2 files changed, 91 insertions(+), 1 deletion(-)
drivers/gpu/drm/nouveau/gv100_fence.c +6 -1
@@ -18,7 +18,7 @@ gv100_fence_emit32(struct nouveau_channel *chan, u64 virtual, u32 sequence)struct nvif_push *push = &chan->chan.push;int ret; - ret =PUSH_WAIT (push,8 ); + ret =PUSH_WAIT (push,13 );if (ret)return ret;
@@ -32,6 +32,11 @@ gv100_fence_emit32(struct nouveau_channel *chan, u64 virtual, u32 sequence) NVDEF(NVC36F, SEM_EXECUTE, PAYLOAD_SIZE, 32BIT) | NVDEF(NVC36F, SEM_EXECUTE, RELEASE_TIMESTAMP, DIS)); +PUSH_MTHD (push,NVC36F ,MEM_OP_A ,0 , +MEM_OP_B ,0 , +MEM_OP_C ,NVDEF (NVC36F ,MEM_OP_C ,MEMBAR_TYPE ,SYS_MEMBAR ), +MEM_OP_D ,NVDEF (NVC36F ,MEM_OP_D ,OPERATION ,MEMBAR )); +PUSH_MTHD (push,NVC36F ,NON_STALL_INTERRUPT ,0 );PUSH_KICK (push);
drivers/gpu/drm/nouveau/include/nvhw/class/clc36f.h +85 -0
91 lines not on this page · raw message
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 134/183 audit: fix out-of-bounds read in audit_compare_dname_path()
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislav Fort <[email protected]>
commit 4540f1d23e7f387880ce46d11b5cd3f27248bf8d upstream.
When a watch on dir=/ is combined with an fsnotify event for a single-character name directly under / (e.g., creating /a), an out-of-bounds read can occur in audit_compare_dname_path().
The helper parent_len() returns 1 for "/". In audit_compare_dname_path(), when parentlen equals the full path length (1), the code sets p = path + 1 and pathlen = 1 - 1 = 0. The subsequent loop then dereferences p[pathlen - 1] (i.e., p[-1]), causing an out-of-bounds read.
Fix this by adding a pathlen > 0 check to the while loop condition to prevent the out-of-bounds access.
--- kernel/auditfilter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/auditfilter.c +1 -1
@@ -1326,7 +1326,7 @@ int audit_compare_dname_path(const struc/* handle trailing slashes */ pathlen -= parentlen; -while (p[pathlen -1 ] =='/' ) +while (pathlen >0 && p[pathlen -1 ] =='/' ) pathlen--;if (pathlen != dlen)
Greg Kroah-Hartman
maintainerPATCH 135/183 batman-adv: fix OOB read/write in network-coding decode
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislav Fort <[email protected]>
commit d77b6ff0ce35a6d0b0b7b9581bc3f76d041d4087 upstream.
batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write.
Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.
--- net/batman-adv/network-coding.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
net/batman-adv/network-coding.c +6 -1
@@ -1687,7 +1687,12 @@ batadv_nc_skb_decode_packet(struct batad coding_len =ntohs (coded_packet_tmp.coded_len); -if (coding_len > skb->len) +/* ensure dst buffer is large enough (payload only) */ +if (coding_len + h_size > skb->len) +return NULL ; + +/* ensure src buffer is large enough (payload only) */ +if (coding_len + h_size > nc_packet->skb->len)return NULL ;/* Here the magic is reversed:
Greg Kroah-Hartman
maintainerPATCH 136/183 cifs: prevent NULL pointer dereference in UTF16 conversion
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Makar Semyonov <[email protected]>
commit 70bccd9855dae56942f2b18a08ba137bb54093a0 upstream.
There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.
This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer.
Found by Linux Verification Center (linuxtesting.org) with SVACE
--- fs/smb/client/cifs_unicode.c | 3 +++ 1 file changed, 3 insertions(+)
fs/smb/client/cifs_unicode.c +3 -0
@@ -629,6 +629,9 @@ cifs_strndup_to_utf16(const char *src, cint len;__le16 *dst; +if (!src) +return NULL ; + len =cifs_local_to_utf16_bytes (src, maxlen, cp); len +=2 ;/* NULL */ dst =kmalloc (len,GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 137/183 e1000e: fix heap overflow in e1000_set_eeprom
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vitaly Lifshits <[email protected]>
commit 90fb7db49c6dbac961c6b8ebfd741141ffbc8545 upstream.
Fix a possible heap overflow in e1000_set_eeprom function by adding input validation for the requested length of the change in the EEPROM. In addition, change the variable type from int to size_t for better code practices and rearrange declarations to RCT.
--- drivers/net/ethernet/intel/e1000e/ethtool.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/net/ethernet/intel/e1000e/ethtool.c +7 -3
@@ -549,12 +549,12 @@ static int e1000_set_eeprom(struct net_d {struct e1000_adapter *adapter =netdev_priv (netdev);struct e1000_hw *hw = &adapter->hw; +size_t total_len, max_len;u16 *eeprom_buff; -void *ptr; -int max_len; +int ret_val =0 ;int first_word;int last_word; -int ret_val =0 ; +void *ptr;u16 i;if (eeprom->len ==0 )
@@ -569,6 +569,10 @@ static int e1000_set_eeprom(struct net_d max_len = hw->nvm.word_size *2 ; +if (check_add_overflow (eeprom->offset, eeprom->len, &total_len) || + total_len > max_len) +return -EFBIG ; + first_word = eeprom->offset >>1 ; last_word = (eeprom->offset + eeprom->len -1 ) >>1 ; eeprom_buff =kmalloc (max_len,GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 138/183 net: dsa: mv88e6xxx: Fix fwnode reference leaks in mv88e6xxx_port_setup_leds
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaoqian Lin <[email protected]>
commit f63e7c8a83892781f6ceb55566f9497639c44555 upstream.
Fix multiple fwnode reference leaks:
1. The function calls fwnode_get_named_child_node() to get the "leds" node, but never calls fwnode_handle_put(leds) to release this reference.
2. Within the fwnode_for_each_child_node() loop, the early return paths that don't properly release the "led" fwnode reference.
This fix follows the same pattern as commit d029edefed39 ("net dsa: qca8k: fix usages of device_get_named_child_node()")
--- drivers/net/dsa/mv88e6xxx/leds.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
drivers/net/dsa/mv88e6xxx/leds.c +13 -4
@@ -779,7 +779,8 @@ int mv88e6xxx_port_setup_leds(struct mv8continue ;if (led_num >1 ) {dev_err (dev,"invalid LED specified port %d\n" , port); -return -EINVAL ; + ret = -EINVAL ; + goto err_put_led; }if (led_num ==0 )
@@ -823,17 +824,25 @@ int mv88e6xxx_port_setup_leds(struct mv8 init_data.devname_mandatory = true; init_data.devicename =kasprintf (GFP_KERNEL ,"%s:0%d:0%d" , chip->info->name, port, led_num); -if (!init_data.devicename) -return -ENOMEM ; +if (!init_data.devicename) { + ret = -ENOMEM ; + goto err_put_led; + } ret =devm_led_classdev_register_ext (dev, l, &init_data);kfree (init_data.devicename);if (ret) {dev_err (dev,"Failed to init LED %d for port %d" , led_num, port); -return ret; + goto err_put_led; } } +fwnode_handle_put (leds);return 0 ; + +err_put_led: +fwnode_handle_put (led); +fwnode_handle_put (leds); +return ret; }
Greg Kroah-Hartman
maintainerPATCH 139/183 net: pcs: rzn1-miic: Correct MODCTRL register offset
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lad Prabhakar <[email protected]>
commit a7195a3d67dace056af7ca65144a11874df79562 upstream.
Correct the Mode Control Register (MODCTRL) offset for RZ/N MIIC. According to the R-IN Engine and Ethernet Peripherals Manual (Rev.1.30) [0], Table 10.1 "Ethernet Accessory Register List", MODCTRL is at offset 0x8, not 0x20 as previously defined.
Offset 0x20 actually maps to the Port Trigger Control Register (PTCTRL), which controls PTP_MODE[3:0] and RGMII_CLKSEL[4]. Using this incorrect definition prevented the driver from configuring the SW_MODE[4:0] bits in MODCTRL, which control the internal connection of Ethernet ports. As a result, the MIIC could not be switched into the correct mode, leading to link setup failures and non-functional Ethernet ports on affected systems.
--- drivers/net/pcs/pcs-rzn1-miic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/pcs/pcs-rzn1-miic.c +1 -1
@@ -19,7 +19,7 @@#define MIIC_PRCMD 0x0#define MIIC_ESID_CODE 0x4 -#define MIIC_MODCTRL 0x20 +#define MIIC_MODCTRL 0x8#define MIIC_MODCTRL_SW_MODE GENMASK(4, 0)#define MIIC_CONVCTRL (port) (0x100 + (port) * 4)
Greg Kroah-Hartman
maintainerPATCH 140/183 microchip: lan865x: Fix module autoloading
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Wahren <[email protected]>
commit c7217963eb779be0a7627dd2121152fa6786ecf7 upstream.
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from spi_device_id table. While at this, fix the misleading variable name (spidev is unrelated to this driver).
--- drivers/net/ethernet/microchip/lan865x/lan865x.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/ethernet/microchip/lan865x/lan865x.c +3 -2
@@ -423,10 +423,11 @@ static void lan865x_remove(struct spi_defree_netdev (priv->netdev); } -static const struct spi_device_id spidev_spi_ids[] = { +static const struct spi_device_id lan865x_ids[] = { { .name ="lan8650" }, {}, }; +MODULE_DEVICE_TABLE (spi, lan865x_ids);static const struct of_device_id lan865x_dt_ids[] = { { .compatible ="microchip,lan8650" },
@@ -441,7 +442,7 @@ static struct spi_driver lan865x_driver }, .probe = lan865x_probe, .remove = lan865x_remove, - .id_table = spidev_spi_ids, + .id_table = lan865x_ids, };module_spi_driver (lan865x_driver);
Greg Kroah-Hartman
maintainerPATCH 141/183 microchip: lan865x: Fix LAN8651 autoloading
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Wahren <[email protected]>
commit ca47c44d36a9ad3268d17f89789104a471c07f81 upstream.
Add missing IDs for LAN8651 devices, which are also defined in the DT bindings.
--- drivers/net/ethernet/microchip/lan865x/lan865x.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/microchip/lan865x/lan865x.c +2 -0
@@ -425,12 +425,14 @@ static void lan865x_remove(struct spi_destatic const struct spi_device_id lan865x_ids[] = { { .name ="lan8650" }, + { .name ="lan8651" }, {}, };MODULE_DEVICE_TABLE (spi, lan865x_ids);static const struct of_device_id lan865x_dt_ids[] = { { .compatible ="microchip,lan8650" }, + { .compatible ="microchip,lan8651" }, {/* Sentinel */ } };MODULE_DEVICE_TABLE (of, lan865x_dt_ids);
Greg Kroah-Hartman
maintainerPATCH 142/183 drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Imre Deak <[email protected]>
commit d34d6feaf4a76833effcec0b148b65946b04cde8 upstream.
Commit a3ef3c2da675 ("drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") stopped using the DPCD_REV register for DPCD probing, since this results in link training failures at least when using an Intel Barlow Ridge TBT hub at UHBR link rates (the DP_INTRA_HOP_AUX_REPLY_INDICATION never getting cleared after the failed link training). Since accessing DPCD_REV during link training is prohibited by the DP Standard, LANE0_1_STATUS (0x202) was used instead, as it falls within the Standard's valid register address range (0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) and it fixed the link training on the above TBT hub.
However, reading the LANE0_1_STATUS register also has a side-effect at least on a Novatek eDP panel, as reported on the Closes: link below, resulting in screen flickering on that panel. One clear side-effect when doing the 1-byte probe reads from LANE0_1_STATUS during link training before reading out the full 6 byte link status starting at the same address is that the panel will report the link training as completed with voltage swing 0. This is different from the normal, flicker-free scenario when no DPCD probing is done, the panel reporting the link training complete with voltage swing 2.
Using the TRAINING_PATTERN_SET register for DPCD probing doesn't have the above side-effect, the panel will link train with voltage swing 2 as expected and it will stay flicker-free. This register is also in the above valid register range and is unlikely to have a side-effect as that of LANE0_1_STATUS: Reading LANE0_1_STATUS is part of the link training CR/EQ sequences and so it may cause a state change in the sink - even if inadvertently as I suspect in the case of the above Novatek panel. As opposed to this, reading TRAINING_PATTERN_SET is not part of the link training sequence (it must be only written once at the beginning of the CR/EQ sequences), so it's unlikely to cause any state change in the sink.
As a side-note, this Novatek panel also lacks support for TPS3, while claiming support for HBR2, which violates the DP Standard (the Standard mandating TPS3 for HBR2).
Besides the Novatek panel (PSR 1), which this change fixes, I also verified the change on a Samsung (PSR 1) and an Analogix (PSR 2) eDP panel as well as on the Intel Barlow Ridge TBT hub.
Note that in the drm-tip tree (targeting the v6.17 kernel version) the i915 and xe drivers keep DPCD probing enabled only for the panel known to require this (HP ZR24w), hence those drivers in drm-tip are not affected by the above problem.
--- drivers/gpu/drm/display/drm_dp_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/display/drm_dp_helper.c +1 -1
@@ -725,7 +725,7 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_a* monitor doesn't power down exactly after the throw away read. */ if (!aux->is_remote) { - ret =drm_dp_dpcd_probe (aux,DP_DPCD_REV ); + ret =drm_dp_dpcd_probe (aux,DP_TRAINING_PATTERN_SET );if (ret <0 )return ret; }
Greg Kroah-Hartman
maintainerPATCH 143/183 rust: support Rust >= 1.91.0 target spec
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miguel Ojeda <[email protected]>
commit 8851e27d2cb947ea8bbbe8e812068f7bf5cbd00b upstream.
Starting with Rust 1.91.0 (expected 2025-10-30), the target spec format has changed the type of the target-pointer-width key from string to integer [1].
Thus conditionally use one or the other depending on the version.
--- scripts/generate_rust_target.rs | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
scripts/generate_rust_target.rs +10 -2
@@ -225,7 +225,11 @@ fn main() { ts.push ("features" , features); ts.push ("llvm-target" ,"x86_64-linux-gnu" ); ts.push ("supported-sanitizers" , ["kcfi" ,"kernel-address" ]); - ts.push ("target-pointer-width" ,"64" ); +if cfg.rustc_version_atleast (1 ,91 ,0 ) { + ts.push ("target-pointer-width" ,64 ); + }else { + ts.push ("target-pointer-width" ,"64" ); + } }else if cfg.has ("X86_32" ) {// This only works on UML, as i386 otherwise needs regparm support in rustc if !cfg.has ("UML" ) {
@@ -245,7 +249,11 @@ fn main() { } ts.push ("features" , features); ts.push ("llvm-target" ,"i386-unknown-linux-gnu" ); - ts.push ("target-pointer-width" ,"32" ); +if cfg.rustc_version_atleast (1 ,91 ,0 ) { + ts.push ("target-pointer-width" ,32 ); + }else { + ts.push ("target-pointer-width" ,"32" ); + } }else if cfg.has ("LOONGARCH" ) {panic! ("loongarch uses the builtin rustc loongarch64-unknown-none-softfloat target" ); }else {
Greg Kroah-Hartman
maintainerPATCH 144/183 ALSA: hda/hdmi: Add pin fix for another HP EliteDesk 800 G4 model
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit bcd6659d4911c528381531472a0cefbd4003e29e upstream.
It was reported that HP EliteDesk 800 G4 DM 65W (SSID 103c:845a) needs the similar quirk for enabling HDMI outputs, too. This patch adds the corresponding quirk entry.
--- sound/pci/hda/patch_hdmi.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_hdmi.c +1 -0
@@ -1991,6 +1991,7 @@ static int hdmi_add_cvt(struct hda_codecstatic const struct snd_pci_quirk force_connect_list[] = {SND_PCI_QUIRK (0x103c ,0x83e2 ,"HP EliteDesk 800 G4" ,1 ),SND_PCI_QUIRK (0x103c ,0x83ef ,"HP MP9 G4 Retail System AMS" ,1 ), +SND_PCI_QUIRK (0x103c ,0x845a ,"HP EliteDesk 800 G4 DM 65W" ,1 ),SND_PCI_QUIRK (0x103c ,0x870f ,"HP" ,1 ),SND_PCI_QUIRK (0x103c ,0x871a ,"HP" ,1 ),SND_PCI_QUIRK (0x103c ,0x8711 ,"HP" ,1 ),
Greg Kroah-Hartman
maintainerPATCH 145/183 ALSA: hda/realtek: Fix headset mic for TongFang X6[AF]R5xxY
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aaron Erhardt <[email protected]>
commit 051b02b17a8b383ee033db211f90f24b91ac7006 upstream.
Add a PCI quirk to enable microphone detection on the headphone jack of TongFang X6AR5xxY and X6FR5xxY devices.
--- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+)
sound/pci/hda/patch_realtek.c +2 -0
@@ -11427,6 +11427,8 @@ static const struct hda_quirk alc269_fixSND_PCI_QUIRK (0x1d05 ,0x121b ,"TongFang GMxAGxx" ,ALC269_FIXUP_NO_SHUTUP ),SND_PCI_QUIRK (0x1d05 ,0x1387 ,"TongFang GMxIXxx" ,ALC2XX_FIXUP_HEADSET_MIC ),SND_PCI_QUIRK (0x1d05 ,0x1409 ,"TongFang GMxIXxx" ,ALC2XX_FIXUP_HEADSET_MIC ), +SND_PCI_QUIRK (0x1d05 ,0x300f ,"TongFang X6AR5xxY" ,ALC2XX_FIXUP_HEADSET_MIC ), +SND_PCI_QUIRK (0x1d05 ,0x3019 ,"TongFang X6FR5xxY" ,ALC2XX_FIXUP_HEADSET_MIC ),SND_PCI_QUIRK (0x1d17 ,0x3288 ,"Haier Boyue G42" ,ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS ),SND_PCI_QUIRK (0x1d72 ,0x1602 ,"RedmiBook" ,ALC255_FIXUP_XIAOMI_HEADSET_MIC ), SND_PCI_QUIRK(0x1d72, 0x1701, "XiaomiNotebook Pro", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE),
Greg Kroah-Hartman
maintainerPATCH 146/183 ALSA: hda: tas2781: fix tas2563 EFI data endianness
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gergo Koteles <[email protected]>
commit e5a00dafc7e06ab1b20fd4c1535cfa9b9940061e upstream.
Before conversion to unify the calibration data management, the tas2563_apply_calib() function performed the big endian conversion and wrote the calibration data to the device. The writing is now done by the common tasdev_load_calibrated_data() function, but without conversion.
Put the values into the calibration data buffer with the expected endianness.
--- sound/pci/hda/tas2781_hda_i2c.c | 3 +++ 1 file changed, 3 insertions(+)
sound/pci/hda/tas2781_hda_i2c.c +3 -0
@@ -292,6 +292,7 @@ static int tas2563_save_calibration(strustruct cali_reg *r = &cd->cali_reg_array;unsigned int offset =0 ;unsigned char *data; +__be32 bedata;efi_status_t status;unsigned int attr;int ret, i, j, k;
@@ -333,6 +334,8 @@ static int tas2563_save_calibration(stru i, j, status);return -EINVAL ; } + bedata =cpu_to_be32 (*(uint32_t *)&data[offset]); +memcpy (&data[offset], &bedata,sizeof (bedata)); offset +=TAS2563_CAL_DATA_SIZE ; } }
Greg Kroah-Hartman
maintainerPATCH 147/183 ALSA: hda: tas2781: reorder tas2563 calibration variables
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gergo Koteles <[email protected]>
commit d5f8458e34a331e5b228de142145e62ac5bfda34 upstream.
The tasdev_load_calibrated_data() function expects the calibration data values in the cali_data buffer as R0, R0Low, InvR0, Power, TLim which is not the same as what tas2563_save_calibration() writes to the buffer.
Reorder the EFI variables in the tas2563_save_calibration() function to put the values in the buffer in the correct order.
--- sound/pci/hda/tas2781_hda_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/pci/hda/tas2781_hda_i2c.c +1 -1
@@ -282,7 +282,7 @@ static int tas2563_save_calibration(stru {efi_guid_t efi_guid = tasdev_fct_efi_guid[LENOVO ];char *vars[TASDEV_CALIB_N ] = { -"R0_%d" ,"InvR0_%d" ,"R0_Low_%d" ,"Power_%d" ,"TLim_%d" +"R0_%d" ,"R0_Low_%d" ,"InvR0_%d" ,"Power_%d" ,"TLim_%d" };efi_char16_t efi_name[TAS2563_CAL_VAR_NAME_MAX ];unsigned long max_size =TAS2563_CAL_DATA_SIZE ;
Greg Kroah-Hartman
maintainerPATCH 148/183 pcmcia: omap: Add missing check for platform_get_resource
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Ni <[email protected]>
[ Upstream commit ecef14f70ec9344a10c817248d2ac6cddee5921e ]
Add missing check for platform_get_resource() and return error if it fails to catch the error.
--- drivers/pcmcia/omap_cf.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/pcmcia/omap_cf.c +2 -0
@@ -215,6 +215,8 @@ static int __init omap_cf_probe(struct platform_device *pdev)return -EINVAL ; res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); +if (!res) +return -EINVAL ; cf =kzalloc (sizeof *cf,GFP_KERNEL );if (!cf)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 149/183 pcmcia: Add error handling for add_interval() in do_validate_mem()
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wentao Liang <[email protected]>
[ Upstream commit 4a81f78caa53e0633cf311ca1526377d9bff7479 ]
In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next.
This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code.
--- drivers/pcmcia/rsrc_nonstatic.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/pcmcia/rsrc_nonstatic.c +3 -1
@@ -375,7 +375,9 @@ static int do_validate_mem(struct pcmcia_socket *s,if (validate && !s->fake_cis) {/* move it to the validated data set */ -add_interval (&s_data->mem_db_valid, base, size); + ret =add_interval (&s_data->mem_db_valid, base, size); +if (ret) +return ret;sub_interval (&s_data->mem_db, base, size); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 150/183 platform/x86: asus-wmi: Remove extra keys from ignore_key_wlan quirk
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antheas Kapenekakis <[email protected]>
[ Upstream commit cf3940ac737d05c85395f343fe33a3cfcadb47db ]
Currently, the ignore_key_wlan quirk applies to keycodes 0x5D, 0x5E, and 0x5F. However, the relevant code for the Asus Zenbook Duo is only 0x5F. Since this code is emitted by other Asus devices, such as from the Z13 for its ROG button, remove the extra codes before expanding the quirk.
For the Duo devices, which are the only ones that use this quirk, there should be no effect.
--- drivers/platform/x86/asus-nb-wmi.c | 2 -- 1 file changed, 2 deletions(-)
drivers/platform/x86/asus-nb-wmi.c +0 -2
@@ -655,8 +655,6 @@ static void asus_nb_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code,if (atkbd_reports_vol_keys) *code =ASUS_WMI_KEY_IGNORE ;break ; -case 0x5D :/* Wireless console Toggle */ -case 0x5E :/* Wireless console Enable */ case 0x5F :/* Wireless console Disable */ if (quirks->ignore_key_wlan) *code =ASUS_WMI_KEY_IGNORE ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 151/183 platform/x86: asus-wmi: Fix racy registrations
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
[ Upstream commit 5549202b9c02c2ecbc8634768a3da8d9e82d548d ]
asus_wmi_register_driver() may be called from multiple drivers concurrently, which can lead to the racy list operations, eventually corrupting the memory and hitting Oops on some ASUS machines. Also, the error handling is missing, and it forgot to unregister ACPI lps0 dev ops in the error case.
This patch covers those issues by introducing a simple mutex at acpi_wmi_register_driver() & *_unregister_driver, and adding the proper call of asus_s2idle_check_unregister() in the error path.
--- drivers/platform/x86/asus-wmi.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/platform/x86/asus-wmi.c +8 -1
@@ -5088,16 +5088,22 @@ static int asus_wmi_probe(struct platform_device *pdev)asus_s2idle_check_register (); -return asus_wmi_add (pdev); + ret =asus_wmi_add (pdev); +if (ret) +asus_s2idle_check_unregister (); + +return ret; }static bool used; +static DEFINE_MUTEX (register_mutex); int __init_or_module asus_wmi_register_driver(struct asus_wmi_driver *driver) {struct platform_driver *platform_driver;struct platform_device *platform_device; +guard (mutex)(®ister_mutex);if (used)return -EBUSY ;
@@ -5120,6 +5126,7 @@ EXPORT_SYMBOL_GPL(asus_wmi_register_driver);void asus_wmi_unregister_driver (struct asus_wmi_driver *driver) { +guard (mutex)(®ister_mutex);asus_s2idle_check_unregister ();platform_device_unregister (driver->platform_device);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 152/183 platform/x86: acer-wmi: Stop using ACPI bitmap for platform profile choices
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Armin Wolf <[email protected]>
[ Upstream commit b0908e03fdd488a5ffd5b80d86dcfc77207464e7 ]
It turns out that the platform firmware on some models does not return valid data when reading the bitmap of supported platform profiles. This prevents the driver from loading on said models, even when the platform profile interface itself works.
Fix this by stop using said bitmap until we have figured out how the OEM software itself detects available platform profiles.
--- drivers/platform/x86/acer-wmi.c | 71 ++++++--------------------------- 1 file changed, 12 insertions(+), 59 deletions(-)
drivers/platform/x86/acer-wmi.c +12 -59
@@ -129,6 +129,7 @@ enum acer_wmi_predator_v4_oc {enum acer_wmi_gaming_misc_setting {ACER_WMID_MISC_SETTING_OC_1 =0x0005 ,ACER_WMID_MISC_SETTING_OC_2 =0x0007 , +/* Unreliable on some models */ ACER_WMID_MISC_SETTING_SUPPORTED_PROFILES =0x000A ,ACER_WMID_MISC_SETTING_PLATFORM_PROFILE =0x000B , };
@@ -794,9 +795,6 @@ static bool platform_profile_support;*/ static int last_non_turbo_profile =INT_MIN ; -/* The most performant supported profile */ -static int acer_predator_v4_max_perf; -enum acer_predator_v4_thermal_profile {ACER_PREDATOR_V4_THERMAL_PROFILE_QUIET =0x00 ,ACER_PREDATOR_V4_THERMAL_PROFILE_BALANCED =0x01 ,
@@ -2014,7 +2012,7 @@ acer_predator_v4_platform_profile_set(struct device *dev,if (err)return err; -if (tp != acer_predator_v4_max_perf) +if (tp !=ACER_PREDATOR_V4_THERMAL_PROFILE_TURBO ) last_non_turbo_profile = tp;return 0 ;
@@ -2023,55 +2021,14 @@ acer_predator_v4_platform_profile_set(struct device *dev,static int acer_predator_v4_platform_profile_probe (void *drvdata,unsigned long *choices) { -unsigned long supported_profiles; -int err; +set_bit (PLATFORM_PROFILE_PERFORMANCE , choices); +set_bit (PLATFORM_PROFILE_BALANCED_PERFORMANCE , choices); +set_bit (PLATFORM_PROFILE_BALANCED , choices); +set_bit (PLATFORM_PROFILE_QUIET , choices); +set_bit (PLATFORM_PROFILE_LOW_POWER , choices); - err =WMID_gaming_get_misc_setting (ACER_WMID_MISC_SETTING_SUPPORTED_PROFILES , - (u8 *)&supported_profiles); -if (err) -return err; - -/* Iterate through supported profiles in order of increasing performance */ -if (test_bit (ACER_PREDATOR_V4_THERMAL_PROFILE_ECO , &supported_profiles)) { -set_bit (PLATFORM_PROFILE_LOW_POWER , choices); - acer_predator_v4_max_perf =ACER_PREDATOR_V4_THERMAL_PROFILE_ECO ; - last_non_turbo_profile =ACER_PREDATOR_V4_THERMAL_PROFILE_ECO ; - } - -if (test_bit (ACER_PREDATOR_V4_THERMAL_PROFILE_QUIET , &supported_profiles)) { -set_bit (PLATFORM_PROFILE_QUIET , choices); - acer_predator_v4_max_perf =ACER_PREDATOR_V4_THERMAL_PROFILE_QUIET ; - last_non_turbo_profile =ACER_PREDATOR_V4_THERMAL_PROFILE_QUIET ; - } - -if (test_bit (ACER_PREDATOR_V4_THERMAL_PROFILE_BALANCED , &supported_profiles)) { -set_bit (PLATFORM_PROFILE_BALANCED , choices); - acer_predator_v4_max_perf =ACER_PREDATOR_V4_THERMAL_PROFILE_BALANCED ; - last_non_turbo_profile =ACER_PREDATOR_V4_THERMAL_PROFILE_BALANCED ; - } - -if (test_bit (ACER_PREDATOR_V4_THERMAL_PROFILE_PERFORMANCE , &supported_profiles)) { -set_bit (PLATFORM_PROFILE_BALANCED_PERFORMANCE , choices); - acer_predator_v4_max_perf =ACER_PREDATOR_V4_THERMAL_PROFILE_PERFORMANCE ; - -/* We only use this profile as a fallback option in case no prior -* profile is supported. -*/ -if (last_non_turbo_profile <0 ) - last_non_turbo_profile =ACER_PREDATOR_V4_THERMAL_PROFILE_PERFORMANCE ; - } - -if (test_bit (ACER_PREDATOR_V4_THERMAL_PROFILE_TURBO , &supported_profiles)) { -set_bit (PLATFORM_PROFILE_PERFORMANCE , choices); - acer_predator_v4_max_perf =ACER_PREDATOR_V4_THERMAL_PROFILE_TURBO ; - -/* We need to handle the hypothetical case where only the turbo profile -* is supported. In this case the turbo toggle will essentially be a -* no-op. -*/ -if (last_non_turbo_profile <0 ) - last_non_turbo_profile =ACER_PREDATOR_V4_THERMAL_PROFILE_TURBO ; - } +/* Set default non-turbo profile */ + last_non_turbo_profile =ACER_PREDATOR_V4_THERMAL_PROFILE_BALANCED ;return 0 ; }
@@ -2108,19 +2065,15 @@ static int acer_thermal_profile_change(void)if (cycle_gaming_thermal_profile) {platform_profile_cycle (); }else { -/* Do nothing if no suitable platform profiles where found */ -if (last_non_turbo_profile <0 ) -return 0 ; - err =WMID_gaming_get_misc_setting (ACER_WMID_MISC_SETTING_PLATFORM_PROFILE , ¤t_tp);if (err)return err; -if (current_tp == acer_predator_v4_max_perf) +if (current_tp ==ACER_PREDATOR_V4_THERMAL_PROFILE_TURBO ) tp = last_non_turbo_profile;else - tp = acer_predator_v4_max_perf; + tp =ACER_PREDATOR_V4_THERMAL_PROFILE_TURBO ; err =WMID_gaming_set_misc_setting (ACER_WMID_MISC_SETTING_PLATFORM_PROFILE , tp);
@@ -2128,7 +2081,7 @@ static int acer_thermal_profile_change(void)return err;/* Store last profile for toggle */ -if (current_tp != acer_predator_v4_max_perf) +if (current_tp !=ACER_PREDATOR_V4_THERMAL_PROFILE_TURBO ) last_non_turbo_profile = current_tp;platform_profile_notify (platform_profile_device);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 153/183 platform/x86/intel: power-domains: Use topology_logical_package_id() for package ID
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Arcari <[email protected]>
[ Upstream commit aa28991fd5dc4c01a40caab2bd9af8c5e06f9899 ]
Currently, tpmi_get_logical_id() calls topology_physical_package_id() to set the pkg_id of the info structure. Since some VM hosts assign non contiguous package IDs, topology_physical_package_id() can return a larger value than topology_max_packages(). This will result in an invalid reference into tpmi_power_domain_mask[] as that is allocatead based on topology_max_packages() as the maximum package ID.
--- drivers/platform/x86/intel/tpmi_power_domains.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/platform/x86/intel/tpmi_power_domains.c +1 -1
@@ -178,7 +178,7 @@ static int tpmi_get_logical_id(unsigned int cpu, struct tpmi_cpu_info *info) info->punit_thread_id =FIELD_GET (LP_ID_MASK , data); info->punit_core_id =FIELD_GET (MODULE_ID_MASK , data); - info->pkg_id =topology_physical_package_id (cpu); + info->pkg_id =topology_logical_package_id (cpu); info->linux_cpu = cpu;return 0 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 154/183 hwmon: mlxreg-fan: Prevent fans from getting stuck at 0 RPM
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vadim Pasternak <[email protected]>
[ Upstream commit 1180c79fbf36e4c02e76ae4658509523437e52a4 ]
The fans controlled by the driver can get stuck at 0 RPM if they are configured below a 20% duty cycle. The driver tries to avoid this by enforcing a minimum duty cycle of 20%, but this is done after the fans are registered with the thermal subsystem. This is too late as the thermal subsystem can set their current state before the driver is able to enforce the minimum duty cycle.
Fix by setting the minimum duty cycle before registering the fans with the thermal subsystem.
--- drivers/hwmon/mlxreg-fan.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/hwmon/mlxreg-fan.c +2 -3
@@ -561,15 +561,14 @@ static int mlxreg_fan_cooling_config(struct device *dev, struct mlxreg_fan *fan)if (!pwm->connected)continue ; pwm->fan = fan; +/* Set minimal PWM speed. */ + pwm->last_hwmon_state =MLXREG_FAN_PWM_DUTY2STATE (MLXREG_FAN_MIN_DUTY ); pwm->cdev =devm_thermal_of_cooling_device_register (dev,NULL , mlxreg_fan_name[i], pwm, &mlxreg_fan_cooling_ops);if (IS_ERR (pwm->cdev)) {dev_err (dev,"Failed to register cooling device\n" );return PTR_ERR (pwm->cdev); } - -/* Set minimal PWM speed. */ - pwm->last_hwmon_state =MLXREG_FAN_PWM_DUTY2STATE (MLXREG_FAN_MIN_DUTY ); }return 0 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 155/183 hwmon: (ina238) Correctly clamp temperature
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Packham <[email protected]>
[ Upstream commit 98fd069dd87386d87eaf439e3c7b5767618926d2 ]
ina238_write_temp() was attempting to clamp the user input but was throwing away the result. Ensure that we clamp the value to the appropriate range before it is converted into a register value.
--- drivers/hwmon/ina238.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/ina238.c +1 -1
@@ -481,7 +481,7 @@ static int ina238_write_temp(struct device *dev, u32 attr, long val)return -EOPNOTSUPP ;/* Signed */ - regval =clamp_val (val,-40000 ,125000 ); + val =clamp_val (val,-40000 ,125000 ); regval =div_s64 (val *10000 , data->config->temp_lsb) << data->config->temp_shift; regval =clamp_val (regval,S16_MIN ,S16_MAX ) & (0xffff << data->config->temp_shift);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 156/183 scsi: sr: Reinstate rotational media flag
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Lei <[email protected]>
[ Upstream commit 708e2371f77a9d3f2f1d54d1ec835d71b9d0dafe ]
Reinstate the rotational media flag for the CD-ROM driver. The flag has been cleared since commit bd4a633b6f7c ("block: move the nonrot flag to queue_limits") and this breaks some applications.
Move queue limit configuration from get_sectorsize() to sr_revalidate_disk() and set the rotational flag.
--- drivers/scsi/sr.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
drivers/scsi/sr.c +10 -6
@@ -475,13 +475,21 @@ static blk_status_t sr_init_command(struct scsi_cmnd *SCpnt)static int sr_revalidate_disk (struct scsi_cd *cd) { +struct request_queue *q = cd->device->request_queue;struct scsi_sense_hdr sshdr; +struct queue_limits lim; +int sector_size;/* if the unit is not ready, nothing more to do */ if (scsi_test_unit_ready (cd->device,SR_TIMEOUT ,MAX_RETRIES , &sshdr))return 0 ;sr_cd_check (&cd->cdi); -return get_sectorsize (cd); + sector_size =get_sectorsize (cd); + + lim =queue_limits_start_update (q); + lim.logical_block_size = sector_size; + lim.features |=BLK_FEAT_ROTATIONAL ; +return queue_limits_commit_update_frozen (q, &lim); }static int sr_block_open (struct gendisk *disk,blk_mode_t mode)
@@ -721,10 +729,8 @@ static int sr_probe(struct device *dev)static int get_sectorsize (struct scsi_cd *cd) { -struct request_queue *q = cd->device->request_queue;static const u8 cmd[10 ] = {READ_CAPACITY };unsigned char buffer[8 ] = { }; -struct queue_limits lim;int err;int sector_size;struct scsi_failure failure_defs[] = {
@@ -795,9 +801,7 @@ static int get_sectorsize(struct scsi_cd *cd)set_capacity (cd->disk, cd->capacity); } - lim =queue_limits_start_update (q); - lim.logical_block_size = sector_size; -return queue_limits_commit_update_frozen (q, &lim); +return sector_size; }static int get_capabilities (struct scsi_cd *cd)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 157/183 spi: spi-fsl-lpspi: Fix transmissions when using CONT
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larisa Grigore <[email protected]>
[ Upstream commit 782a7c73078e1301c0c427f21c06377d77dfa541 ]
Commit 6a130448498c ("spi: lpspi: Fix wrong transmission when don't use CONT") breaks transmissions when CONT is used. The TDIE interrupt should not be disabled in all cases. If CONT is used and the TX transfer is not yet completed yet, but the interrupt handler is called because there are characters to be received, TDIE is replaced with FCIE. When the transfer is finally completed, SR_TDF is set but the interrupt handler isn't called again.
--- drivers/spi/spi-fsl-lpspi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/spi/spi-fsl-lpspi.c +2 -2
@@ -3,7 +3,7 @@// Freescale i.MX7ULP LPSPI driver // // Copyright 2016 Freescale Semiconductor, Inc. -// Copyright 2018 NXP Semiconductors +// Copyright 2018, 2023, 2025 NXP #include <linux/clk.h> #include <linux/completion.h>
@@ -786,7 +786,7 @@ static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)if (temp_SR &SR_MBF ||readl (fsl_lpspi->base +IMX7ULP_FSR ) &FSR_TXCOUNT ) {writel (SR_FCF , fsl_lpspi->base +IMX7ULP_SR ); -fsl_lpspi_intctrl (fsl_lpspi,IER_FCIE ); +fsl_lpspi_intctrl (fsl_lpspi,IER_FCIE | (temp_IER &IER_TDIE ));return IRQ_HANDLED ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 158/183 spi: spi-fsl-lpspi: Set correct chip-select polarity bit
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larisa Grigore <[email protected]>
[ Upstream commit cbe33705864ba2697a2939de715b81538cf32430 ]
The driver currently supports multiple chip-selects, but only sets the polarity for the first one (CS 0). Fix it by setting the PCSPOL bit for the desired chip-select.
--- drivers/spi/spi-fsl-lpspi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/spi/spi-fsl-lpspi.c +5 -2
@@ -5,6 +5,7 @@// Copyright 2016 Freescale Semiconductor, Inc. // Copyright 2018, 2023, 2025 NXP +#include <linux/bitfield.h> #include <linux/clk.h> #include <linux/completion.h> #include <linux/delay.h>
@@ -70,7 +71,7 @@#define DER_TDDE BIT(0)#define CFGR1_PCSCFG BIT(27)#define CFGR1_PINCFG (BIT(24)|BIT(25)) -#define CFGR1_PCSPOL BIT(8) +#define CFGR1_PCSPOL_MASK GENMASK(11, 8)#define CFGR1_NOSTALL BIT(3)#define CFGR1_HOST BIT(0)#define FSR_TXCOUNT (0xFF)
@@ -424,7 +425,9 @@ static int fsl_lpspi_config(struct fsl_lpspi_data *fsl_lpspi)else temp =CFGR1_PINCFG ;if (fsl_lpspi->config.mode &SPI_CS_HIGH ) - temp |=CFGR1_PCSPOL ; + temp |=FIELD_PREP (CFGR1_PCSPOL_MASK , +BIT (fsl_lpspi->config.chip_select)); +writel (temp, fsl_lpspi->base +IMX7ULP_CFGR1 ); temp =readl (fsl_lpspi->base +IMX7ULP_CR );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 159/183 spi: spi-fsl-lpspi: Reset FIFO and disable module on transfer abort
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larisa Grigore <[email protected]>
[ Upstream commit e811b088a3641861fc9d2b2b840efc61a0f1907d ]
In DMA mode fsl_lpspi_reset() is always called at the end, even when the transfer is aborted. In PIO mode aborts skip the reset leaving the FIFO filled and the module enabled.
Fix it by always calling fsl_lpspi_reset().
--- drivers/spi/spi-fsl-lpspi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/spi/spi-fsl-lpspi.c +1 -3
@@ -734,12 +734,10 @@ static int fsl_lpspi_pio_transfer(struct spi_controller *controller,fsl_lpspi_write_tx_fifo (fsl_lpspi); ret =fsl_lpspi_wait_for_completion (controller); -if (ret) -return ret;fsl_lpspi_reset (fsl_lpspi); -return 0 ; +return ret; } static int fsl_lpspi_transfer_one(struct spi_controller *controller,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 160/183 spi: spi-fsl-lpspi: Clear status register after disabling the module
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larisa Grigore <[email protected]>
[ Upstream commit dedf9c93dece441e9a0a4836458bc93677008ddd ]
Clear the error flags after disabling the module to avoid the case when a flag is set again between flag clear and module disable. And use SR_CLEAR_MASK to replace hardcoded value for improved readability.
Although fsl_lpspi_reset() was only introduced in commit a15dc3d657fa ("spi: lpspi: Fix CLK pin becomes low before one transfer"), the original driver only reset SR in the interrupt handler, making it vulnerable to the same issue. Therefore the fixes commit is set at the introduction of the driver.
--- drivers/spi/spi-fsl-lpspi.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/spi/spi-fsl-lpspi.c +5 -4
@@ -83,6 +83,8 @@#define TCR_RXMSK BIT(19)#define TCR_TXMSK BIT(18) +#define SR_CLEAR_MASK GENMASK(13, 8) +struct fsl_lpspi_devtype_data {u8 prescale_max; };
@@ -536,14 +538,13 @@ static int fsl_lpspi_reset(struct fsl_lpspi_data *fsl_lpspi)fsl_lpspi_intctrl (fsl_lpspi,0 ); } -/* W1C for all flags in SR */ - temp =0x3F <<8 ; -writel (temp, fsl_lpspi->base +IMX7ULP_SR ); -/* Clear FIFO and disable module */ temp =CR_RRF |CR_RTF ;writel (temp, fsl_lpspi->base +IMX7ULP_CR ); +/* W1C for all flags in SR */ +writel (SR_CLEAR_MASK , fsl_lpspi->base +IMX7ULP_SR ); +return 0 ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 161/183 hwmon: (ina238) Correctly clamp shunt voltage limit
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit bd7e7bc2cc2024035dfbc8239c9f4d8675793445 ]
When clamping a register value, the result needs to be masked against the register size. This was missing, resulting in errors when trying to write negative limits. Fix by masking the clamping result against the register size.
--- drivers/hwmon/ina238.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/ina238.c +1 -1
@@ -300,7 +300,7 @@ static int ina238_write_in(struct device *dev, u32 attr, int channel, regval =clamp_val (val,-163 ,163 ); regval = (regval *1000 *4 ) / (INA238_SHUNT_VOLTAGE_LSB * data->gain); - regval =clamp_val (regval,S16_MIN ,S16_MAX ); + regval =clamp_val (regval,S16_MIN ,S16_MAX ) &0xffff ;switch (attr) {case hwmon_in_max:
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 162/183 hwmon: (ina238) Correctly clamp power limits
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit c2623573178bab32990695fb729e9b69710ed66d ]
ina238_write_power() was attempting to clamp the user input but was throwing away the result. Ensure that we clamp the value to the appropriate range before it is converted into a register value.
--- drivers/hwmon/ina238.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/hwmon/ina238.c +3 -2
@@ -426,9 +426,10 @@ static int ina238_write_power(struct device *dev, u32 attr, long val)* Unsigned postive values. Compared against the 24-bit power register, * lower 8-bits are truncated. Same conversion to/from uW as POWER * register. +* The first clamp_val() is to establish a baseline to avoid overflows. */ - regval =clamp_val (val,0 ,LONG_MAX ); - regval =div_u64 (val *4 *100 * data->rshunt, data->config->power_calculate_factor * + regval =clamp_val (val,0 ,LONG_MAX /2 ); + regval =div_u64 (regval *4 *100 * data->rshunt, data->config->power_calculate_factor *1000ULL *INA238_FIXED_SHUNT * data->gain); regval =clamp_val (regval >>8 ,0 ,U16_MAX );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 163/183 drm/bridge: ti-sn65dsi86: fix REFCLK setting
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Walle <[email protected]>
[ Upstream commit bdd5a14e660062114bdebaef9ad52adf04970a89 ]
The bridge has three bootstrap pins which are sampled to determine the frequency of the external reference clock. The driver will also (over)write that setting. But it seems this is racy after the bridge is enabled. It was observed that although the driver write the correct value (by sniffing on the I2C bus), the register has the wrong value. The datasheet states that the GPIO lines have to be stable for at least 5us after asserting the EN signal. Thus, there seems to be some logic which samples the GPIO lines and this logic appears to overwrite the register value which was set by the driver. Waiting 20us after asserting the EN line resolves this issue.
--- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/gpu/drm/bridge/ti-sn65dsi86.c +11 -0
@@ -392,6 +392,17 @@ static int __maybe_unused ti_sn65dsi86_resume(struct device *dev)gpiod_set_value_cansleep (pdata->enable_gpio,1 ); +/* +* After EN is deasserted and an external clock is detected, the bridge +* will sample GPIO3:1 to determine its frequency. The driver will +* overwrite this setting in ti_sn_bridge_set_refclk_freq(). But this is +* racy. Thus we have to wait a couple of us. According to the datasheet +* the GPIO lines has to be stable at least 5 us (td5) but it seems that +* is not enough and the refclk frequency value is still lost or +* overwritten by the bridge itself. Waiting for 20us seems to work. +*/ +usleep_range (20 ,30 ); +/* * If we have a reference clock we can enable communication w/ the * panel (including the aux channel) w/out any need for an input clock
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 164/183 perf bpf-event: Fix use-after-free in synthesis
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Rogers <[email protected]>
[ Upstream commit d7b67dd6f9db7bd2c49b415e901849b182ff0735 ]
Calls to perf_env__insert_bpf_prog_info may fail as a sideband thread may already have inserted the bpf_prog_info. Such failures may yield info_linear being freed which then causes use-after-free issues with the internal bpf_prog_info info struct. Make it so that perf_env__insert_bpf_prog_info trigger early non-error paths and fix the use-after-free in perf_event__synthesize_one_bpf_prog. Add proper return error handling to perf_env__add_bpf_info (that calls perf_env__insert_bpf_prog_info) and propagate the return value in its callers.
--- tools/perf/util/bpf-event.c | 39 +++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-)
tools/perf/util/bpf-event.c +27 -12
@@ -290,9 +290,15 @@ static int perf_event__synthesize_one_bpf_prog(struct perf_session *session, info_node->info_linear = info_linear;if (!perf_env__insert_bpf_prog_info (env, info_node)) { -free (info_linear); +/* +* Insert failed, likely because of a duplicate event +* made by the sideband thread. Ignore synthesizing the +* metadata. +*/ free (info_node); + goto out; } +/* info_linear is now owned by info_node and shouldn't be freed below. */ info_linear =NULL ;/*
@@ -451,18 +457,18 @@ int perf_event__synthesize_bpf_events(struct perf_session *session,return err; } -static void perf_env__add_bpf_info (struct perf_env *env,u32 id) +static int perf_env__add_bpf_info (struct perf_env *env,u32 id) {struct bpf_prog_info_node *info_node;struct perf_bpil *info_linear;struct btf *btf =NULL ;u64 arrays;u32 btf_id; -int fd; +int fd, err =0 ; fd =bpf_prog_get_fd_by_id (id);if (fd <0 ) -return ; +return -EINVAL ; arrays =1UL <<PERF_BPIL_JITED_KSYMS ; arrays |=1UL <<PERF_BPIL_JITED_FUNC_LENS ;
@@ -475,6 +481,7 @@ static void perf_env__add_bpf_info(struct perf_env *env, u32 id) info_linear =get_bpf_prog_info_linear (fd, arrays);if (IS_ERR_OR_NULL (info_linear)) {pr_debug ("%s: failed to get BPF program info. aborting\n" , __func__); + err =PTR_ERR (info_linear); goto out; }
@@ -484,38 +491,46 @@ static void perf_env__add_bpf_info(struct perf_env *env, u32 id)if (info_node) { info_node->info_linear = info_linear;if (!perf_env__insert_bpf_prog_info (env, info_node)) { +pr_debug ("%s: duplicate add bpf info request for id %u\n" , + __func__, btf_id);free (info_linear);free (info_node); + goto out; } - }else + }else {free (info_linear); + err = -ENOMEM ; + goto out; + }if (btf_id ==0 ) goto out; btf =btf__load_from_kernel_by_id (btf_id); -if (libbpf_get_error (btf)) { -pr_debug ("%s: failed to get BTF of id %u, aborting\n" , - __func__, btf_id); - goto out; +if (!btf) { + err = -errno; +pr_debug ("%s: failed to get BTF of id %u %d\n" , __func__, btf_id, err); + }else { +perf_env__fetch_btf (env, btf_id, btf); } -perf_env__fetch_btf (env, btf_id, btf); out:btf__free (btf);close (fd); +return err; }static int bpf_event__sb_cb (union perf_event *event,void *data) {struct perf_env *env = data; +int ret =0 ;if (event->header.type !=PERF_RECORD_BPF_EVENT )return -1 ;switch (event->bpf.type) {case PERF_BPF_EVENT_PROG_LOAD : -perf_env__add_bpf_info (env, event->bpf.id); + ret =perf_env__add_bpf_info (env, event->bpf.id);case PERF_BPF_EVENT_PROG_UNLOAD :/*
@@ -529,7 +544,7 @@ static int bpf_event__sb_cb(union perf_event *event, void *data)break ; } -return 0 ; +return ret; }int evlist__add_bpf_sb_event (struct evlist *evlist,struct perf_env *env)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 165/183 perf bpf-utils: Constify bpil_array_desc
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Rogers <[email protected]>
[ Upstream commit 1654a0e4d576d9e43fbb10ccf6a1b307c5c18566 ]
The array's contents is a compile time constant. Constify to make the code more intention revealing and avoid unintended errors.
Stable-dep-of: 01be43f2a0ea ("perf bpf-utils: Harden get_bpf_prog_info_linear")
--- tools/perf/util/bpf-utils.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-)
tools/perf/util/bpf-utils.c +6 -12
@@ -20,7 +20,7 @@ struct bpil_array_desc {*/ }; -static struct bpil_array_desc bpil_array_desc[] = { +static const struct bpil_array_desc bpil_array_desc[] = { [PERF_BPIL_JITED_INSNS ] = { offsetof(struct bpf_prog_info , jited_prog_insns), offsetof(struct bpf_prog_info , jited_prog_len),
@@ -129,12 +129,10 @@ get_bpf_prog_info_linear(int fd, __u64 arrays)/* step 2: calculate total size of all arrays */ for (i =PERF_BPIL_FIRST_ARRAY ; i <PERF_BPIL_LAST_ARRAY ; ++i) { +const struct bpil_array_desc *desc = &bpil_array_desc[i];bool include_array = (arrays & (1UL << i)) >0 ; -struct bpil_array_desc *desc;__u32 count, size; - desc = bpil_array_desc + i; -/* kernel is too old to support this field */ if (info_len < desc->array_offset + sizeof(__u32) || info_len < desc->count_offset + sizeof(__u32) ||
@@ -163,13 +161,12 @@ get_bpf_prog_info_linear(int fd, __u64 arrays) ptr = info_linear->data;for (i =PERF_BPIL_FIRST_ARRAY ; i <PERF_BPIL_LAST_ARRAY ; ++i) { -struct bpil_array_desc *desc; +const struct bpil_array_desc *desc = &bpil_array_desc[i];__u32 count, size;if ((arrays & (1UL << i)) ==0 )continue ; - desc = bpil_array_desc + i; count =bpf_prog_info_read_offset_u32 (&info, desc->count_offset); size =bpf_prog_info_read_offset_u32 (&info, desc->size_offset); bpf_prog_info_set_offset_u32(&info_linear->info,
@@ -192,13 +189,12 @@ get_bpf_prog_info_linear(int fd, __u64 arrays)/* step 6: verify the data */ for (i =PERF_BPIL_FIRST_ARRAY ; i <PERF_BPIL_LAST_ARRAY ; ++i) { -struct bpil_array_desc *desc; +const struct bpil_array_desc *desc = &bpil_array_desc[i];__u32 v1, v2;if ((arrays & (1UL << i)) ==0 )continue ; - desc = bpil_array_desc + i; v1 =bpf_prog_info_read_offset_u32 (&info, desc->count_offset); v2 =bpf_prog_info_read_offset_u32 (&info_linear->info, desc->count_offset);
@@ -224,13 +220,12 @@ void bpil_addr_to_offs(struct perf_bpil *info_linear)int i;for (i =PERF_BPIL_FIRST_ARRAY ; i <PERF_BPIL_LAST_ARRAY ; ++i) { -struct bpil_array_desc *desc; +const struct bpil_array_desc *desc = &bpil_array_desc[i];__u64 addr, offs;if ((info_linear->arrays & (1UL << i)) ==0 )continue ; - desc = bpil_array_desc + i; addr =bpf_prog_info_read_offset_u64 (&info_linear->info, desc->array_offset); offs = addr -ptr_to_u64 (info_linear->data);
@@ -244,13 +239,12 @@ void bpil_offs_to_addr(struct perf_bpil *info_linear)int i;for (i =PERF_BPIL_FIRST_ARRAY ; i <PERF_BPIL_LAST_ARRAY ; ++i) { -struct bpil_array_desc *desc; +const struct bpil_array_desc *desc = &bpil_array_desc[i];__u64 addr, offs;if ((info_linear->arrays & (1UL << i)) ==0 )continue ; - desc = bpil_array_desc + i; offs =bpf_prog_info_read_offset_u64 (&info_linear->info, desc->array_offset); addr = offs +ptr_to_u64 (info_linear->data);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 166/183 perf bpf-utils: Harden get_bpf_prog_info_linear
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Rogers <[email protected]>
[ Upstream commit 01be43f2a0eaeed83e94dee054742f37625c86d9 ]
In get_bpf_prog_info_linear two calls to bpf_obj_get_info_by_fd are made, the first to compute memory requirements for a struct perf_bpil and the second to fill it in. Previously the code would warn when the second call didn't match the first. Such races can be common place in things like perf test, whose perf trace tests will frequently load BPF programs. Rather than a debug message, return actual errors for this case. Out of paranoia also validate the read bpf_prog_info array value. Change the type of ptr to avoid mismatched pointer type compiler warnings. Add some additional debug print outs and sanity asserts.
--- tools/perf/util/bpf-utils.c | 43 ++++++++++++++++++++++++++++--------- 1 file changed, 33 insertions(+), 10 deletions(-)
tools/perf/util/bpf-utils.c +33 -10
@@ -115,7 +115,7 @@ get_bpf_prog_info_linear(int fd, __u64 arrays)__u32 info_len =sizeof (info);__u32 data_len =0 ;int i, err; -void *ptr; +__u8 *ptr;if (arrays >>PERF_BPIL_LAST_ARRAY )return ERR_PTR (-EINVAL );
@@ -126,6 +126,8 @@ get_bpf_prog_info_linear(int fd, __u64 arrays)pr_debug ("can't get prog info: %s" ,strerror (errno));return ERR_PTR (-EFAULT ); } +if (info.type >= __MAX_BPF_PROG_TYPE) +pr_debug ("%s:%d: unexpected program type %u\n" , __func__, __LINE__, info.type);/* step 2: calculate total size of all arrays */ for (i =PERF_BPIL_FIRST_ARRAY ; i <PERF_BPIL_LAST_ARRAY ; ++i) {
@@ -173,6 +175,8 @@ get_bpf_prog_info_linear(int fd, __u64 arrays) desc->count_offset, count);bpf_prog_info_set_offset_u32 (&info_linear->info, desc->size_offset, size); +assert (ptr >= info_linear->data); +assert (ptr < &info_linear->data[data_len]);bpf_prog_info_set_offset_u64 (&info_linear->info, desc->array_offset,ptr_to_u64 (ptr));
@@ -186,26 +190,45 @@ get_bpf_prog_info_linear(int fd, __u64 arrays)free (info_linear);return ERR_PTR (-EFAULT ); } +if (info_linear->info.type >= __MAX_BPF_PROG_TYPE) { +pr_debug ("%s:%d: unexpected program type %u\n" , + __func__, __LINE__, info_linear->info.type); + }/* step 6: verify the data */ + ptr = info_linear->data;for (i =PERF_BPIL_FIRST_ARRAY ; i <PERF_BPIL_LAST_ARRAY ; ++i) {const struct bpil_array_desc *desc = &bpil_array_desc[i]; -__u32 v1, v2; +__u32 count1, count2, size1, size2; +__u64 ptr2;if ((arrays & (1UL << i)) ==0 )continue ; - v1 =bpf_prog_info_read_offset_u32 (&info, desc->count_offset); - v2 =bpf_prog_info_read_offset_u32 (&info_linear->info, + count1 =bpf_prog_info_read_offset_u32 (&info, desc->count_offset); + count2 =bpf_prog_info_read_offset_u32 (&info_linear->info, desc->count_offset); -if (v1 != v2) -pr_warning ("%s: mismatch in element count\n" , __func__); +if (count1 != count2) { +pr_warning ("%s: mismatch in element count %u vs %u\n" , __func__, count1, count2); +free (info_linear); +return ERR_PTR (-ERANGE ); + } - v1 =bpf_prog_info_read_offset_u32 (&info, desc->size_offset); - v2 =bpf_prog_info_read_offset_u32 (&info_linear->info, + size1 =bpf_prog_info_read_offset_u32 (&info, desc->size_offset); + size2 =bpf_prog_info_read_offset_u32 (&info_linear->info, desc->size_offset); -if (v1 != v2) -pr_warning ("%s: mismatch in rec size\n" , __func__); +if (size1 != size2) { +pr_warning ("%s: mismatch in rec size %u vs %u\n" , __func__, size1, size2); +free (info_linear); +return ERR_PTR (-ERANGE ); + } + ptr2 =bpf_prog_info_read_offset_u64 (&info_linear->info, desc->array_offset); +if (ptr_to_u64 (ptr) != ptr2) { +pr_warning ("%s: mismatch in array %p vs %llx\n" , __func__, ptr, ptr2); +free (info_linear); +return ERR_PTR (-ERANGE ); + } + ptr +=roundup (count1 * size1,sizeof (__u64)); }/* step 7: update info_len and data_len */
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 167/183 spi: spi-qpic-snand: unregister ECC engine on probe error and device remove
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gabor Juhos <[email protected]>
[ Upstream commit 1991a458528588ff34e98b6365362560d208710f ]
The on-host hardware ECC engine remains registered both when the spi_register_controller() function returns with an error and also on device removal.
Change the qcom_spi_probe() function to unregister the engine on the error path, and add the missing unregistering call to qcom_spi_remove() to avoid possible use-after-free issues.
Message-ID: <20250903-qpic-snand-unregister-ecceng-v1-1-ef5387b0abdc@gmail.com>
--- drivers/spi/spi-qpic-snand.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/spi/spi-qpic-snand.c +4 -2
@@ -1615,11 +1615,13 @@ static int qcom_spi_probe(struct platform_device *pdev) ret =spi_register_controller (ctlr);if (ret) {dev_err (&pdev->dev,"spi_register_controller failed.\n" ); - goto err_spi_init; + goto err_register_controller; }return 0 ; +err_register_controller: +nand_ecc_unregister_on_host_hw_engine (&snandc->qspi->ecc_eng); err_spi_init:qcom_nandc_unalloc (snandc); err_snand_alloc:
@@ -1641,7 +1643,7 @@ static void qcom_spi_remove(struct platform_device *pdev)struct resource *res =platform_get_resource (pdev,IORESOURCE_MEM ,0 );spi_unregister_controller (ctlr); - +nand_ecc_unregister_on_host_hw_engine (&snandc->qspi->ecc_eng);qcom_nandc_unalloc (snandc);clk_disable_unprepare (snandc->aon_clk);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 168/183 drm/amd/amdgpu: Fix missing error return on kzalloc failure
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <[email protected]>
[ Upstream commit 467e00b30dfe75c4cfc2197ceef1fddca06adc25 ]
Currently the kzalloc failure check just sets reports the failure and sets the variable ret to -ENOMEM, which is not checked later for this specific error. Fix this by just returning -ENOMEM rather than setting ret.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c +1 -1
@@ -447,7 +447,7 @@ static int psp_sw_init(struct amdgpu_ip_block *ip_block) psp->cmd =kzalloc (sizeof (struct psp_gfx_cmd_resp ),GFP_KERNEL );if (!psp->cmd) {dev_err (adev->dev,"Failed to allocate memory to command buffer!\n" ); - ret = -ENOMEM ; +return -ENOMEM ; } adev->psp.xgmi_context.supports_extended_data =
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 169/183 tools: gpio: remove the include directory on make clean
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: zhang jiao <[email protected]>
[ Upstream commit ed42d80f3bae89592fbb2ffaf8b6b2e720d53f6a ]
Remove the generated include directory when running make clean.
--- tools/gpio/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/gpio/Makefile +1 -1
@@ -77,7 +77,7 @@ $(OUTPUT)gpio-watch: $(GPIO_WATCH_IN) clean: rm -f $(ALL_PROGRAMS) - rm -f $(OUTPUT)include/linux/gpio.h + rm -rf $(OUTPUT)include find $(or $(OUTPUT),.) -name '*.o' -delete -o -name '\.*.d' -delete -o -name '\.*.cmd' -delete install: $(ALL_PROGRAMS)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 170/183 md/raid1: fix data lost for writemostly rdev
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Kuai <[email protected]>
[ Upstream commit 93dec51e716db88f32d770dc9ab268964fff320b ]
If writemostly is enabled, alloc_behind_master_bio() will allocate a new bio for rdev, with bi_opf set to 0. Later, raid1_write_request() will clone from this bio, hence bi_opf is still 0 for the cloned bio. Submit this cloned bio will end up to be read, causing write data lost.
Fix this problem by inheriting bi_opf from original bio for behind_mast_bio.
--- drivers/md/raid1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/raid1.c +1 -1
@@ -1226,7 +1226,7 @@ static void alloc_behind_master_bio(struct r1bio *r1_bio,int i =0 ;struct bio *behind_bio =NULL ; - behind_bio =bio_alloc_bioset (NULL , vcnt,0 ,GFP_NOIO , + behind_bio =bio_alloc_bioset (NULL , vcnt, bio->bi_opf,GFP_NOIO , &r1_bio->mddev->bio_set);/* discard op, we don't support writezero/writesame yet */
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 171/183 md: prevent incorrect update of resync/recovery offset
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Nan <[email protected]>
[ Upstream commit 7202082b7b7a256d04ec96131c7f859df0a79f64 ]
In md_do_sync(), when md_sync_action returns ACTION_FROZEN, subsequent call to md_sync_position() will return MaxSector. This causes 'curr_resync' (and later 'recovery_offset') to be set to MaxSector too, which incorrectly signals that recovery/resync has completed, even though disk data has not actually been updated.
To fix this issue, skip updating any offset values when the sync action is FROZEN. The same holds true for IDLE.
--- drivers/md/md.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/md/md.c +5 -0
@@ -9089,6 +9089,11 @@ void md_do_sync(struct md_thread *thread) } action =md_sync_action (mddev); +if (action ==ACTION_FROZEN || action ==ACTION_IDLE ) { +set_bit (MD_RECOVERY_INTR , &mddev->recovery); + goto skip; + } + desc =md_sync_action_name (action); mddev->last_sync_action = action;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 172/183 drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ville Syrjälä <[email protected]>
[ Upstream commit d6e020819612a4a06207af858e0978be4d3e3140 ]
The intel-media-driver is currently broken on DG1 because it uses EXEC_CAPTURE with recovarable contexts. Relax the check to allow that.
I've also submitted a fix for the intel-media-driver:
https://github.com/intel/media-driver/pull/1920
Cc: [email protected] # v6.0+
Cc: Matthew Auld <[email protected]>
Cc: Thomas Hellström <[email protected]>
Testcase: igt/gem_exec_capture/capture-invisible
--- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +1 -1
@@ -2013,7 +2013,7 @@ static int eb_capture_stage(struct i915_execbuffer *eb)continue ;if (i915_gem_context_is_recoverable (eb->gem_context) && - (IS_DGFX (eb->i915) ||GRAPHICS_VER_FULL (eb->i915) >IP_VER (12 ,0 ))) +GRAPHICS_VER_FULL (eb->i915) >IP_VER (12 ,10 ))return -EINVAL ;for_each_batch_create_order (eb, j) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 173/183 ACPI: RISC-V: Fix FFH_CPPC_CSR error handling
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anup Patel <[email protected]>
commit 5b3706597b90a7b6c9ae148edd07a43531dcd49e upstream.
The cppc_ffh_csr_read() and cppc_ffh_csr_write() returns Linux error code in "data->ret.error" so cpc_read_ffh() and cpc_write_ffh() must not use sbi_err_map_linux_errno() for FFH_CPPC_CSR.
--- drivers/acpi/riscv/cppc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/acpi/riscv/cppc.c +2 -2
@@ -119,7 +119,7 @@ int cpc_read_ffh(int cpu, struct cpc_reg *val = data.ret.value; -return (data.ret.error) ?sbi_err_map_linux_errno (data.ret.error) :0 ; +return data.ret.error; }return -EINVAL ;
@@ -148,7 +148,7 @@ int cpc_write_ffh(int cpu, struct cpc_resmp_call_function_single (cpu, cppc_ffh_csr_write, &data,1 ); -return (data.ret.error) ?sbi_err_map_linux_errno (data.ret.error) :0 ; +return data.ret.error; }return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 174/183 riscv: Only allow LTO with CMODEL_MEDANY
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 41f9049cff324b7033e6ed1ded7dfff803cf550a upstream.
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.
--- arch/riscv/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/Kconfig +1 -1
@@ -69,7 +69,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
Greg Kroah-Hartman
maintainerPATCH 175/183 riscv: uaccess: fix __put_user_nocheck for unaligned accesses
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aurelien Jarno <[email protected]>
commit 1046791390af6703a5e24718a16f37974adb11db upstream.
The type of the value to write should be determined by the size of the destination, not by the value itself, which may be a constant. This aligns the behavior with x86_64, where __typeof__(*(__gu_ptr)) is used to infer the correct type.
This fixes an issue in put_cmsg, which was only writing 4 out of 8 bytes to the cmsg_len field, causing the glibc tst-socket-timestamp test to fail.
--- arch/riscv/include/asm/uaccess.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/uaccess.h +1 -1
@@ -311,7 +311,7 @@ do { \ do { \ if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && \ !IS_ALIGNED((uintptr_t)__gu_ptr, sizeof(*__gu_ptr))) { \ - __inttype(x) ___val = (__inttype(x))x; \ + __typeof__(*(__gu_ptr)) ___val = (x); \ if (__asm_copy_to_user_sum_enabled(__gu_ptr, &(___val), sizeof(*__gu_ptr))) \ goto label; \ break; \
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 176/183 riscv: use lw when reading int cpu in new_vmalloc_check
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Radim Krčmář <[email protected]>
commit e108c8a94f3f958c877f6ec7a6052a893ae4aa98 upstream.
REG_L is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine.
--- arch/riscv/kernel/entry.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/kernel/entry.S +1 -1
@@ -46,7 +46,7 @@ * a0 = &new_vmalloc[BIT_WORD(cpu)] * a1 = BIT_MASK(cpu) */ - REG_L a2, TASK_TI_CPU(tp) + lw a2, TASK_TI_CPU(tp) /* * Compute the new_vmalloc element position: * (cpu / 64) * 8 = (cpu >> 6) << 3
Greg Kroah-Hartman
maintainerPATCH 177/183 riscv: use lw when reading int cpu in asm_per_cpu
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Radim Krčmář <[email protected]>
commit f4ea67a722e8c9e1fb8109adebb9fb881ff0793a upstream.
REG_L is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine.
--- arch/riscv/include/asm/asm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/asm.h +1 -1
@@ -91,7 +91,7 @@#endif .macro asm_per_cpu dst sym tmp - REG_L \tmp, TASK_TI_CPU_NUM(tp) + lw \tmp, TASK_TI_CPU_NUM(tp) slli \tmp, \tmp, PER_CPU_OFFSET_SHIFT la \dst, __per_cpu_offset add \dst, \dst, \tmp
Greg Kroah-Hartman
maintainerPATCH 178/183 riscv, bpf: use lw when reading int cpu in BPF_MOV64_PERCPU_REG
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Radim Krčmář <[email protected]>
commit ad5348c765914766a98ad26cf7a8c28d51a16bdd upstream.
emit_ld is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine.
--- arch/riscv/net/bpf_jit_comp64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/net/bpf_jit_comp64.c +1 -1
@@ -1356,7 +1356,7 @@ int bpf_jit_emit_insn(const struct bpf_iemit_mv (rd, rs, ctx);#ifdef CONFIG_SMP /* Load current CPU number in T1 */ -emit_ld (RV_REG_T1 , offsetof(struct thread_info , cpu), +emit_lw (RV_REG_T1 , offsetof(struct thread_info , cpu),RV_REG_TP , ctx);/* Load address of __per_cpu_offset array in T2 */ emit_addr (RV_REG_T2 , (u64)&__per_cpu_offset, extra_pass, ctx);
Greg Kroah-Hartman
maintainerPATCH 179/183 riscv, bpf: use lw when reading int cpu in bpf_get_smp_processor_id
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Radim Krčmář <[email protected]>
commit 8a16586fa7b8a01360890d284896b90c217dca44 upstream.
emit_ld is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine.
--- arch/riscv/net/bpf_jit_comp64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/net/bpf_jit_comp64.c +1 -1
@@ -1763,7 +1763,7 @@ int bpf_jit_emit_insn(const struct bpf_i*/ if (insn->src_reg ==0 && insn->imm == BPF_FUNC_get_smp_processor_id) {/* Load current CPU number in R0 */ -emit_ld (bpf_to_rv_reg (BPF_REG_0 , ctx), offsetof(struct thread_info , cpu), +emit_lw (bpf_to_rv_reg (BPF_REG_0 , ctx), offsetof(struct thread_info , cpu),RV_REG_TP , ctx);break ; }
Greg Kroah-Hartman
maintainerPATCH 180/183 riscv: kexec: Initialize kexec_buf struct
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
commit 95c54cd9c769a198118772e196adfaa1f002e365 upstream.
The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage.
This is also triggering a UBSAN warning when the uninitialized data was accessed:
------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool'
Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used.
--- arch/riscv/kernel/kexec_elf.c | 4 ++-- arch/riscv/kernel/kexec_image.c | 2 +- arch/riscv/kernel/machine_kexec_file.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-)
arch/riscv/kernel/kexec_elf.c +2 -2
@@ -28,7 +28,7 @@ static int riscv_kexec_elf_load(struct kimage *image, struct elfhdr *ehdr,int i;int ret =0 ;size_t size; -struct kexec_buf kbuf; +struct kexec_buf kbuf = {};const struct elf_phdr *phdr; kbuf.image = image;
@@ -66,7 +66,7 @@ static int elf_find_pbase(struct kimage *image, unsigned long kernel_len, {int i;int ret; -struct kexec_buf kbuf; +struct kexec_buf kbuf = {};const struct elf_phdr *phdr;unsigned long lowest_paddr =ULONG_MAX ;unsigned long lowest_vaddr =ULONG_MAX ;
arch/riscv/kernel/kexec_image.c +1 -1
@@ -41,7 +41,7 @@ static void *image_load(struct kimage *image,struct riscv_image_header *h;u64 flags;bool be_image, be_kernel; -struct kexec_buf kbuf; +struct kexec_buf kbuf = {};int ret;/* Check Image header */
arch/riscv/kernel/machine_kexec_file.c +1 -1
@@ -261,7 +261,7 @@ int load_extra_segments(struct kimage *image, unsigned long kernel_start,int ret;void *fdt;unsigned long initrd_pbase =0UL ; -struct kexec_buf kbuf; +struct kexec_buf kbuf = {};char *modified_cmdline =NULL ; kbuf.image = image;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 181/183 riscv: Fix sparse warning in __get_user_error()
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Ghiti <[email protected]>
commit fef7ded169ed7e133612f90a032dc2af1ce19bef upstream.
We used to assign 0 to x without an appropriate cast which results in sparse complaining when x is a pointer:
Quoted 1 line
Quoted 1 line
block/ioctl.c:72:39: sparse: sparse: Using plain integer as NULL pointer
So fix this by casting 0 to the correct type of x.
--- arch/riscv/include/asm/uaccess.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/uaccess.h +1 -1
@@ -209,7 +209,7 @@ do { \ err =0 ; \break ; \ __gu_failed: \ - x =0 ; \ + x = (__typeof__ (x ))0 ; \ err = -EFAULT ; \ }while (0 )
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 182/183 riscv: Fix sparse warning about different address spaces
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Ghiti <[email protected]>
commit a03ee11b8f850bd008226c6d392da24163dfb56e upstream.
We did not propagate the __user attribute of the pointers in __get_kernel_nofault() and __put_kernel_nofault(), which results in sparse complaining:
Quoted 1 line
Quoted 1 line
mm/maccess.c:41:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const [noderef]__user*from @@ got unsigned long long [usertype] * @@
mm/maccess.c:41:17: sparse: expected void const [noderef] __user *from
mm/maccess.c:41:17: sparse: got unsigned long long [usertype] *
So fix this by correctly casting those pointers.
--- arch/riscv/include/asm/uaccess.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/riscv/include/asm/uaccess.h +2 -2
@@ -438,10 +438,10 @@ unsigned long __must_check clear_user(vo }#define __get_kernel_nofault (dst, src, type, err_label) \ - __get_user_nocheck(*((type *)(dst)), (type *)(src), err_label) + __get_user_nocheck(*((type *)(dst)), (__force __user type *)(src), err_label)#define __put_kernel_nofault (dst, src, type, err_label) \ - __put_user_nocheck(*((type *)(src)), (type *)(dst), err_label) + __put_user_nocheck(*((type *)(src)), (__force __user type *)(dst), err_label) static __must_check __always_inline bool user_access_begin(const void __user *ptr, size_t len) {
Greg Kroah-Hartman
maintainerPATCH 183/183 Revert "drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1"
In reply to Greg Kroah-Hartman6.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joonas Lahtinen <[email protected]>
[ Upstream commit d2dc30e0aa252830f908c8e793d3139d51321370 ]
This reverts commit d6e020819612a4a06207af858e0978be4d3e3140.
The IS_DGFX check was put in place because error capture of buffer objects is expected to be broken on devices with VRAM.
Userspace fix[1] to the impacted media driver has been submitted, merged and a new driver release is out as 25.2.3 where the capture flag is dropped on DG1 thus unblocking the usage of media driver on DG1.
[1] https://github.com/intel/media-driver/commit/93c07d9b4b96a78bab21f6acd4eb863f4313ea4a
--- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +1 -1
@@ -2013,7 +2013,7 @@ static int eb_capture_stage(struct i915_execbuffer *eb)continue ;if (i915_gem_context_is_recoverable (eb->gem_context) && -GRAPHICS_VER_FULL (eb->i915) >IP_VER (12 ,10 )) + (IS_DGFX (eb->i915) ||GRAPHICS_VER_FULL (eb->i915) >IP_VER (12 ,0 )))return -EINVAL ;for_each_batch_create_order (eb, j) {
Signature · 1 line
2.51.0
Hi
no regressions here on x86_64 (RKL, Intel 11th Gen. CPU)
Thanks
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.16.y
and the diffstat can be found below.thanks,
greg k-h
6.16.6-rc1 tested.
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)
[ 0.000000] Linux version 6.16.6-rc1rv-g665877a17a1b
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 15.2.1 20250813, GNU ld (GNU Binutils) 2.45.0) #1 SMP PREEMPT_DYNAMIC Mon Sep 8 11:19:48 JST 2025
Thanks
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.16.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.16.y
and the diffstat can be found below.thanks,
greg k-h
Thanks! Build-tested on all Alpine architectures and boot tested on x86_64.
# Librecast Test Results
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.16.6-rc1-g665877a17a1b #62 SMP PREEMPT_DYNAMIC Mon Sep 8 06:39:13 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Quoted 8 lines · On Sun, 07 Sep 2025 21:57:07 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for loongarch64:
Thanks!
Cheers,
Miguel
Am 07.09.2025 um 21:57 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.16.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.16:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
120 tests: 120 pass, 0 failLinux version: 6.16.6-rc1-g665877a17a1b
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
Hi Greg
6.16.6-rc1 compiles on x86_64 (Xeon E5-1620 v2, Slackware64-15.0), and boots & runs on x86_64 (AMD Ryzen 5 7520U, Slackware64-current). No regressions observed.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.16.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.16.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.16.y
and the diffstat can be found below.thanks,
greg k-h
Build and boot tested 6.16.6-rc1 using qemu-x86_64. The kernel was successfully built and booted in a virtualized environment without issues.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.16.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.16.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.16.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.16.6-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 665877a17a1b1f125d4ad586fb5f032accb7d853
* git describe: v6.16.4-327-g665877a17a1b
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.16.y/build/v6.16.4-327-g665877a17a1b
## Test Regressions (compared to v6.16.4-143-g6a02da415966)
## Metric Regressions (compared to v6.16.4-143-g6a02da415966)
## Test Fixes (compared to v6.16.4-143-g6a02da415966)
## Metric Fixes (compared to v6.16.4-143-g6a02da415966)
## Test result summary
total: 348600, pass: 321208, fail: 6791, skip: 20601, xfail: 0
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 138 passed, 1 failed
* arm64: 57 total, 56 passed, 1 failed
* i386: 18 total, 18 passed, 0 failed
* mips: 34 total, 27 passed, 7 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 40 total, 39 passed, 1 failed
* riscv: 25 total, 24 passed, 1 failed
* s390: 22 total, 22 passed, 0 failed
* sh: 5 total, 5 passed, 0 failed
* sparc: 4 total, 3 passed, 1 failed
* x86_64: 49 total, 48 passed, 1 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mm
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-rust
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* modules
* perf
* rcutorture
* rt-tests-cyclicdeadline
* rt-tests-pi-stress
* rt-tests-pmqtest
* rt-tests-rt-migrate-test
* rt-tests-signaltest
--
Linaro LKFT
https://lkft.linaro.org
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.16.6 release. There are 183 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 09 Sep 2025 19:55:53 +0000. Anything received after that time might be too late.
Tested on the following hardware:
* a ThinkPad E14 Gen 3 with a AMD Ryzen 5 5500U CPU
* a Framework Laptop with a Ryzen AI 5 340
* a Framework Desktop
* a Steam Deck (LCD Edition)
The kernel, bpf tool, perf tool, and kselftest builds fine for v6.16.6-rc1 on x86 and arm64 Azure VM.
Thanks,
Hardik