5.10.219-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 275/317 f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
commit 20faaf30e55522bba2b56d9c46689233205d7717 upstream.
syzbot reports a kernel bug as below:
F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4
==================================================================
BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline] BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076 CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline] f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838 __do_sys_ioctl fs/ioctl.c:902 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
The root cause is we missed to do sanity check on i_xattr_nid during f2fs_iget(), so that in fiemap() path, current_nat_addr() will access nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering kasan bug report, fix it.
--- fs/f2fs/inode.c | 6 ++++++ 1 file changed, 6 insertions(+)
fs/f2fs/inode.c +6 -0
@@ -326,6 +326,12 @@ static bool sanity_check_inode(struct in } } +if (fi->i_xattr_nid &&f2fs_check_nid_range (sbi, fi->i_xattr_nid)) { +f2fs_warn (sbi,"%s: inode (ino=%lx) has corrupted i_xattr_nid: %u, run fsck to fix." , + __func__, inode->i_ino, fi->i_xattr_nid); +return false; + } +return true; }
Greg Kroah-Hartman
maintainerPATCH 276/317 media: lgdt3306a: Add a check against null-pointer-def
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zheyu Ma <[email protected]>
commit c1115ddbda9c930fba0fdd062e7a8873ebaf898d upstream.
The driver should check whether the client provides the platform_data.
The following log reveals it:
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasan_report+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasan_check_range+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306a_probe+0x52/0x310 [ 29.616339] i2c_device_probe+0x951/0xa90
--- drivers/media/dvb-frontends/lgdt3306a.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/media/dvb-frontends/lgdt3306a.c +5 -0
@@ -2213,6 +2213,11 @@ static int lgdt3306a_probe(struct i2c_clstruct dvb_frontend *fe;int ret; +if (!client->dev.platform_data) { +dev_err (&client->dev,"platform data is mandatory\n" ); +return -EINVAL ; + } + config =kmemdup (client->dev.platform_data,sizeof (struct lgdt3306a_config ),GFP_KERNEL );if (config ==NULL ) {
Greg Kroah-Hartman
maintainerPATCH 277/317 drm/amdgpu: add error handle to avoid out-of-bounds
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bob Zhou <[email protected]>
commit 8b2faf1a4f3b6c748c0da36cda865a226534d520 upstream.
if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should be stop to avoid out-of-bounds read, so directly return -EINVAL.
--- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c +3 -0
@@ -2073,6 +2073,9 @@ static int sdma_v4_0_process_trap_irq(stDRM_DEBUG ("IH: SDMA trap\n" ); instance =sdma_v4_0_irq_id_to_seq (entry->client_id); +if (instance <0 ) +return instance; +switch (entry->ring_id) {case 0 :amdgpu_fence_process (&adev->sdma.instance[instance].ring);
Greg Kroah-Hartman
maintainerPATCH 278/317 ata: pata_legacy: make legacy_exit() work again
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Shtylyov <[email protected]>
commit d4a89339f17c87c4990070e9116462d16e75894f upstream.
Commit defc9cd826e4 ("pata_legacy: resychronize with upstream changes and resubmit") missed to update legacy_exit(), so that it now fails to do any cleanup -- the loop body there can never be entered. Fix that and finally remove now useless nr_legacy_host variable...
Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.
--- drivers/ata/pata_legacy.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/ata/pata_legacy.c +4 -4
@@ -114,8 +114,6 @@ static int legacy_port[NR_HOST] = { 0x1fstatic struct legacy_probe probe_list[NR_HOST ];static struct legacy_data legacy_data[NR_HOST ];static struct ata_host *legacy_host[NR_HOST ]; -static int nr_legacy_host; -static int probe_all;/* Set to check all ISA port ranges */ static int ht6560a;/* HT 6560A on primary 1, second 2, both 3 */
@@ -1239,9 +1237,11 @@ static __exit void legacy_exit(void) {int i; -for (i =0 ; i < nr_legacy_host; i++) { +for (i =0 ; i <NR_HOST ; i++) {struct legacy_data *ld = &legacy_data[i]; -ata_host_detach (legacy_host[i]); + +if (legacy_host[i]) +ata_host_detach (legacy_host[i]);platform_device_unregister (ld->platform_dev); } }
Greg Kroah-Hartman
maintainerPATCH 279/317 ACPI: resource: Do IRQ override on TongFang GXxHRXx and GMxHGxx
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoffer Sandberg <[email protected]>
commit c81bf14f9db68311c2e75428eea070d97d603975 upstream.
Listed devices need the override for the keyboard to work.
--- drivers/acpi/resource.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/acpi/resource.c +12 -0
@@ -475,6 +475,18 @@ static const struct dmi_system_id asus_l DMI_MATCH(DMI_BOARD_NAME, "B2502CBA"), }, }, + { +/* TongFang GXxHRXx/TUXEDO InfinityBook Pro Gen9 AMD */ + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "GXxHRXx"), + }, + }, + { +/* TongFang GMxHGxx/TUXEDO Stellaris Slim Gen1 AMD */ + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "GMxHGxx"), + }, + }, { } };
Greg Kroah-Hartman
maintainerPATCH 280/317 arm64: tegra: Correct Tegra132 I2C alias
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 2633c58e1354d7de2c8e7be8bdb6f68a0a01bad7 upstream.
There is no such device as "as3722@40", because its name is "pmic". Use phandles for aliases to fix relying on full node path. This corrects aliases for RTC devices and also fixes dtc W=1 warning:
tegra132-norrin.dts:12.3-36: Warning (alias_paths): /aliases:rtc0: aliases property is not a valid node (/i2c@7000d000/as3722@40)
--- arch/arm64/boot/dts/nvidia/tegra132-norrin.dts | 4 ++-- arch/arm64/boot/dts/nvidia/tegra132.dtsi | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/nvidia/tegra132-norrin.dts +2 -2
@@ -9,8 +9,8 @@ compatible = "nvidia,norrin", "nvidia,tegra132", "nvidia,tegra124"; aliases { - rtc0 = "/i2c@7000d000/as3722@40"; - rtc1 = "/rtc@7000e000"; + rtc0 = &as3722; + rtc1 = &tegra_rtc; serial0 = &uarta; };
arch/arm64/boot/dts/nvidia/tegra132.dtsi +1 -1
@@ -573,7 +573,7 @@ status = "disabled"; }; - rtc@7000e000 { + tegra_rtc: rtc@7000e000 { compatible = "nvidia,tegra124-rtc", "nvidia,tegra20-rtc"; reg = <0x0 0x7000e000 0x0 0x100>; interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
Greg Kroah-Hartman
maintainerPATCH 281/317 arm64: dts: qcom: qcs404: fix bluetooth device address
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit f5f390a77f18eaeb2c93211a1b7c5e66b5acd423 upstream.
The 'local-bd-address' property is used to pass a unique Bluetooth device address from the boot firmware to the kernel and should otherwise be left unset so that the OS can prevent the controller from being used until a valid address has been provided through some other means (e.g. using btmgmt).
--- arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi +1 -1
@@ -60,7 +60,7 @@ vddrf-supply = <&vreg_l1_1p3>; vddch0-supply = <&vdd_ch0_3p3>; - local-bd-address = [ 02 00 00 00 5a ad ]; + local-bd-address = [ 00 00 00 00 00 00 ]; max-speed = <3200000>; };
Greg Kroah-Hartman
maintainerPATCH 282/317 md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Kuai <[email protected]>
commit 151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa upstream.
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released.
Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well.
--- drivers/md/raid5.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-)
drivers/md/raid5.c +3 -12
@@ -36,7 +36,6 @@*/ #include <linux/blkdev.h> -#include <linux/delay.h> #include <linux/kthread.h> #include <linux/raid/pq.h> #include <linux/async_tx.h>
@@ -6484,6 +6483,9 @@ static void raid5d(struct md_thread *thrint batch_size, released;unsigned int offset; +if (test_bit (MD_SB_CHANGE_PENDING , &mddev->sb_flags)) +break ; + released =release_stripe_list (conf, conf->temp_inactive_list);if (released)clear_bit (R5_DID_ALLOC , &conf->cache_state);
@@ -6520,18 +6522,7 @@ static void raid5d(struct md_thread *thrspin_unlock_irq (&conf->device_lock);md_check_recovery (mddev);spin_lock_irq (&conf->device_lock); - -/* -* Waiting on MD_SB_CHANGE_PENDING below may deadlock -* seeing md_check_recovery() is needed to clear -* the flag when using mdmon. -*/ -continue ; } - -wait_event_lock_irq (mddev->sb_wait, - !test_bit (MD_SB_CHANGE_PENDING , &mddev->sb_flags), - conf->device_lock); }pr_debug ("%d stripes handled\n" , handled);
Greg Kroah-Hartman
maintainerPATCH 283/317 wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AU
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <[email protected]>
commit 08b5d052d17a89bb8706b2888277d0b682dc1610 upstream.
Don't subtract 1 from the power index. This was added in commit 2fc0b8e5a17d ("rtl8xxxu: Add TX power base values for gen1 parts") for unknown reasons. The vendor drivers don't do this.
Also correct the calculations of values written to REG_OFDM0_X{C,D}_TX_IQ_IMBALANCE. According to the vendor driver, these are used for TX power training.
With these changes rtl8xxxu sets the TX power of RTL8192CU the same as the vendor driver.
None of this appears to have any effect on my RTL8192CU device.
--- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 26 +++++++----------- 1 file changed, 11 insertions(+), 15 deletions(-)
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +11 -15
@@ -28,6 +28,7 @@#include <linux/wireless.h> #include <linux/firmware.h> #include <linux/moduleparam.h> +#include <linux/bitfield.h> #include <net/mac80211.h> #include "rtl8xxxu.h" #include "rtl8xxxu_regs.h"
@@ -1389,13 +1390,13 @@ rtl8xxxu_gen1_set_tx_power(struct rtl8xxu8 cck[RTL8723A_MAX_RF_PATHS ], ofdm[RTL8723A_MAX_RF_PATHS ];u8 ofdmbase[RTL8723A_MAX_RF_PATHS ], mcsbase[RTL8723A_MAX_RF_PATHS ];u32 val32, ofdm_a, ofdm_b, mcs_a, mcs_b; -u8 val8; +u8 val8, base;int group, i; group =rtl8xxxu_gen1_channel_to_group (channel); - cck[0 ] = priv->cck_tx_power_index_A[group] -1 ; - cck[1 ] = priv->cck_tx_power_index_B[group] -1 ; + cck[0 ] = priv->cck_tx_power_index_A[group]; + cck[1 ] = priv->cck_tx_power_index_B[group];if (priv->hi_pa) {if (cck[0 ] >0x20 )
@@ -1406,10 +1407,6 @@ rtl8xxxu_gen1_set_tx_power(struct rtl8xx ofdm[0 ] = priv->ht40_1s_tx_power_index_A[group]; ofdm[1 ] = priv->ht40_1s_tx_power_index_B[group]; -if (ofdm[0 ]) - ofdm[0 ] -=1 ; -if (ofdm[1 ]) - ofdm[1 ] -=1 ; ofdmbase[0 ] = ofdm[0 ] + priv->ofdm_tx_power_index_diff[group].a; ofdmbase[1 ] = ofdm[1 ] + priv->ofdm_tx_power_index_diff[group].b;
@@ -1498,20 +1495,19 @@ rtl8xxxu_gen1_set_tx_power(struct rtl8xxrtl8xxxu_write32 (priv,REG_TX_AGC_A_MCS15_MCS12 , mcs_a + power_base->reg_0e1c); + val8 =u32_get_bits (mcs_a + power_base->reg_0e1c,0xff000000 );for (i =0 ; i <3 ; i++) { -if (i !=2 ) - val8 = (mcsbase[0 ] >8 ) ? (mcsbase[0 ] -8 ) :0 ; -else - val8 = (mcsbase[0 ] >6 ) ? (mcsbase[0 ] -6 ) :0 ; + base = i !=2 ?8 :6 ; + val8 =max_t (int, val8 - base,0 );rtl8xxxu_write8 (priv,REG_OFDM0_XC_TX_IQ_IMBALANCE + i, val8); } +rtl8xxxu_write32 (priv,REG_TX_AGC_B_MCS15_MCS12 , mcs_b + power_base->reg_0868); + val8 =u32_get_bits (mcs_b + power_base->reg_0868,0xff000000 );for (i =0 ; i <3 ; i++) { -if (i !=2 ) - val8 = (mcsbase[1 ] >8 ) ? (mcsbase[1 ] -8 ) :0 ; -else - val8 = (mcsbase[1 ] >6 ) ? (mcsbase[1 ] -6 ) :0 ; + base = i !=2 ?8 :6 ; + val8 =max_t (int, val8 - base,0 );rtl8xxxu_write8 (priv,REG_OFDM0_XD_TX_IQ_IMBALANCE + i, val8); } }
Greg Kroah-Hartman
maintainerPATCH 284/317 wifi: rtlwifi: rtl8192de: Fix low speed with WPA3-SAE
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <[email protected]>
commit a7c0f48410f546772ac94a0f7b7291a15c4fc173 upstream.
Some (all?) management frames are incorrectly reported to mac80211 as decrypted when actually the hardware did not decrypt them. This results in speeds 3-5 times lower than expected, 20-30 Mbps instead of 100 Mbps.
Fix this by checking the encryption type field of the RX descriptor. rtw88 does the same thing.
This fix was tested only with rtl8192du, which will use the same code.
--- drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 5 ++--- drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h | 14 ++++++++++++++ 2 files changed, 16 insertions(+), 3 deletions(-)
drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c +2 -3
@@ -414,7 +414,8 @@ bool rtl92de_rx_query_desc(struct ieee80 stats->icv = (u16 )get_rx_desc_icv (pdesc); stats->crc = (u16 )get_rx_desc_crc32 (pdesc); stats->hwerror = (stats->crc | stats->icv); - stats->decrypted = !get_rx_desc_swdec (pdesc); + stats->decrypted = !get_rx_desc_swdec (pdesc) && +get_rx_desc_enc_type (pdesc) !=RX_DESC_ENC_NONE ; stats->rate = (u8 )get_rx_desc_rxmcs (pdesc); stats->shortpreamble = (u16 )get_rx_desc_splcp (pdesc); stats->isampdu = (bool )(get_rx_desc_paggr (pdesc) ==1 );
@@ -427,8 +428,6 @@ bool rtl92de_rx_query_desc(struct ieee80 rx_status->band = hw->conf.chandef.chan->band;if (get_rx_desc_crc32 (pdesc)) rx_status->flag |=RX_FLAG_FAILED_FCS_CRC ; -if (!get_rx_desc_swdec (pdesc)) - rx_status->flag |=RX_FLAG_DECRYPTED ;if (get_rx_desc_bw (pdesc)) rx_status->bw =RATE_INFO_BW_40 ;if (get_rx_desc_rxht (pdesc))
drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h +14 -0
@@ -14,6 +14,15 @@#define USB_HWDESC_HEADER_LEN 32#define CRCLENGTH 4 +enum rtl92d_rx_desc_enc { +RX_DESC_ENC_NONE =0 , +RX_DESC_ENC_WEP40 =1 , +RX_DESC_ENC_TKIP_WO_MIC =2 , +RX_DESC_ENC_TKIP_MIC =3 , +RX_DESC_ENC_AES =4 , +RX_DESC_ENC_WEP104 =5 , +}; +/* macros to read/write various fields in RX or TX descriptors */ static inline void set_tx_desc_pkt_size (__le32 *__pdesc,u32 __val)
@@ -246,6 +255,11 @@ static inline u32 get_rx_desc_drv_info_sreturn le32_get_bits (*__pdesc,GENMASK (19 ,16 )); } +static inline u32 get_rx_desc_enc_type (__le32 *__pdesc) +{ +return le32_get_bits (*__pdesc,GENMASK (22 ,20 )); +} +static inline u32 get_rx_desc_shift (__le32 *__pdesc) {return le32_get_bits (*__pdesc,GENMASK (25 ,24 ));
Greg Kroah-Hartman
maintainerPATCH 285/317 wifi: rtlwifi: rtl8192de: Fix endianness issue in RX path
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <[email protected]>
commit 2f228d364da95ab58f63a3fedc00d5b2b7db16ab upstream.
Structs rx_desc_92d and rx_fwinfo_92d will not work for big endian systems.
Delete rx_desc_92d because it's big and barely used, and instead use the get_rx_desc_rxmcs and get_rx_desc_rxht functions, which work on big endian systems too.
Fix rx_fwinfo_92d by duplicating four of its members in the correct order.
Tested only with RTL8192DU, which will use the same code. Tested only on a little endian system.
--- drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 16 ++-- drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h | 65 ++----------------- 2 files changed, 15 insertions(+), 66 deletions(-)
drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c +8 -8
@@ -35,7 +35,7 @@ static long _rtl92de_translate_todbm(str static void _rtl92de_query_rxphystatus(struct ieee80211_hw *hw, struct rtl_stats *pstats, - struct rx_desc_92d *pdesc, + __le32 *pdesc, struct rx_fwinfo_92d *p_drvinfo, bool packet_match_bssid, bool packet_toself,
@@ -49,8 +49,10 @@ static void _rtl92de_query_rxphystatus(su8 i, max_spatial_stream;u32 rssi, total_rssi =0 ;bool is_cck_rate; +u8 rxmcs; - is_cck_rate =RX_HAL_IS_CCK_RATE (pdesc->rxmcs); + rxmcs =get_rx_desc_rxmcs (pdesc); + is_cck_rate = rxmcs <=DESC_RATE11M ; pstats->packet_matchbssid = packet_match_bssid; pstats->packet_toself = packet_toself; pstats->packet_beacon = packet_beacon;
@@ -158,8 +160,8 @@ static void _rtl92de_query_rxphystatus(s pstats->rx_pwdb_all = pwdb_all; pstats->rxpower = rx_pwr_all; pstats->recvsignalpower = rx_pwr_all; -if (pdesc->rxht && pdesc->rxmcs >=DESC_RATEMCS8 && - pdesc->rxmcs <=DESC_RATEMCS15 ) +if (get_rx_desc_rxht (pdesc) && rxmcs >=DESC_RATEMCS8 && + rxmcs <=DESC_RATEMCS15 ) max_spatial_stream =2 ;else max_spatial_stream =1 ;
@@ -365,7 +367,7 @@ static void _rtl92de_process_phyinfo(strstatic void _rtl92de_translate_rx_signal_stuff (struct ieee80211_hw *hw,struct sk_buff *skb,struct rtl_stats *pstats, -struct rx_desc_92d *pdesc, +__le32 *pdesc,struct rx_fwinfo_92d *p_drvinfo) {struct rtl_mac *mac =rtl_mac (rtl_priv (hw));
@@ -441,9 +443,7 @@ bool rtl92de_rx_query_desc(struct ieee80if (phystatus) { p_drvinfo = (struct rx_fwinfo_92d *)(skb->data + stats->rx_bufshift); -_rtl92de_translate_rx_signal_stuff (hw, - skb, stats, - (struct rx_desc_92d *)pdesc, +_rtl92de_translate_rx_signal_stuff (hw, skb, stats, pdesc, p_drvinfo); }/*rx_status->qual = stats->signal; */
drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h +7 -58
81 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 286/317 arm64: dts: hi3798cv200: fix the size of GICR
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Xiwen <[email protected]>
commit 428a575dc9038846ad259466d5ba109858c0a023 upstream.
During boot, Linux kernel complains:
[ 0.000000] GIC: GICv2 detected, but range too small and irqchip.gicv2_force_probe not set
This SoC is using a regular GIC-400 and the GICR space size should be 8KB rather than 256B.
With this patch:
[ 0.000000] GIC: Using split EOI/Deactivate mode
So this should be the correct fix.
--- arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi +1 -1
@@ -58,7 +58,7 @@ gic: interrupt-controller@f1001000 { compatible = "arm,gic-400"; reg = <0x0 0xf1001000 0x0 0x1000>, /* GICD */ - <0x0 0xf1002000 0x0 0x100>; /* GICC */ + <0x0 0xf1002000 0x0 0x2000>; /* GICC */ #address-cells = <0>; #interrupt-cells = <3>; interrupt-controller;
Greg Kroah-Hartman
maintainerPATCH 287/317 media: mc: mark the media devnode as registered from the, start
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
commit 4bc60736154bc9e0e39d3b88918f5d3762ebe5e0 upstream.
First the media device node was created, and if successful it was marked as 'registered'. This leaves a small race condition where an application can open the device node and get an error back because the 'registered' flag was not yet set.
Change the order: first set the 'registered' flag, then actually register the media device node. If that fails, then clear the flag.
--- drivers/media/mc/mc-devnode.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/media/mc/mc-devnode.c +2 -3
@@ -246,15 +246,14 @@ int __must_check media_devnode_register(kobject_set_name (&devnode->cdev.kobj,"media%d" , devnode->minor);/* Part 3: Add the media and char device */ +set_bit (MEDIA_FLAG_REGISTERED , &devnode->flags); ret =cdev_device_add (&devnode->cdev, &devnode->dev);if (ret <0 ) { +clear_bit (MEDIA_FLAG_REGISTERED , &devnode->flags);pr_err ("%s: cdev_device_add failed\n" , __func__); goto cdev_add_error; } -/* Part 4: Activate this minor. The char device can now be used. */ -set_bit (MEDIA_FLAG_REGISTERED , &devnode->flags); -return 0 ; cdev_add_error:
Greg Kroah-Hartman
maintainerPATCH 288/317 media: mxl5xx: Move xpt structures off stack
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 526f4527545b2d4ce0733733929fac7b6da09ac6 upstream.
When building for LoongArch with clang 18.0.0, the stack usage of probe() is larger than the allowed 2048 bytes:
drivers/media/dvb-frontends/mxl5xx.c:1698:12: warning: stack frame size (2368) exceeds limit (2048) in 'probe' [-Wframe-larger-than]
1698 | static int probe(struct mxl *state, struct mxl5xx_cfg *cfg)
| ^
1 warning generated.
This is the result of the linked LLVM commit, which changes how the arrays of structures in config_ts() get handled with CONFIG_INIT_STACK_ZERO and CONFIG_INIT_STACK_PATTERN, which causes the above warning in combination with inlining, as config_ts() gets inlined into probe().
This warning can be easily fixed by moving the array of structures off of the stackvia 'static const', which is a better location for these variables anyways because they are static data that is only ever read from, never modified, so allocating the stack space is wasteful.
This drops the stack usage from 2368 bytes to 256 bytes with the same compiler and configuration.
--- drivers/media/dvb-frontends/mxl5xx.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/media/dvb-frontends/mxl5xx.c +11 -11
@@ -1390,57 +1390,57 @@ static int config_ts(struct mxl *state,u32 nco_count_min =0 ;u32 clk_type =0 ; -struct MXL_REG_FIELD_T xpt_sync_polarity[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_sync_polarity[MXL_HYDRA_DEMOD_MAX ] = { {0x90700010 ,8 ,1 }, {0x90700010 ,9 ,1 }, {0x90700010 ,10 ,1 }, {0x90700010 ,11 ,1 }, {0x90700010 ,12 ,1 }, {0x90700010 ,13 ,1 }, {0x90700010 ,14 ,1 }, {0x90700010 ,15 ,1 } }; -struct MXL_REG_FIELD_T xpt_clock_polarity[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_clock_polarity[MXL_HYDRA_DEMOD_MAX ] = { {0x90700010 ,16 ,1 }, {0x90700010 ,17 ,1 }, {0x90700010 ,18 ,1 }, {0x90700010 ,19 ,1 }, {0x90700010 ,20 ,1 }, {0x90700010 ,21 ,1 }, {0x90700010 ,22 ,1 }, {0x90700010 ,23 ,1 } }; -struct MXL_REG_FIELD_T xpt_valid_polarity[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_valid_polarity[MXL_HYDRA_DEMOD_MAX ] = { {0x90700014 ,0 ,1 }, {0x90700014 ,1 ,1 }, {0x90700014 ,2 ,1 }, {0x90700014 ,3 ,1 }, {0x90700014 ,4 ,1 }, {0x90700014 ,5 ,1 }, {0x90700014 ,6 ,1 }, {0x90700014 ,7 ,1 } }; -struct MXL_REG_FIELD_T xpt_ts_clock_phase[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_ts_clock_phase[MXL_HYDRA_DEMOD_MAX ] = { {0x90700018 ,0 ,3 }, {0x90700018 ,4 ,3 }, {0x90700018 ,8 ,3 }, {0x90700018 ,12 ,3 }, {0x90700018 ,16 ,3 }, {0x90700018 ,20 ,3 }, {0x90700018 ,24 ,3 }, {0x90700018 ,28 ,3 } }; -struct MXL_REG_FIELD_T xpt_lsb_first[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_lsb_first[MXL_HYDRA_DEMOD_MAX ] = { {0x9070000C ,16 ,1 }, {0x9070000C ,17 ,1 }, {0x9070000C ,18 ,1 }, {0x9070000C ,19 ,1 }, {0x9070000C ,20 ,1 }, {0x9070000C ,21 ,1 }, {0x9070000C ,22 ,1 }, {0x9070000C ,23 ,1 } }; -struct MXL_REG_FIELD_T xpt_sync_byte[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_sync_byte[MXL_HYDRA_DEMOD_MAX ] = { {0x90700010 ,0 ,1 }, {0x90700010 ,1 ,1 }, {0x90700010 ,2 ,1 }, {0x90700010 ,3 ,1 }, {0x90700010 ,4 ,1 }, {0x90700010 ,5 ,1 }, {0x90700010 ,6 ,1 }, {0x90700010 ,7 ,1 } }; -struct MXL_REG_FIELD_T xpt_enable_output[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_enable_output[MXL_HYDRA_DEMOD_MAX ] = { {0x9070000C ,0 ,1 }, {0x9070000C ,1 ,1 }, {0x9070000C ,2 ,1 }, {0x9070000C ,3 ,1 }, {0x9070000C ,4 ,1 }, {0x9070000C ,5 ,1 }, {0x9070000C ,6 ,1 }, {0x9070000C ,7 ,1 } }; -struct MXL_REG_FIELD_T xpt_err_replace_sync[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_err_replace_sync[MXL_HYDRA_DEMOD_MAX ] = { {0x9070000C ,24 ,1 }, {0x9070000C ,25 ,1 }, {0x9070000C ,26 ,1 }, {0x9070000C ,27 ,1 }, {0x9070000C ,28 ,1 }, {0x9070000C ,29 ,1 }, {0x9070000C ,30 ,1 }, {0x9070000C ,31 ,1 } }; -struct MXL_REG_FIELD_T xpt_err_replace_valid[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_err_replace_valid[MXL_HYDRA_DEMOD_MAX ] = { {0x90700014 ,8 ,1 }, {0x90700014 ,9 ,1 }, {0x90700014 ,10 ,1 }, {0x90700014 ,11 ,1 }, {0x90700014 ,12 ,1 }, {0x90700014 ,13 ,1 }, {0x90700014 ,14 ,1 }, {0x90700014 ,15 ,1 } }; -struct MXL_REG_FIELD_T xpt_continuous_clock[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_continuous_clock[MXL_HYDRA_DEMOD_MAX ] = { {0x907001D4 ,0 ,1 }, {0x907001D4 ,1 ,1 }, {0x907001D4 ,2 ,1 }, {0x907001D4 ,3 ,1 }, {0x907001D4 ,4 ,1 }, {0x907001D4 ,5 ,1 }, {0x907001D4 ,6 ,1 }, {0x907001D4 ,7 ,1 } }; -struct MXL_REG_FIELD_T xpt_nco_clock_rate[MXL_HYDRA_DEMOD_MAX ] = { +static const struct MXL_REG_FIELD_T xpt_nco_clock_rate[MXL_HYDRA_DEMOD_MAX ] = { {0x90700044 ,16 ,80 }, {0x90700044 ,16 ,81 }, {0x90700044 ,16 ,82 }, {0x90700044 ,16 ,83 }, {0x90700044 ,16 ,84 }, {0x90700044 ,16 ,85 },
Greg Kroah-Hartman
maintainerPATCH 289/317 media: v4l2-core: hold videodev_lock until dev reg, finishes
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
commit 1ed4477f2ea4743e7c5e1f9f3722152d14e6eeb1 upstream.
After the new V4L2 device node was registered, some additional initialization was done before the device node was marked as 'registered'. During the time between creating the device node and marking it as 'registered' it was possible to open the device node, which would return -ENODEV since the 'registered' flag was not yet set.
Hold the videodev_lock mutex from just before the device node is registered until the 'registered' flag is set. Since v4l2_open will take the same lock, it will wait until this registration process is finished. This resolves this race condition.
--- drivers/media/v4l2-core/v4l2-dev.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/media/v4l2-core/v4l2-dev.c +3 -0
@@ -1030,8 +1030,10 @@ int __video_register_device(struct video vdev->dev.devt =MKDEV (VIDEO_MAJOR , vdev->minor); vdev->dev.parent = vdev->dev_parent;dev_set_name (&vdev->dev,"%s%d" , name_base, vdev->num); +mutex_lock (&videodev_lock); ret =device_register (&vdev->dev);if (ret <0 ) { +mutex_unlock (&videodev_lock);pr_err ("%s: device_register failed\n" , __func__); goto cleanup; }
@@ -1051,6 +1053,7 @@ int __video_register_device(struct video/* Part 6: Activate this minor. The char device can now be used. */ set_bit (V4L2_FL_REGISTERED , &vdev->flags); +mutex_unlock (&videodev_lock);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 290/317 mmc: core: Add mmc_gpiod_set_cd_config() function
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit 63a7cd660246aa36af263b85c33ecc6601bf04be upstream.
Some mmc host drivers may need to fixup a card-detection GPIO's config to e.g. enable the GPIO controllers builtin pull-up resistor on devices where the firmware description of the GPIO is broken (e.g. GpioInt with PullNone instead of PullUp in ACPI DSDT).
Since this is the exception rather then the rule adding a config parameter to mmc_gpiod_request_cd() seems undesirable, so instead add a new mmc_gpiod_set_cd_config() function. This is simply a wrapper to call gpiod_set_config() on the card-detect GPIO acquired through mmc_gpiod_request_cd().
--- drivers/mmc/core/slot-gpio.c | 20 ++++++++++++++++++++ include/linux/mmc/slot-gpio.h | 1 + 2 files changed, 21 insertions(+)
drivers/mmc/core/slot-gpio.c +20 -0
@@ -202,6 +202,26 @@ int mmc_gpiod_request_cd(struct mmc_host }EXPORT_SYMBOL (mmc_gpiod_request_cd); +/** +* mmc_gpiod_set_cd_config - set config for card-detection GPIO +* @host: mmc host +* @config: Generic pinconf config (from pinconf_to_config_packed()) +* +* This can be used by mmc host drivers to fixup a card-detection GPIO's config +* (e.g. set PIN_CONFIG_BIAS_PULL_UP) after acquiring the GPIO descriptor +* through mmc_gpiod_request_cd(). +* +* Returns: +* 0 on success, or a negative errno value on error. +*/ +int mmc_gpiod_set_cd_config (struct mmc_host *host,unsigned long config) +{ +struct mmc_gpio *ctx = host->slot.handler_priv; + +return gpiod_set_config (ctx->cd_gpio, config); +} +EXPORT_SYMBOL (mmc_gpiod_set_cd_config); +bool mmc_can_gpio_cd (struct mmc_host *host) {struct mmc_gpio *ctx = host->slot.handler_priv;
include/linux/mmc/slot-gpio.h +1 -0
@@ -20,6 +20,7 @@ int mmc_gpiod_request_cd(struct mmc_host unsigned int debounce);int mmc_gpiod_request_ro (struct mmc_host *host,const char *con_id,unsigned int idx,unsigned int debounce); +int mmc_gpiod_set_cd_config (struct mmc_host *host,unsigned long config);void mmc_gpio_set_cd_isr (struct mmc_host *host,irqreturn_t (*isr)(int irq,void *dev_id));int mmc_gpio_set_cd_wake (struct mmc_host *host,bool on);
Greg Kroah-Hartman
maintainerPATCH 291/317 mmc: sdhci-acpi: Sort DMI quirks alphabetically
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit a92a73b1d9249d155412d8ac237142fa716803ea upstream.
Sort the DMI quirks alphabetically.
--- drivers/mmc/host/sdhci-acpi.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-)
drivers/mmc/host/sdhci-acpi.c +13 -12
@@ -761,9 +761,22 @@ static const struct acpi_device_id sdhci };MODULE_DEVICE_TABLE (acpi, sdhci_acpi_ids); +/* Please keep this list sorted alphabetically */ static const struct dmi_system_id sdhci_acpi_quirks[] = { {/* +* The Acer Aspire Switch 10 (SW5-012) microSD slot always +* reports the card being write-protected even though microSD +* cards do not have a write-protect switch at all. +*/ + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Acer" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"Aspire SW5-012" ), + }, + .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT , + }, + { +/* * The Lenovo Miix 320-10ICR has a bug in the _PS0 method of * the SHC1 ACPI device, this bug causes it to reprogram the * wrong LDO (DLDO3) to 1.8V if 1.8V modes are used and the
@@ -778,18 +791,6 @@ static const struct dmi_system_id sdhci_ }, {/* -* The Acer Aspire Switch 10 (SW5-012) microSD slot always -* reports the card being write-protected even though microSD -* cards do not have a write-protect switch at all. -*/ - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Acer" ), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire SW5-012"), - }, - .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT, - }, - { -/* * The Toshiba WT8-B's microSD slot always reports the card being * write-protected. */
Greg Kroah-Hartman
maintainerPATCH 292/317 mmc: sdhci-acpi: Fix Lenovo Yoga Tablet 2 Pro 1380 sdcard slot not working
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit f3521d7cbaefff19cc656325787ed797e5f6a955 upstream.
The Lenovo Yoga Tablet 2 Pro 1380 sdcard slot has an active high cd pin and a broken wp pin which always reports the card being write-protected.
Add a DMI quirk to address both issues.
--- drivers/mmc/host/sdhci-acpi.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
drivers/mmc/host/sdhci-acpi.c +24 -0
@@ -81,6 +81,7 @@ struct sdhci_acpi_host {enum {DMI_QUIRK_RESET_SD_SIGNAL_VOLT_ON_SUSP =BIT (0 ),DMI_QUIRK_SD_NO_WRITE_PROTECT =BIT (1 ), +DMI_QUIRK_SD_CD_ACTIVE_HIGH =BIT (2 ), };static inline void *sdhci_acpi_priv (struct sdhci_acpi_host *c)
@@ -791,6 +792,26 @@ static const struct dmi_system_id sdhci_ }, {/* +* Lenovo Yoga Tablet 2 Pro 1380F/L (13" Android version) this +* has broken WP reporting and an inverted CD signal. +* Note this has more or less the same BIOS as the Lenovo Yoga +* Tablet 2 830F/L or 1050F/L (8" and 10" Android), but unlike +* the 830 / 1050 models which share the same mainboard this +* model has a different mainboard and the inverted CD and +* broken WP are unique to this board. +*/ + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Intel Corp." ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VALLEYVIEW C0 PLATFORM" ), +DMI_MATCH (DMI_BOARD_NAME ,"BYT-T FFD8" ), +/* Full match so as to NOT match the 830/1050 BIOS */ + DMI_MATCH(DMI_BIOS_VERSION, "BLADE_21.X64.0005.R00.1504101516"), + }, + .driver_data = (void *)(DMI_QUIRK_SD_NO_WRITE_PROTECT | + DMI_QUIRK_SD_CD_ACTIVE_HIGH), + }, + { +/* * The Toshiba WT8-B's microSD slot always reports the card being * write-protected. */
@@ -914,6 +935,9 @@ static int sdhci_acpi_probe(struct platfif (sdhci_acpi_flag (c,SDHCI_ACPI_SD_CD )) {bool v =sdhci_acpi_flag (c,SDHCI_ACPI_SD_CD_OVERRIDE_LEVEL ); +if (quirks &DMI_QUIRK_SD_CD_ACTIVE_HIGH ) + host->mmc->caps2 |=MMC_CAP2_CD_ACTIVE_HIGH ; + err =mmc_gpiod_request_cd (host->mmc,NULL ,0 , v,0 );if (err) {if (err == -EPROBE_DEFER )
Greg Kroah-Hartman
maintainerPATCH 293/317 mmc: sdhci-acpi: Disable write protect detection on Toshiba WT10-A
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit ef3eab75e17191e5665f52e64e85bc29d5705a7b upstream.
On the Toshiba WT10-A the microSD slot always reports the card being write-protected, just like on the Toshiba WT8-B.
Add a DMI quirk to work around this.
--- drivers/mmc/host/sdhci-acpi.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/mmc/host/sdhci-acpi.c +11 -0
@@ -821,6 +821,17 @@ static const struct dmi_system_id sdhci_ }, .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT, }, + { + /* + * The Toshiba WT10-A's microSD slot always reports the card being + * write-protected. + */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "TOSHIBA WT10-A"), + }, + .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT, + }, {} /* Terminating entry */ };
Greg Kroah-Hartman
maintainerPATCH 294/317 fbdev: savage: Handle err return when savagefb_check_var failed
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cai Xinchen <[email protected]>
commit 6ad959b6703e2c4c5d7af03b4cfd5ff608036339 upstream.
The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefb_probe doesn't handle the error return of savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.
--- drivers/video/fbdev/savage/savagefb_driver.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/video/fbdev/savage/savagefb_driver.c +4 -1
@@ -2271,7 +2271,10 @@ static int savagefb_probe(struct pci_devif (info->var.xres_virtual >0x1000 ) info->var.xres_virtual =0x1000 ;#endif -savagefb_check_var (&info->var, info); + err =savagefb_check_var (&info->var, info); +if (err) + goto failed; +savagefb_set_fix (info);/*
Greg Kroah-Hartman
maintainerPATCH 295/317 KVM: arm64: Allow AArch32 PSTATE.M to be restored as System mode
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
commit dfe6d190f38fc5df5ff2614b463a5195a399c885 upstream.
It appears that we don't allow a vcpu to be restored in AArch32 System mode, as we *never* included it in the list of valid modes.
Just add it to the list of allowed modes.
--- arch/arm64/kvm/guest.c | 1 + 1 file changed, 1 insertion(+)
arch/arm64/kvm/guest.c +1 -0
@@ -234,6 +234,7 @@ static int set_core_reg(struct kvm_vcpucase PSR_AA32_MODE_SVC :case PSR_AA32_MODE_ABT :case PSR_AA32_MODE_UND : +case PSR_AA32_MODE_SYS :if (!vcpu_el1_is_32bit (vcpu))return -EINVAL ;break ;
Greg Kroah-Hartman
maintainerPATCH 296/317 crypto: ecrdsa - Fix module auto-load on add_key
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vitaly Chikunov <[email protected]>
commit eb5739a1efbc9ff216271aeea0ebe1c92e5383e5 upstream.
Add module alias with the algorithm cra_name similar to what we have for RSA-related and other algorithms.
The kernel attempts to modprobe asymmetric algorithms using the names "crypto-$cra_name" and "crypto-$cra_name-all." However, since these aliases are currently missing, the modules are not loaded. For instance, when using the add_key function, the hash algorithm is typically loaded automatically, but the asymmetric algorithm is not.
Steps to test:
1. Cert is generated usings ima-evm-utils test suite with gen-keys.sh, example cert is provided below:
$ base64 -d >test-gost2012_512-A.cer <<EOF MIIB/DCCAWagAwIBAgIUK8+whWevr3FFkSdU9GLDAM7ure8wDAYIKoUDBwEBAwMFADARMQ8wDQYD VQQDDAZDQSBLZXkwIBcNMjIwMjAxMjIwOTQxWhgPMjA4MjEyMDUyMjA5NDFaMBExDzANBgNVBAMM BkNBIEtleTCBoDAXBggqhQMHAQEBAjALBgkqhQMHAQIBAgEDgYQABIGALXNrTJGgeErBUOov3Cfo IrHF9fcj8UjzwGeKCkbCcINzVUbdPmCopeJRHDJEvQBX1CQUPtlwDv6ANjTTRoq5nCk9L5PPFP1H z73JIXHT0eRBDVoWy0cWDRz1mmQlCnN2HThMtEloaQI81nTlKZOcEYDtDpi5WODmjEeRNQJMdqCj UDBOMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFCwfOITMbE9VisW1i2TYeu1tAo5QMB8GA1UdIwQY MBaAFCwfOITMbE9VisW1i2TYeu1tAo5QMAwGCCqFAwcBAQMDBQADgYEAmBfJCMTdC0/NSjz4BBiQ qDIEjomO7FEHYlkX5NGulcF8FaJW2jeyyXXtbpnub1IQ8af1KFIpwoS2e93LaaofxpWlpQLlju6m KYLOcO4xK3Whwa2hBAz9YbpUSFjvxnkS2/jpH2MsOSXuUEeCruG/RkHHB3ACef9umG6HCNQuAPY= EOF
2. Optionally, trace module requests with: trace-cmd stream -e module &
3. Trigger add_key call for the cert:
# keyctl padd asymmetric "" @u <test-gost2012_512-A.cer 939910969 # lsmod | head -3 Module Size Used by ecrdsa_generic 16384 0 streebog_generic 28672 0
--- crypto/ecrdsa.c | 1 + 1 file changed, 1 insertion(+)
crypto/ecrdsa.c +1 -0
@@ -294,4 +294,5 @@ module_exit(ecrdsa_mod_fini);MODULE_LICENSE ("GPL" );MODULE_AUTHOR ("Vitaly Chikunov <[email protected]>" );MODULE_DESCRIPTION ("EC-RDSA generic algorithm" ); +MODULE_ALIAS_CRYPTO ("ecrdsa" );MODULE_ALIAS_CRYPTO ("ecrdsa-generic" );
Greg Kroah-Hartman
maintainerPATCH 297/317 crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <[email protected]>
commit d3b17c6d9dddc2db3670bc9be628b122416a3d26 upstream.
Using completion_done to determine whether the caller has gone away only works after a complete call. Furthermore it's still possible that the caller has not yet called wait_for_completion, resulting in another potential UAF.
Fix this by making the caller use cancel_work_sync and then freeing the memory safely.
--- drivers/crypto/qat/qat_common/adf_aer.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-)
drivers/crypto/qat/qat_common/adf_aer.c +5 -14
@@ -95,8 +95,7 @@ static void adf_device_reset_worker(struif (adf_dev_init (accel_dev) ||adf_dev_start (accel_dev)) {/* The device hanged and we can't restart it so stop here */ dev_err (&GET_DEV (accel_dev),"Restart device failed\n" ); -if (reset_data->mode ==ADF_DEV_RESET_ASYNC || -completion_done (&reset_data->compl)) +if (reset_data->mode ==ADF_DEV_RESET_ASYNC )kfree (reset_data);WARN (1 ,"QAT: device restart failed. Device is unusable\n" );return ;
@@ -104,16 +103,8 @@ static void adf_device_reset_worker(struadf_dev_restarted_notify (accel_dev);clear_bit (ADF_STATUS_RESTARTING , &accel_dev->status); -/* -* The dev is back alive. Notify the caller if in sync mode -* -* If device restart will take a more time than expected, -* the schedule_reset() function can timeout and exit. This can be -* detected by calling the completion_done() function. In this case -* the reset_data structure needs to be freed here. -*/ -if (reset_data->mode ==ADF_DEV_RESET_ASYNC || -completion_done (&reset_data->compl)) +/* The dev is back alive. Notify the caller if in sync mode */ +if (reset_data->mode ==ADF_DEV_RESET_ASYNC )kfree (reset_data);else complete (&reset_data->compl);
@@ -148,10 +139,10 @@ static int adf_dev_aer_schedule_reset(stif (!timeout) {dev_err (&GET_DEV (accel_dev),"Reset device timeout expired\n" ); +cancel_work_sync (&reset_data->reset_work); ret = -EFAULT ; - }else { -kfree (reset_data); } +kfree (reset_data);return ret; }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 298/317 net/ipv6: Fix route deleting failure when metric equals 0
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: xu xin <[email protected]>
commit bb487272380d120295e955ad8acfcbb281b57642 upstream.
Problem
=========
After commit 67f695134703 ("ipv6: Move setting default metric for routes"), we noticed that the logic of assigning the default value of fc_metirc changed in the ioctl process. That is, when users use ioctl(fd, SIOCADDRT, rt) with a non-zero metric to add a route, then they may fail to delete a route with passing in a metric value of 0 to the kernel by ioctl(fd, SIOCDELRT, rt). But iproute can succeed in deleting it.
As a reference, when using iproute tools by netlink to delete routes with a metric parameter equals 0, like the command as follows:
ip -6 route del fe80::/64 via fe81::5054:ff:fe11:3451 dev eth0 metric 0
the user can still succeed in deleting the route entry with the smallest metric.
Root Reason
===========
After commit 67f695134703 ("ipv6: Move setting default metric for routes"), When ioctl() pass in SIOCDELRT with a zero metric, rtmsg_to_fib6_config() will set a defalut value (1024) to cfg->fc_metric in kernel, and in ip6_route_del() and the line 4074 at net/ipv3/route.c, it will check by
if (cfg->fc_metric && cfg->fc_metric != rt->fib6_metric) continue;
and the condition is true and skip the later procedure (deleting route) because cfg->fc_metric != rt->fib6_metric. But before that commit, cfg->fc_metric is still zero there, so the condition is false and it will do the following procedure (deleting).
Solution
========
In order to keep a consistent behaviour across netlink() and ioctl(), we should allow to delete a route with a metric value of 0. So we only do the default setting of fc_metric in route adding.
--- net/ipv6/route.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/ipv6/route.c +4 -1
@@ -4345,7 +4345,7 @@ static void rtmsg_to_fib6_config(struct .fc_table = l3mdev_fib_table_by_index(net, rtmsg->rtmsg_ifindex) ? : RT6_TABLE_MAIN, .fc_ifindex = rtmsg->rtmsg_ifindex, - .fc_metric = rtmsg->rtmsg_metric ? : IP6_RT_PRIO_USER, + .fc_metric = rtmsg->rtmsg_metric, .fc_expires = rtmsg->rtmsg_info, .fc_dst_len = rtmsg->rtmsg_dst_len, .fc_src_len = rtmsg->rtmsg_src_len,
@@ -4375,6 +4375,9 @@ int ipv6_route_ioctl(struct net *net, unrtnl_lock ();switch (cmd) {case SIOCADDRT : +/* Only do the default setting of fc_metric in route adding */ +if (cfg.fc_metric ==0 ) + cfg.fc_metric =IP6_RT_PRIO_USER ; err =ip6_route_add (&cfg,GFP_KERNEL ,NULL );break ;case SIOCDELRT :
Greg Kroah-Hartman
maintainerPATCH 299/317 net/9p: fix uninit-value in p9_client_rpc()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikita Zhandarovich <[email protected]>
commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a upstream.
Syzbot with the help of KMSAN reported the following error:
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
__alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes.
Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage.
Message-ID: <[email protected]>
--- net/9p/client.c | 2 ++ 1 file changed, 2 insertions(+)
net/9p/client.c +2 -0
@@ -235,6 +235,8 @@ static int p9_fcall_init(struct p9_clienif (!fc->sdata)return -ENOMEM ; fc->capacity = alloc_msize; + fc->id =0 ; + fc->tag =P9_NOTAG ;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 300/317 intel_th: pci: Add Meteor Lake-S CPU support
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Shishkin <[email protected]>
commit a4f813c3ec9d1c32bc402becd1f011b3904dd699 upstream.
Add support for the Trace Hub in Meteor Lake-S CPU.
--- drivers/hwtracing/intel_th/pci.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/hwtracing/intel_th/pci.c +5 -0
@@ -290,6 +290,11 @@ static const struct pci_device_id intel_ .driver_data = (kernel_ulong_t)&intel_th_2x, }, { +/* Meteor Lake-S CPU */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xae24), + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, + {/* Raptor Lake-S */ PCI_DEVICE (PCI_VENDOR_ID_INTEL ,0x7a26 ), .driver_data = (kernel_ulong_t)&intel_th_2x,
Greg Kroah-Hartman
maintainerPATCH 301/317 sparc64: Fix number of online CPUs
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sam Ravnborg <[email protected]>
commit 98937707fea8375e8acea0aaa0b68a956dd52719 upstream.
Nick Bowler reported:
When using newer kernels on my Ultra 60 with dual 450MHz UltraSPARC-II CPUs, I noticed that only CPU 0 comes up, while older kernels (including 4.7) are working fine with both CPUs.
I bisected the failure to this commit:
9b2f753ec23710aa32c0d837d2499db92fe9115b is the first bad commit commit 9b2f753ec23710aa32c0d837d2499db92fe9115b
Author: Atish Patra <[email protected]>
Date: Thu Sep 15 14:54:40 2016 -0600
sparc64: Fix cpu_possible_mask if nr_cpus is set
This is a small change that reverts very easily on top of 5.18: there is just one trivial conflict. Once reverted, both CPUs work again.
Maybe this is related to the fact that the CPUs on this system are numbered CPU0 and CPU2 (there is no CPU1)?
The current code that adjust cpu_possible based on nr_cpu_ids do not take into account that CPU's may not come one after each other. Move the chech to the function that setup the cpu_possible mask so there is no need to adjust it later.
--- arch/sparc/include/asm/smp_64.h | 2 -- arch/sparc/kernel/prom_64.c | 4 +++- arch/sparc/kernel/setup_64.c | 1 - arch/sparc/kernel/smp_64.c | 14 -------------- 4 files changed, 3 insertions(+), 18 deletions(-)
arch/sparc/include/asm/smp_64.h +0 -2
@@ -47,7 +47,6 @@ void arch_send_call_function_ipi_mask(coint hard_smp_processor_id (void );#define raw_smp_processor_id () (current_thread_info()->cpu) -void smp_fill_in_cpu_possible_map (void );void smp_fill_in_sib_core_maps (void );void cpu_play_dead (void );
@@ -77,7 +76,6 @@ void __cpu_die(unsigned int cpu);#define smp_fill_in_sib_core_maps () do { } while (0)#define smp_fetch_global_regs () do { } while (0)#define smp_fetch_global_pmu () do { } while (0) -#define smp_fill_in_cpu_possible_map () do { } while (0)#define smp_init_cpu_poke () do { } while (0)#define scheduler_poke () do { } while (0)
arch/sparc/kernel/prom_64.c +3 -1
@@ -483,7 +483,9 @@ static void *record_one_cpu(struct devic ncpus_probed++;#ifdef CONFIG_SMP set_cpu_present (cpuid, true); -set_cpu_possible (cpuid, true); + +if (num_possible_cpus () < nr_cpu_ids) +set_cpu_possible (cpuid, true);#endif return NULL ; }
arch/sparc/kernel/setup_64.c +0 -1
@@ -688,7 +688,6 @@ void __init setup_arch(char **cmdline_p)paging_init ();init_sparc64_elf_hwcap (); -smp_fill_in_cpu_possible_map ();/* * Once the OF device tree and MDESC have been setup and nr_cpus has * been parsed, we know the list of possible cpus. Therefore we can
arch/sparc/kernel/smp_64.c +0 -14
@@ -1210,20 +1210,6 @@ void __init smp_setup_processor_id(void) xcall_deliver_impl = hypervisor_xcall_deliver; } -void __init smp_fill_in_cpu_possible_map (void ) -{ -int possible_cpus =num_possible_cpus (); -int i; - -if (possible_cpus > nr_cpu_ids) - possible_cpus = nr_cpu_ids; - -for (i =0 ; i < possible_cpus; i++) -set_cpu_possible (i, true); -for (; i <NR_CPUS ; i++) -set_cpu_possible (i, false); -} -void smp_fill_in_sib_core_maps (void ) {unsigned int i;
Greg Kroah-Hartman
maintainerPATCH 302/317 watchdog: rti_wdt: Set min_hw_heartbeat_ms to accommodate a safety margin
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Judith Mendez <[email protected]>
commit cae58516534e110f4a8558d48aa4435e15519121 upstream.
On AM62x, the watchdog is pet before the valid window is open. Fix min_hw_heartbeat and accommodate a 2% + static offset safety margin. The static offset accounts for max hardware error.
Remove the hack in the driver which shifts the open window boundary, since it is no longer necessary due to the fix mentioned above.
--- drivers/watchdog/rti_wdt.c | 34 +++++++++++++++------------------- 1 file changed, 15 insertions(+), 19 deletions(-)
drivers/watchdog/rti_wdt.c +15 -19
@@ -52,6 +52,8 @@#define DWDST BIT(1) +#define MAX_HW_ERROR 250 +static int heartbeat =DEFAULT_HEARTBEAT ;/*
@@ -90,7 +92,7 @@ static int rti_wdt_start(struct watchdog* to be 50% or less than that; we obviouly want to configure the open * window as large as possible so we select the 50% option. */ - wdd->min_hw_heartbeat_ms =500 * wdd->timeout; + wdd->min_hw_heartbeat_ms =520 * wdd->timeout +MAX_HW_ERROR ;/* Generate NMI when wdt expires */ writel_relaxed (RTIWWDRX_NMI , wdt->base +RTIWWDRXCTRL );
@@ -124,31 +126,33 @@ static int rti_wdt_setup_hw_hb(struct wa* be petted during the open window; not too early or not too late. * The HW configuration options only allow for the open window size * to be 50% or less than that. +* To avoid any glitches, we accommodate 2% + max hardware error +* safety margin. */ switch (wsize) {case RTIWWDSIZE_50P : -/* 50% open window => 50% min heartbeat */ - wdd->min_hw_heartbeat_ms =500 * heartbeat; +/* 50% open window => 52% min heartbeat */ + wdd->min_hw_heartbeat_ms =520 * heartbeat +MAX_HW_ERROR ;break ;case RTIWWDSIZE_25P : -/* 25% open window => 75% min heartbeat */ - wdd->min_hw_heartbeat_ms =750 * heartbeat; +/* 25% open window => 77% min heartbeat */ + wdd->min_hw_heartbeat_ms =770 * heartbeat +MAX_HW_ERROR ;break ;case RTIWWDSIZE_12P5 : -/* 12.5% open window => 87.5% min heartbeat */ - wdd->min_hw_heartbeat_ms =875 * heartbeat; +/* 12.5% open window => 89.5% min heartbeat */ + wdd->min_hw_heartbeat_ms =895 * heartbeat +MAX_HW_ERROR ;break ;case RTIWWDSIZE_6P25 : -/* 6.5% open window => 93.5% min heartbeat */ - wdd->min_hw_heartbeat_ms =935 * heartbeat; +/* 6.5% open window => 95.5% min heartbeat */ + wdd->min_hw_heartbeat_ms =955 * heartbeat +MAX_HW_ERROR ;break ;case RTIWWDSIZE_3P125 : -/* 3.125% open window => 96.9% min heartbeat */ - wdd->min_hw_heartbeat_ms =969 * heartbeat; +/* 3.125% open window => 98.9% min heartbeat */ + wdd->min_hw_heartbeat_ms =989 * heartbeat +MAX_HW_ERROR ;break ;default :
@@ -222,14 +226,6 @@ static int rti_wdt_probe(struct platformreturn -EINVAL ; } -/* -* If watchdog is running at 32k clock, it is not accurate. -* Adjust frequency down in this case so that we don't pet -* the watchdog too often. -*/ -if (wdt->freq <32768 ) - wdt->freq = wdt->freq *9 /10 ; -pm_runtime_enable (dev); ret =pm_runtime_get_sync (dev);if (ret <0 ) {
Greg Kroah-Hartman
maintainerPATCH 303/317 kdb: Fix buffer overflow during tab-complete
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <[email protected]>
commit e9730744bf3af04cda23799029342aa3cddbc454 upstream.
Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer.
Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around.
--- kernel/debug/kdb/kdb_io.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-)
kernel/debug/kdb/kdb_io.c +13 -8
@@ -354,14 +354,19 @@ poll_again:kdb_printf (kdb_prompt_str);kdb_printf ("%s" , buffer); }else if (tab !=2 && count >0 ) { - len_tmp =strlen (p_tmp); -strncpy (p_tmp+len_tmp, cp, lastchar-cp+1 ); - len_tmp =strlen (p_tmp); -strncpy (cp, p_tmp+len, len_tmp-len +1 ); - len = len_tmp - len; -kdb_printf ("%s" , cp); - cp += len; - lastchar += len; +/* How many new characters do we want from tmpbuffer? */ + len_tmp =strlen (p_tmp) - len; +if (lastchar + len_tmp >= bufend) + len_tmp = bufend - lastchar; + +if (len_tmp) { +/* + 1 ensures the '\0' is memmove'd */ +memmove (cp+len_tmp, cp, (lastchar-cp) +1 ); +memcpy (cp, p_tmp+len, len_tmp); +kdb_printf ("%s" , cp); + cp += len_tmp; + lastchar += len_tmp; + } } kdb_nextline =1 ;/* reset output line number */ break ;
Greg Kroah-Hartman
maintainerPATCH 304/317 kdb: Use format-strings rather than \0 injection in kdb_read()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <[email protected]>
commit 09b35989421dfd5573f0b4683c7700a7483c71f9 upstream.
Currently when kdb_read() needs to reposition the cursor it uses copy and paste code that works by injecting an '\0' at the cursor position before delivering a carriage-return and reprinting the line (which stops at the '\0').
Tidy up the code by hoisting the copy and paste code into an appropriately named function. Additionally let's replace the '\0' injection with a proper field width parameter so that the string will be abridged during formatting instead.
--- kernel/debug/kdb/kdb_io.c | 55 ++++++++++++++++++++++++++++------------------ 1 file changed, 34 insertions(+), 21 deletions(-)
kernel/debug/kdb/kdb_io.c +34 -21
@@ -172,6 +172,33 @@ char kdb_getchar(void)unreachable (); } +/** +* kdb_position_cursor() - Place cursor in the correct horizontal position +* @prompt: Nil-terminated string containing the prompt string +* @buffer: Nil-terminated string containing the entire command line +* @cp: Cursor position, pointer the character in buffer where the cursor +* should be positioned. +* +* The cursor is positioned by sending a carriage-return and then printing +* the content of the line until we reach the correct cursor position. +* +* There is some additional fine detail here. +* +* Firstly, even though kdb_printf() will correctly format zero-width fields +* we want the second call to kdb_printf() to be conditional. That keeps things +* a little cleaner when LOGGING=1. +* +* Secondly, we can't combine everything into one call to kdb_printf() since +* that renders into a fixed length buffer and the combined print could result +* in unwanted truncation. +*/ +static void kdb_position_cursor (char *prompt,char *buffer,char *cp) +{ +kdb_printf ("\r%s" , kdb_prompt_str); +if (cp > buffer) +kdb_printf ("%.*s" , (int )(cp - buffer), buffer); +} +/* * kdb_read *
@@ -200,7 +227,6 @@ static char *kdb_read(char *buffer, size* and null byte */ char *lastchar;char *p_tmp; -char tmp;static char tmpbuffer[CMD_BUFLEN ];int len =strlen (buffer);int len_tmp;
@@ -237,12 +263,8 @@ poll_again: } *(--lastchar) ='\0' ; --cp; -kdb_printf ("\b%s \r" , cp); - tmp = *cp; - *cp ='\0' ; -kdb_printf (kdb_prompt_str); -kdb_printf ("%s" , buffer); - *cp = tmp; +kdb_printf ("\b%s " , cp); +kdb_position_cursor (kdb_prompt_str, buffer, cp); }break ;case 13 :/* enter */
@@ -259,19 +281,14 @@ poll_again:memcpy (tmpbuffer, cp+1 , lastchar - cp -1 );memcpy (cp, tmpbuffer, lastchar - cp -1 ); *(--lastchar) ='\0' ; -kdb_printf ("%s \r" , cp); - tmp = *cp; - *cp ='\0' ; -kdb_printf (kdb_prompt_str); -kdb_printf ("%s" , buffer); - *cp = tmp; +kdb_printf ("%s " , cp); +kdb_position_cursor (kdb_prompt_str, buffer, cp); }break ;case 1 :/* Home */ if (cp > buffer) { -kdb_printf ("\r" ); -kdb_printf (kdb_prompt_str); cp = buffer; +kdb_position_cursor (kdb_prompt_str, buffer, cp); }break ;case 5 :/* End */
@@ -377,13 +394,9 @@ poll_again:memcpy (cp+1 , tmpbuffer, lastchar - cp); *++lastchar ='\0' ; *cp = key; -kdb_printf ("%s\r" , cp); +kdb_printf ("%s" , cp); ++cp; - tmp = *cp; - *cp ='\0' ; -kdb_printf (kdb_prompt_str); -kdb_printf ("%s" , buffer); - *cp = tmp; +kdb_position_cursor (kdb_prompt_str, buffer, cp); }else { *++lastchar ='\0' ; *cp++ = key;
Greg Kroah-Hartman
maintainerPATCH 305/317 kdb: Fix console handling when editing and tab-completing commands
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <[email protected]>
commit db2f9c7dc29114f531df4a425d0867d01e1f1e28 upstream.
Currently, if the cursor position is not at the end of the command buffer and the user uses the Tab-complete functions, then the console does not leave the cursor in the correct position.
For example consider the following buffer with the cursor positioned at the ^:
md kdb_pro 10
^
Pressing tab should result in:
md kdb_prompt_str 10
^
However this does not happen. Instead the cursor is placed at the end (after then 10) and further cursor movement redraws incorrectly. The same problem exists when we double-Tab but in a different part of the code.
Fix this by sending a carriage return and then redisplaying the text to the left of the cursor.
--- kernel/debug/kdb/kdb_io.c | 5 +++++ 1 file changed, 5 insertions(+)
kernel/debug/kdb/kdb_io.c +5 -0
@@ -370,6 +370,8 @@ poll_again:kdb_printf ("\n" );kdb_printf (kdb_prompt_str);kdb_printf ("%s" , buffer); +if (cp != lastchar) +kdb_position_cursor (kdb_prompt_str, buffer, cp); }else if (tab !=2 && count >0 ) {/* How many new characters do we want from tmpbuffer? */ len_tmp =strlen (p_tmp) - len;
@@ -383,6 +385,9 @@ poll_again:kdb_printf ("%s" , cp); cp += len_tmp; lastchar += len_tmp; +if (cp != lastchar) +kdb_position_cursor (kdb_prompt_str, + buffer, cp); } } kdb_nextline =1 ;/* reset output line number */
Greg Kroah-Hartman
maintainerPATCH 306/317 kdb: Merge identical case statements in kdb_read()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <[email protected]>
commit 6244917f377bf64719551b58592a02a0336a7439 upstream.
The code that handles case 14 (down) and case 16 (up) has been copy and pasted despite being byte-for-byte identical. Combine them.
--- kernel/debug/kdb/kdb_io.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
kernel/debug/kdb/kdb_io.c +1 -9
@@ -304,6 +304,7 @@ poll_again: }break ;case 14 :/* Down */ +case 16 :/* Up */ memset (tmpbuffer,' ' ,strlen (kdb_prompt_str) + (lastchar-buffer)); *(tmpbuffer+strlen(kdb_prompt_str) +
@@ -318,15 +319,6 @@ poll_again: ++cp; }break ; -case 16 :/* Up */ -memset (tmpbuffer,' ' , -strlen (kdb_prompt_str) + (lastchar-buffer)); - *(tmpbuffer+strlen (kdb_prompt_str) + - (lastchar-buffer)) ='\0' ; -kdb_printf ("\r%s\r" , tmpbuffer); - *lastchar = (char )key; - *(lastchar+1 ) ='\0' ; -return lastchar;case 9 :/* Tab */ if (tab <2 ) ++tab;
Greg Kroah-Hartman
maintainerPATCH 307/317 kdb: Use format-specifiers rather than memset() for padding in kdb_read()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <[email protected]>
commit c9b51ddb66b1d96e4d364c088da0f1dfb004c574 upstream.
Currently when the current line should be removed from the display kdb_read() uses memset() to fill a temporary buffer with spaces. The problem is not that this could be trivially implemented using a format string rather than open coding it. The real problem is that it is possible, on systems with a long kdb_prompt_str, to write past the end of the tmpbuffer.
Happily, as mentioned above, this can be trivially implemented using a format string. Make it so!
--- kernel/debug/kdb/kdb_io.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
kernel/debug/kdb/kdb_io.c +3 -5
@@ -305,11 +305,9 @@ poll_again:break ;case 14 :/* Down */ case 16 :/* Up */ -memset (tmpbuffer,' ' , -strlen (kdb_prompt_str) + (lastchar-buffer)); - *(tmpbuffer+strlen (kdb_prompt_str) + - (lastchar-buffer)) ='\0' ; -kdb_printf ("\r%s\r" , tmpbuffer); +kdb_printf ("\r%*c\r" , + (int )(strlen (kdb_prompt_str) + (lastchar - buffer)), +' ' ); *lastchar = (char )key; *(lastchar+1 ) ='\0' ;return lastchar;
Greg Kroah-Hartman
maintainerPATCH 308/317 net: fix __dst_negative_advice() race
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit 92f1655aa2b2294d0b49925f3b875a634bd3b59e upstream.
__dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF.
RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst).
Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order.
Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves.
Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks.
Many thanks to Clement Lecigne for tracking this issue.
This old bug became visible after the blamed commit, using UDP sockets.
--- include/net/dst_ops.h | 2 +- include/net/sock.h | 13 +++---------- net/ipv4/route.c | 22 ++++++++-------------- net/ipv6/route.c | 29 +++++++++++++++-------------- net/xfrm/xfrm_policy.c | 11 +++-------- 5 files changed, 30 insertions(+), 47 deletions(-)
include/net/dst_ops.h +1 -1
@@ -24,7 +24,7 @@ struct dst_ops {void (*destroy)(struct dst_entry *);void (*ifdown)(struct dst_entry *,struct net_device *dev,int how); -struct dst_entry * (*negative_advice)(struct dst_entry *); +void (*negative_advice)(struct sock *sk,struct dst_entry *);void (*link_failure)(struct sk_buff *); void (*update_pmtu)(struct dst_entry *dst, struct sock *sk, struct sk_buff *skb, u32 mtu,
include/net/sock.h +3 -10
@@ -2012,17 +2012,10 @@ sk_dst_get(struct sock *sk)static inline void __dst_negative_advice (struct sock *sk) { -struct dst_entry *ndst, *dst =__sk_dst_get (sk); +struct dst_entry *dst =__sk_dst_get (sk); -if (dst && dst->ops->negative_advice) { - ndst = dst->ops->negative_advice (dst); - -if (ndst != dst) { -rcu_assign_pointer (sk->sk_dst_cache, ndst); -sk_tx_queue_clear (sk); -WRITE_ONCE (sk->sk_dst_pending_confirm,0 ); - } - } +if (dst && dst->ops->negative_advice) + dst->ops->negative_advice (sk, dst); }static inline void dst_negative_advice (struct sock *sk)
net/ipv4/route.c +8 -14
@@ -137,7 +137,8 @@ static int ip_rt_gc_timeout __read_mostlstatic struct dst_entry *ipv4_dst_check (struct dst_entry *dst,u32 cookie);static unsigned int ipv4_default_advmss (const struct dst_entry *dst);static unsigned int ipv4_mtu (const struct dst_entry *dst); -static struct dst_entry *ipv4_negative_advice (struct dst_entry *dst); +static void ipv4_negative_advice (struct sock *sk, +struct dst_entry *dst);static void ipv4_link_failure (struct sk_buff *skb); static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk, struct sk_buff *skb, u32 mtu,
@@ -866,22 +867,15 @@ static void ip_do_redirect(struct dst_en__ip_do_redirect (rt, skb, &fl4, true); } -static struct dst_entry *ipv4_negative_advice (struct dst_entry *dst) +static void ipv4_negative_advice (struct sock *sk, +struct dst_entry *dst) {struct rtable *rt = (struct rtable *)dst; -struct dst_entry *ret = dst; -if (rt) { -if (dst->obsolete >0 ) { -ip_rt_put (rt); - ret =NULL ; - }else if ((rt->rt_flags &RTCF_REDIRECTED ) || - rt->dst.expires) { -ip_rt_put (rt); - ret =NULL ; - } - } -return ret; +if ((dst->obsolete >0 ) || + (rt->rt_flags &RTCF_REDIRECTED ) || + rt->dst.expires) +sk_dst_reset (sk); }/*
net/ipv6/route.c +15 -14
@@ -85,7 +85,8 @@ enum rt6_nud_state {static struct dst_entry *ip6_dst_check (struct dst_entry *dst,u32 cookie);static unsigned int ip6_default_advmss (const struct dst_entry *dst);static unsigned int ip6_mtu (const struct dst_entry *dst); -static struct dst_entry *ip6_negative_advice (struct dst_entry *); +static void ip6_negative_advice (struct sock *sk, +struct dst_entry *dst);static void ip6_dst_destroy (struct dst_entry *);static void ip6_dst_ifdown (struct dst_entry *,struct net_device *dev,int how);
@@ -2635,24 +2636,24 @@ static struct dst_entry *ip6_dst_check(sreturn dst_ret; } -static struct dst_entry *ip6_negative_advice (struct dst_entry *dst) +static void ip6_negative_advice (struct sock *sk, +struct dst_entry *dst) {struct rt6_info *rt = (struct rt6_info *) dst; -if (rt) { -if (rt->rt6i_flags &RTF_CACHE ) { -rcu_read_lock (); -if (rt6_check_expired (rt)) { -rt6_remove_exception_rt (rt); - dst =NULL ; - } -rcu_read_unlock (); - }else { -dst_release (dst); - dst =NULL ; +if (rt->rt6i_flags &RTF_CACHE ) { +rcu_read_lock (); +if (rt6_check_expired (rt)) { +/* counteract the dst_release() in sk_dst_reset() */ +dst_hold (dst); +sk_dst_reset (sk); + +rt6_remove_exception_rt (rt); } +rcu_read_unlock (); +return ; } -return dst; +sk_dst_reset (sk); }static void ip6_link_failure (struct sk_buff *skb)
net/xfrm/xfrm_policy.c +3 -8
@@ -3807,15 +3807,10 @@ static void xfrm_link_failure(struct sk_/* Impossible. Such dst must be popped before reaches point of failure. */ } -static struct dst_entry *xfrm_negative_advice (struct dst_entry *dst) +static void xfrm_negative_advice (struct sock *sk,struct dst_entry *dst) { -if (dst) { -if (dst->obsolete) { -dst_release (dst); - dst =NULL ; - } - } -return dst; +if (dst->obsolete) +sk_dst_reset (sk); }static void xfrm_init_pmtu (struct xfrm_dst **bundle,int nr)
Greg Kroah-Hartman
maintainerPATCH 309/317 sparc: move struct termio to asm/termios.h
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Gilbert <[email protected]>
commit c32d18e7942d7589b62e301eb426b32623366565 upstream.
Every other arch declares struct termio in asm/termios.h, so make sparc match them.
Resolves a build failure in the PPP software package, which includes both bits/ioctl-types.h via sys/ioctl.h (glibc) and asm/termbits.h.
--- arch/sparc/include/uapi/asm/termbits.h | 10 ---------- arch/sparc/include/uapi/asm/termios.h | 9 +++++++++ 2 files changed, 9 insertions(+), 10 deletions(-)
arch/sparc/include/uapi/asm/termbits.h +0 -10
@@ -13,16 +13,6 @@ typedef unsigned int tcflag_t;typedef unsigned long tcflag_t ;#endif -#define NCC 8 -struct termio { -unsigned short c_iflag;/* input mode flags */ -unsigned short c_oflag;/* output mode flags */ -unsigned short c_cflag;/* control mode flags */ -unsigned short c_lflag;/* local mode flags */ -unsigned char c_line;/* line discipline */ -unsigned char c_cc[NCC ];/* control characters */ -}; -#define NCCS 17struct termios {tcflag_t c_iflag;/* input mode flags */
arch/sparc/include/uapi/asm/termios.h +9 -0
@@ -40,5 +40,14 @@ struct winsize { unsigned short ws_ypixel; }; +#define NCC 8 +struct termio { +unsigned short c_iflag;/* input mode flags */ +unsigned short c_oflag;/* output mode flags */ +unsigned short c_cflag;/* control mode flags */ +unsigned short c_lflag;/* local mode flags */ +unsigned char c_line;/* line discipline */ +unsigned char c_cc[NCC ];/* control characters */ +};#endif /* _UAPI_SPARC_TERMIOS_H */
Greg Kroah-Hartman
maintainerPATCH 310/317 ext4: fix mb_cache_entrys e_refcnt leak in ext4_xattr_block_cache_find()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baokun Li <[email protected]>
commit 0c0b4a49d3e7f49690a6827a41faeffad5df7e21 upstream.
Syzbot reports a warning as follows:
============================================
WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327
[...]
============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.
--- fs/ext4/xattr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/ext4/xattr.c +3 -1
@@ -3065,8 +3065,10 @@ ext4_xattr_block_cache_find(struct inode bh =ext4_sb_bread (inode->i_sb, ce->e_value,REQ_PRIO );if (IS_ERR (bh)) { -if (PTR_ERR (bh) == -ENOMEM ) +if (PTR_ERR (bh) == -ENOMEM ) { +mb_cache_entry_put (ea_block_cache, ce);return NULL ; + } bh =NULL ;EXT4_ERROR_INODE (inode,"block %lu read error" , (unsigned long )ce->e_value);
Greg Kroah-Hartman
maintainerPATCH 311/317 s390/ap: Fix crash in AP internal function modify_bitmap()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harald Freudenberger <[email protected]>
commit d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9 upstream.
A system crash like this
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oops
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow.
--- drivers/s390/crypto/ap_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/s390/crypto/ap_bus.c +1 -1
@@ -859,7 +859,7 @@ static int hex2bitmap(const char *str, u*/ static int modify_bitmap (const char *str,unsigned long *bitmap,int bits) { -int a, i, z; +unsigned long a, i, z;char *np, sign;/* bits needs to be a multiple of 8 */
Greg Kroah-Hartman
maintainerPATCH 312/317 nfs: fix undefined behavior in nfs_block_bits()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Shtylyov <[email protected]>
commit 3c0a2e0b0ae661457c8505fecc7be5501aa7a715 upstream.
Shifting *signed int* typed constant 1 left by 31 bits causes undefined behavior. Specify the correct *unsigned long* type by using 1UL instead.
Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.
--- fs/nfs/internal.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfs/internal.h +2 -2
@@ -660,9 +660,9 @@ unsigned long nfs_block_bits(unsigned loif ((bsize & (bsize -1 )) || nrbitsp) {unsigned char nrbits; -for (nrbits =31 ; nrbits && !(bsize & (1 << nrbits)); nrbits--) +for (nrbits =31 ; nrbits && !(bsize & (1UL << nrbits)); nrbits--) ; - bsize =1 << nrbits; + bsize =1UL << nrbits;if (nrbitsp) *nrbitsp = nrbits; }
Greg Kroah-Hartman
maintainerPATCH 313/317 NFS: Fix READ_PLUS when server doesnt support OP_READ_PLUS
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anna Schumaker <[email protected]>
commit f06d1b10cb016d5aaecdb1804fefca025387bd10 upstream.
Olga showed me a case where the client was sending multiple READ_PLUS calls to the server in parallel, and the server replied NFS4ERR_OPNOTSUPP to each. The client would fall back to READ for the first reply, but fail to retry the other calls.
I fix this by removing the test for NFS_CAP_READ_PLUS in nfs4_read_plus_not_supported(). This allows us to reschedule any READ_PLUS call that has a NFS4ERR_OPNOTSUPP return value, even after the capability has been cleared.
--- fs/nfs/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfs/nfs4proc.c +1 -1
@@ -5320,7 +5320,7 @@ static bool nfs4_read_plus_not_supportedstruct rpc_message *msg = &task->tk_msg;if (msg->rpc_proc == &nfs4_procedures[NFSPROC4_CLNT_READ_PLUS ] && - server->caps &NFS_CAP_READ_PLUS && task->tk_status == -ENOTSUPP ) { + task->tk_status == -ENOTSUPP ) { server->caps &= ~NFS_CAP_READ_PLUS ; msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ ];rpc_restart_call_prepare (task);
Greg Kroah-Hartman
maintainerPATCH 314/317 scsi: ufs: ufs-qcom: Clear qunipro_g4_sel for HW major version > 5
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neil Armstrong <[email protected]>
commit c422fbd5cb58c9a078172ae1e9750971b738a197 upstream.
The qunipro_g4_sel clear is also needed for new platforms with major version > 5. Fix the version check to take this into account.
--- drivers/scsi/ufs/ufs-qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/ufs/ufs-qcom.c +1 -1
@@ -243,7 +243,7 @@ static void ufs_qcom_select_unipro_mode(ufs_qcom_cap_qunipro (host) ?QUNIPRO_SEL :0 , REG_UFS_CFG1); -if (host->hw_ver.major ==0x05 ) +if (host->hw_ver.major >=0x05 )ufshcd_rmwl (host->hba,QUNIPRO_G4_SEL ,0 ,REG_UFS_CFG0 ); }
Greg Kroah-Hartman
maintainerPATCH 315/317 f2fs: compress: fix compression chksum
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
commit 75e91c888989cf2df5c78b251b07de1f5052e30e upstream.
This patch addresses minor issues in compression chksum.
--- fs/f2fs/compress.c | 3 +-- fs/f2fs/compress.h | 0 fs/f2fs/compress.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) create mode 100644 fs/f2fs/compress.h
fs/f2fs/compress.c +1 -2
@@ -783,7 +783,7 @@ void f2fs_decompress_pages(struct bio *b ret = cops->decompress_pages (dic); -if (!ret && fi->i_compress_flag &1 <<COMPRESS_CHKSUM ) { +if (!ret && (fi->i_compress_flag &1 <<COMPRESS_CHKSUM )) {u32 provided =le32_to_cpu (dic->cbuf->chksum);u32 calculated =f2fs_crc32 (sbi, dic->cbuf->cdata, dic->clen);
@@ -796,7 +796,6 @@ void f2fs_decompress_pages(struct bio *b provided, calculated); }set_sbi_flag (sbi,SBI_NEED_FSCK ); -WARN_ON_ONCE (1 ); } }
Greg Kroah-Hartman
maintainerPATCH 316/317 RDMA/hns: Use mutex instead of spinlock for ida allocation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yangyang Li <[email protected]>
commit 9293d3fcb70583f2c786f04ca788af026b7c4c5c upstream.
GFP_KERNEL may cause ida_alloc_range() to sleep, but the spinlock covering this function is not allowed to sleep, so the spinlock needs to be changed to mutex.
As there is a certain chance of memory allocation failure, GFP_ATOMIC is not suitable for QP allocation scenarios.
--- drivers/infiniband/hw/hns/hns_roce_device.h | 2 +- drivers/infiniband/hw/hns/hns_roce_qp.c | 11 ++++++----- 2 files changed, 7 insertions(+), 6 deletions(-)
drivers/infiniband/hw/hns/hns_roce_device.h +1 -1
@@ -537,7 +537,7 @@ struct hns_roce_qp_table {struct hns_roce_hem_table sccc_table;struct mutex scc_mutex;struct hns_roce_bank bank[HNS_ROCE_QP_BANK_NUM ]; -spinlock_t bank_lock; +struct mutex bank_mutex; };struct hns_roce_cq_table {
drivers/infiniband/hw/hns/hns_roce_qp.c +6 -5
@@ -210,7 +210,7 @@ static int alloc_qpn(struct hns_roce_dev hr_qp->doorbell_qpn =1 ; }else { -spin_lock (&qp_table->bank_lock); +mutex_lock (&qp_table->bank_mutex); bankid =get_least_load_bankid_for_qp (qp_table->bank); ret = alloc_qpn_with_bankid(&qp_table->bank[bankid], bankid,
@@ -218,12 +218,12 @@ static int alloc_qpn(struct hns_roce_devif (ret) {ibdev_err (&hr_dev->ib_dev,"failed to alloc QPN, ret = %d\n" , ret); -spin_unlock (&qp_table->bank_lock); +mutex_unlock (&qp_table->bank_mutex);return ret; } qp_table->bank[bankid].inuse++; -spin_unlock (&qp_table->bank_lock); +mutex_unlock (&qp_table->bank_mutex); hr_qp->doorbell_qpn = (u32 )num; }
@@ -409,9 +409,9 @@ static void free_qpn(struct hns_roce_devida_free (&hr_dev->qp_table.bank[bankid].ida, hr_qp->qpn >>3 ); -spin_lock (&hr_dev->qp_table.bank_lock); +mutex_lock (&hr_dev->qp_table.bank_mutex); hr_dev->qp_table.bank[bankid].inuse--; -spin_unlock (&hr_dev->qp_table.bank_lock); +mutex_unlock (&hr_dev->qp_table.bank_mutex); } static int set_rq_size(struct hns_roce_dev *hr_dev, struct ib_qp_cap *cap,
@@ -1358,6 +1358,7 @@ int hns_roce_init_qp_table(struct hns_rounsigned int i;mutex_init (&qp_table->scc_mutex); +mutex_init (&qp_table->bank_mutex);xa_init (&hr_dev->qp_table_xa); reserved_from_bot = hr_dev->caps.reserved_qps;
Greg Kroah-Hartman
maintainerPATCH 317/317 RDMA/hns: Fix CQ and QP cache affinity
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chengchang Tang <[email protected]>
commit 9e03dbea2b0634b21a45946b4f8097e0dc86ebe1 upstream.
Currently, the affinity between QP cache and CQ cache is not considered when assigning QPN, it will affect the message rate of HW.
Allocate QPN from QP cache with better CQ affinity to get better performance.
--- drivers/infiniband/hw/hns/hns_roce_device.h | 2 ++ drivers/infiniband/hw/hns/hns_roce_qp.c | 28 ++++++++++++++++++++++------ 2 files changed, 24 insertions(+), 6 deletions(-)
drivers/infiniband/hw/hns/hns_roce_device.h +2 -0
@@ -122,6 +122,8 @@*/ #define EQ_DEPTH_COEFF 2 +#define CQ_BANKID_MASK GENMASK(1, 0) +enum {SERV_TYPE_RC ,SERV_TYPE_UC ,
drivers/infiniband/hw/hns/hns_roce_qp.c +22 -6
@@ -154,14 +154,29 @@ static void hns_roce_ib_qp_event(struct } } -static u8 get_least_load_bankid_for_qp (struct hns_roce_bank *bank) +static u8 get_affinity_cq_bank (u8 qp_bank) { -u32 least_load = bank[0 ].inuse; +return (qp_bank >>1 ) &CQ_BANKID_MASK ; +} + +static u8 get_least_load_bankid_for_qp (struct ib_qp_init_attr *init_attr, +struct hns_roce_bank *bank) +{ +#define INVALID_LOAD_QPNUM 0xFFFFFFFF +struct ib_cq *scq = init_attr->send_cq; +u32 least_load =INVALID_LOAD_QPNUM ; +unsigned long cqn =0 ;u8 bankid =0 ;u32 bankcnt;u8 i; -for (i =1 ; i <HNS_ROCE_QP_BANK_NUM ; i++) { +if (scq) + cqn =to_hr_cq (scq)->cqn; + +for (i =0 ; i <HNS_ROCE_QP_BANK_NUM ; i++) { +if (scq && (get_affinity_cq_bank (i) != (cqn &CQ_BANKID_MASK ))) +continue ; + bankcnt = bank[i].inuse;if (bankcnt < least_load) { least_load = bankcnt;
@@ -193,7 +208,8 @@ static int alloc_qpn_with_bankid(structreturn 0 ; } -static int alloc_qpn (struct hns_roce_dev *hr_dev,struct hns_roce_qp *hr_qp) +static int alloc_qpn (struct hns_roce_dev *hr_dev,struct hns_roce_qp *hr_qp, +struct ib_qp_init_attr *init_attr) {struct hns_roce_qp_table *qp_table = &hr_dev->qp_table;unsigned long num =0 ;
@@ -211,7 +227,7 @@ static int alloc_qpn(struct hns_roce_dev hr_qp->doorbell_qpn =1 ; }else {mutex_lock (&qp_table->bank_mutex); - bankid =get_least_load_bankid_for_qp (qp_table->bank); + bankid =get_least_load_bankid_for_qp (init_attr, qp_table->bank); ret =alloc_qpn_with_bankid (&qp_table->bank[bankid], bankid, &num);
@@ -1005,7 +1021,7 @@ static int hns_roce_create_qp_common(str goto err_db; } - ret =alloc_qpn (hr_dev, hr_qp); + ret =alloc_qpn (hr_dev, hr_qp, init_attr);if (ret) {ibdev_err (ibdev,"failed to alloc QPN, ret = %d.\n" , ret); goto err_buf;
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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 Sat, 15 Jun 2024 11:31:50 +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/v5.x/stable-review/patch-5.10.219-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
The powerpc builds failed on stable-rc 5.10 branch with gcc-12 and clang.
Powerpc:
- maple_defconfig
- ppc6xx_defconfig
- tinyconfig
Build log:
---------
from /builds/linux/arch/powerpc/kernel/asm-offsets.c:14:arch/powerpc/include/asm/uaccess.h: In function 'raw_copy_from_user':arch/powerpc/include/asm/uaccess.h:472:25: error: implicit declaration of function '__get_user_size'; did you mean '__get_user_bad'? [-Werror=implicit-function-declaration]
472 | __get_user_size(*(u8 *)to, from, 1, ret);
| ^~~~~~~~~~~~~~~
| __get_user_badcc1: some warnings being treated as errors
Links:
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.218-318-g853b71b570fb/testrun/24321785/suite/build/test/gcc-12-maple_defconfig/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.218-318-g853b71b570fb/testrun/24321785/suite/build/test/gcc-12-maple_defconfig/history/
--
Linaro LKFT
https://lkft.linaro.org
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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 Sat, 15 Jun 2024 11:31:50 +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/v5.x/stable-review/patch-5.10.219-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
The following build errors are noticed on riscv with clang-18 toolchain but gcc-12 builds pass.
However, compared with older releases this is a build regression on stable-rc 5.10.
riscv:
defconfig - gcc-12 - PASS
defconfig - clang-18 - FAILED
Build error:
------arch/riscv/kernel/stacktrace.c:75:52: error: incompatible pointer to integer conversion passing 'void *' to parameter of type 'unsigned long' [-Wint-conversion]
75 | if
(unlikely(!__kernel_text_address(pc) || !fn(arg, pc)))
|
^~~include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^arch/riscv/kernel/stacktrace.c:75:57: error: incompatible integer to pointer conversion passing 'unsigned long' to parameter of type 'void *' [-Wint-conversion]
75 | if
(unlikely(!__kernel_text_address(pc) || !fn(arg, pc)))
|
^~include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
2 errors generated.
make[3]: *** [scripts/Makefile.build:286:arch/riscv/kernel/stacktrace.o] Error 1
Links:
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.218-318-g853b71b570fb/testrun/24322227/suite/build/test/clang-18-defconfig/details/
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.218-318-g853b71b570fb/testrun/24322227/suite/build/test/clang-18-defconfig/history/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2hp7bDTOjqzNr8hqqSWyMf943W8/
--
Linaro LKFT
https://lkft.linaro.org
Quoted 51 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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 Sat, 15 Jun 2024 11:31:50 +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/v5.x/stable-review/patch-5.10.219-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
The following build errors are noticed on riscv with clang-18 toolchain but gcc-12 builds pass.
However, compared with older releases this is a build regression on stable-rc 5.10.
riscv:
defconfig - gcc-12 - PASS
defconfig - clang-18 - FAILEDBuild error:
------arch/riscv/kernel/stacktrace.c:75:52: error: incompatible pointer to integer conversion passing 'void *' to parameter of type 'unsigned long' [-Wint-conversion]
75 | if
(unlikely(!__kernel_text_address(pc) || !fn(arg, pc)))| ^~~
include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
78 | # define unlikely(x)__builtin_expect(!!(x), 0)
| ^arch/riscv/kernel/stacktrace.c:75:57: error: incompatible integer to pointer conversion passing 'unsigned long' to parameter of type 'void *' [-Wint-conversion]
75 | if
(unlikely(!__kernel_text_address(pc) || !fn(arg, pc)))
Quoted 8 lines
| ^~
include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
78 | # define unlikely(x)__builtin_expect(!!(x), 0)
| ^
2 errors generated.
make[3]: *** [scripts/Makefile.build:286:arch/riscv/kernel/stacktrace.o] Error 1
It looks like either commit 9dd97064e21f ("riscv: Make stack walk callback consistent with generic code") should be applied with the straight from upstream copy of commit 7ecdadf7f8c6 ("riscv: stacktrace:
Make walk_stackframe cross pt_regs frame") or the latter commit's 5.10 backport should be modified to match the linux-5.10.y order of the arguments:
arch/riscv/kernel/stacktrace.c +1 -1
@@ -72,7 +72,7 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs, pc =ftrace_graph_ret_addr (current,NULL , frame->ra, &frame->ra);if (pc == (unsigned long )ret_from_exception) { -if (unlikely (!__kernel_text_address (pc) || !fn (arg, pc))) +if (unlikely (!__kernel_text_address (pc) || !fn (pc, arg)))break ; pc = ((struct pt_regs *)sp)->epc;
Cheers,
Nathan
Greg Kroah-Hartman
maintainerQuoted 73 lines · Nathan Chancellor
Quoted 51 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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 Sat, 15 Jun 2024 11:31:50 +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/v5.x/stable-review/patch-5.10.219-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
The following build errors are noticed on riscv with clang-18 toolchain but gcc-12 builds pass.
However, compared with older releases this is a build regression on stable-rc 5.10.
riscv:
defconfig - gcc-12 - PASS
defconfig - clang-18 - FAILEDBuild error:
------arch/riscv/kernel/stacktrace.c:75:52: error: incompatible pointer to integer conversion passing 'void *' to parameter of type 'unsigned long' [-Wint-conversion]
75 | if
(unlikely(!__kernel_text_address(pc) || !fn(arg, pc)))| ^~~
include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
78 | # define unlikely(x)__builtin_expect(!!(x), 0)
| ^arch/riscv/kernel/stacktrace.c:75:57: error: incompatible integer to pointer conversion passing 'unsigned long' to parameter of type 'void *' [-Wint-conversion]
75 | if
(unlikely(!__kernel_text_address(pc) || !fn(arg, pc)))Quoted 8 lines
| ^~
include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
78 | # define unlikely(x)__builtin_expect(!!(x), 0)
| ^
2 errors generated.
make[3]: *** [scripts/Makefile.build:286:arch/riscv/kernel/stacktrace.o] Error 1It looks like either commit
9dd97064e21f("riscv: Make stack walk callback consistent with generic code") should be applied with the straight from upstream copy of commit7ecdadf7f8c6("riscv: stacktrace:
Makewalk_stackframecrosspt_regsframe") or the latter commit's 5.10 backport should be modified to match the linux-5.10.y order of the arguments:arch/riscv/kernel/stacktrace.c +0
-0
arch/riscv/kernel/stacktrace.c void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs, · line 78
Quoted 8 lines
arch/riscv/kernel/stacktrace.c +1
-1@@ -72,7 +72,7 @@ void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs, pc =ftrace_graph_ret_addr (current,NULL , frame->ra, &frame->ra);if (pc == (unsigned long )ret_from_exception) { -if (unlikely (!__kernel_text_address (pc) || !fn (arg, pc))) +if (unlikely (!__kernel_text_address (pc) || !fn (pc, arg)))break ; pc = ((struct pt_regs *)sp)->epc;
I'll just drop these riscv patches from 5.10.y, as odds are, no one is using that arch in that old tree anymore. And if they are, they can send working patches :)
thanks,
greg k-h
Greg Kroah-Hartman wrote on Thu, Jun 13, 2024 at 01:30:18PM +0200:
Quoted 5 lines
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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 8 lines
Responses should be made by Sat, 15 Jun 2024 11:31:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.219-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.
(There will likely be a rc2 for riscv/ppc, but..)
Tested 853b71b570fb ("Linux 5.10.219-rc1") on:
- arm i.MX6ULL (Armadillo 640)
- arm64 i.MX8MP (Armadillo G4)
No obvious regression in dmesg or basic tests:
--
Dominique Martinet | Asmadeus
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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 Sat, 15 Jun 2024 11:31:50 +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/v5.x/stable-review/patch-5.10.219-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.10:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
68 tests: 68 pass, 0 failLinux version: 5.10.219-rc1-g853b71b570fb
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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 Sat, 15 Jun 2024 11:31:50 +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/v5.x/stable-review/patch-5.10.219-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Regressions on Powerpc and riscv build failures.
NOTE:
----
Following new build warnings noticed with gcc-12.
net/nfc/nci/core.c: In function 'nci_valid_size':net/nfc/nci/core.c:1458:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
1458 | unsigned int hdr_size = NCI_CTRL_HDR_SIZE;
| ^~~~~~~~## Build
* kernel: 5.10.219-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: 853b71b570fb6a0cfe358e0be3b638c65c9065ea
* git describe: v5.10.218-318-g853b71b570fb
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.218-318-g853b71b570fb
## Test Regressions (compared to v5.10.218)
* powerpc, build
- clang-18-allnoconfig
- clang-18-defconfig
- clang-18-mpc83xx_defconfig
- clang-18-tinyconfig
- clang-18-tqm8xx_defconfig
- gcc-12-allnoconfig
- gcc-12-cell_defconfig
- gcc-12-defconfig
- gcc-12-maple_defconfig
- gcc-12-mpc83xx_defconfig
- gcc-12-ppc64e_defconfig
- gcc-12-ppc6xx_defconfig
- gcc-12-tinyconfig
- gcc-12-tqm8xx_defconfig
riscv:
* build/clang-18-defconfig
## Metric Regressions (compared to v5.10.218)
## Test Fixes (compared to v5.10.218)
## Metric Fixes (compared to v5.10.218)
## Test result summary
total: 86688, pass: 68564, fail: 2978, skip: 15098, xfail: 48
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 104 total, 104 passed, 0 failed
* arm64: 31 total, 31 passed, 0 failed
* i386: 25 total, 25 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* parisc: 3 total, 0 passed, 3 failed
* powerpc: 23 total, 9 passed, 14 failed
* riscv: 9 total, 8 passed, 1 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 27 total, 27 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mm
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* 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-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-smoketest
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.219 release. There are 317 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 Sat, 15 Jun 2024 11:31:50 +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/v5.x/stable-review/patch-5.10.219-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Seeing the same perf build failure already reported by Harshit aginst 5.15:
In file included from util/cache.h:7,
from builtin-annotate.c:13:util/../ui/ui.h:5:10: fatal error: ../util/mutex.h: No such file or directory
5 | #include "../util/mutex.h"
| ^~~~~~~~~~~~~~~~~compilation terminated.
Thanks!
Signature · 1 line
Florian