5.10.246-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 288/332 RISC-V: Minimal parser for "riscv, isa" strings
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tsukasa OI <[email protected]>
[ Upstream commit 2a31c54be097c74344b4fab20ea6104012d2cb8b ]
Current hart ISA ("riscv,isa") parser don't correctly parse:
1. Multi-letter extensions
2. Version numbers
All ISA extensions ratified recently has multi-letter extensions (except 'H'). The current "riscv,isa" parser that is easily confused by multi-letter extensions and "p" in version numbers can be a huge problem for adding new extensions through the device tree.
Leaving it would create incompatible hacks and would make "riscv,isa" value unreliable.
This commit implements minimal parser for "riscv,isa" strings. With this, we can safely ignore multi-letter extensions and version numbers.
Stable-dep-of: d2721bb165b3 ("RISC-V: Don't print details of CPUs disabled in DT")
--- arch/riscv/kernel/cpufeature.c | 72 ++++++++++++++++++++++++++++------ 1 file changed, 61 insertions(+), 11 deletions(-)
arch/riscv/kernel/cpufeature.c +61 -11
@@ -7,6 +7,7 @@*/ #include <linux/bitmap.h> +#include <linux/ctype.h> #include <linux/of.h> #include <asm/processor.h> #include <asm/hwcap.h>
@@ -66,7 +67,7 @@ void riscv_fill_hwcap(void)struct device_node *node;const char *isa;char print_str[NUM_ALPHA_EXTS +1 ]; -size_t i, j, isa_len; +int i, j;static unsigned long isa2hwcap[256 ] = {0 }; isa2hwcap['i' ] = isa2hwcap['I' ] =COMPAT_HWCAP_ISA_I ;
@@ -92,23 +93,72 @@ void riscv_fill_hwcap(void)continue ; } - i =0 ; - isa_len =strlen (isa);#if IS_ENABLED (CONFIG_32BIT )if (!strncmp (isa,"rv32" ,4 )) - i +=4 ; + isa +=4 ;#elif IS_ENABLED (CONFIG_64BIT )if (!strncmp (isa,"rv64" ,4 )) - i +=4 ; + isa +=4 ;#endif -for (; i < isa_len; ++i) { - this_hwcap |= isa2hwcap[(unsigned char )(isa[i])]; +for (; *isa; ++isa) { +const char *ext = isa++; +const char *ext_end = isa; +bool ext_long = false, ext_err = false; + +switch (*ext) { +case 's' : +/** +* Workaround for invalid single-letter 's' & 'u'(QEMU). +* No need to set the bit in riscv_isa as 's' & 'u' are +* not valid ISA extensions. It works until multi-letter +* extension starting with "Su" appears. +*/ +if (ext[-1 ] !='_' && ext[1 ] =='u' ) { + ++isa; + ext_err = true; +break ; + } + fallthrough; +case 'x' : +case 'z' : + ext_long = true; +/* Multi-letter extension must be delimited */ +for (; *isa && *isa !='_' ; ++isa) +if (!islower (*isa) && !isdigit (*isa)) + ext_err = true; +break ; +default : +if (unlikely (!islower (*ext))) { + ext_err = true; +break ; + } +/* Find next extension */ +if (!isdigit (*isa)) +break ; +/* Skip the minor version */ +while (isdigit (*++isa)) + ; +if (*isa !='p' ) +break ; +if (!isdigit (*++isa)) { + --isa; +break ; + } +/* Skip the major version */ +while (isdigit (*++isa)) + ; +break ; + } +if (*isa !='_' ) + --isa;/* -* TODO: X, Y and Z extension parsing for Host ISA -* bitmap will be added in-future. +* TODO: Full version-aware handling including +* multi-letter extensions will be added in-future. */ -if ('a' <= isa[i] && isa[i] <'x' ) - this_isa |= (1UL << (isa[i] -'a' )); +if (ext_err || ext_long) +continue ; + this_hwcap |= isa2hwcap[(unsigned char )(*ext)]; + this_isa |= (1UL << (*ext -'a' )); }/*
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 289/332 riscv: cpu: Add 64bit hartid support on RV64
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sunil V L <[email protected]>
[ Upstream commit ad635e723e17379b192a5ba9c182e3eedfc24d16 ]
The hartid can be a 64bit value on RV64 platforms.
Add support for 64bit hartid in riscv_of_processor_hartid() and update its callers.
Stable-dep-of: d2721bb165b3 ("RISC-V: Don't print details of CPUs disabled in DT")
--- arch/riscv/include/asm/processor.h | 4 ++-- arch/riscv/kernel/cpu.c | 26 +++++++++++++++----------- arch/riscv/kernel/cpufeature.c | 6 ++++-- arch/riscv/kernel/smpboot.c | 9 +++++---- drivers/clocksource/timer-riscv.c | 15 ++++++++------- drivers/irqchip/irq-riscv-intc.c | 7 ++++--- drivers/irqchip/irq-sifive-plic.c | 7 ++++--- 7 files changed, 42 insertions(+), 32 deletions(-)
arch/riscv/include/asm/processor.h +2 -2
@@ -66,8 +66,8 @@ static inline void wait_for_interrupt(void) }struct device_node ; -int riscv_of_processor_hartid (struct device_node *node); -int riscv_of_parent_hartid (struct device_node *node); +int riscv_of_processor_hartid (struct device_node *node,unsigned long *hartid); +int riscv_of_parent_hartid (struct device_node *node,unsigned long *hartid);extern void riscv_fill_hwcap (void );
arch/riscv/kernel/cpu.c +15 -11
@@ -12,37 +12,36 @@* Returns the hart ID of the given device tree node, or -ENODEV if the node * isn't an enabled and valid RISC-V hart node. */ -int riscv_of_processor_hartid (struct device_node *node) +int riscv_of_processor_hartid (struct device_node *node,unsigned long *hart) {const char *isa; -u32 hart;if (!of_device_is_compatible (node,"riscv" )) {pr_warn ("Found incompatible CPU\n" );return -ENODEV ; } - hart =of_get_cpu_hwid (node,0 ); -if (hart == ~0U ) { + *hart = (unsigned long )of_get_cpu_hwid (node,0 ); +if (*hart == ~0UL ) {pr_warn ("Found CPU without hart ID\n" );return -ENODEV ; }if (!of_device_is_available (node)) { -pr_info ("CPU with hartid=%d is not available\n" , hart); +pr_info ("CPU with hartid=%lu is not available\n" , *hart);return -ENODEV ; }if (of_property_read_string (node,"riscv,isa" , &isa)) { -pr_warn ("CPU with hartid=%d has no \"riscv,isa\" property\n" , hart); +pr_warn ("CPU with hartid=%lu has no \"riscv,isa\" property\n" , *hart);return -ENODEV ; }if (isa[0 ] !='r' || isa[1 ] !='v' ) { -pr_warn ("CPU with hartid=%d has an invalid ISA of \"%s\"\n" , hart, isa); +pr_warn ("CPU with hartid=%lu has an invalid ISA of \"%s\"\n" , *hart, isa);return -ENODEV ; } -return hart; +return 0 ; }/*
@@ -51,11 +50,16 @@ int riscv_of_processor_hartid(struct device_node *node)* To achieve this, we walk up the DT tree until we find an active * RISC-V core (HART) node and extract the cpuid from it. */ -int riscv_of_parent_hartid (struct device_node *node) +int riscv_of_parent_hartid (struct device_node *node,unsigned long *hartid) { +int rc; +for (; node; node = node->parent) { -if (of_device_is_compatible (node,"riscv" )) -return riscv_of_processor_hartid (node); +if (of_device_is_compatible (node,"riscv" )) { + rc =riscv_of_processor_hartid (node, hartid); +if (!rc) +return 0 ; + } }return -1 ;
arch/riscv/kernel/cpufeature.c +4 -2
@@ -67,8 +67,9 @@ void riscv_fill_hwcap(void)struct device_node *node;const char *isa;char print_str[NUM_ALPHA_EXTS +1 ]; -int i, j; +int i, j, rc;static unsigned long isa2hwcap[256 ] = {0 }; +unsigned long hartid; isa2hwcap['i' ] = isa2hwcap['I' ] =COMPAT_HWCAP_ISA_I ; isa2hwcap['m' ] = isa2hwcap['M' ] =COMPAT_HWCAP_ISA_M ;
@@ -85,7 +86,8 @@ void riscv_fill_hwcap(void)unsigned long this_hwcap =0 ;unsigned long this_isa =0 ; -if (riscv_of_processor_hartid (node) <0 ) + rc =riscv_of_processor_hartid (node, &hartid); +if (rc <0 )continue ;if (of_property_read_string (node,"riscv,isa" , &isa)) {
arch/riscv/kernel/smpboot.c +5 -4
@@ -67,15 +67,16 @@ void __init smp_prepare_cpus(unsigned int max_cpus)void __init setup_smp (void ) {struct device_node *dn; -int hart; +unsigned long hart;bool found_boot_cpu = false;int cpuid =1 ; +int rc;cpu_set_ops (0 );for_each_of_cpu_node (dn) { - hart =riscv_of_processor_hartid (dn); -if (hart <0 ) + rc =riscv_of_processor_hartid (dn, &hart); +if (rc <0 )continue ;if (hart ==cpuid_to_hartid_map (0 )) {
@@ -84,7 +85,7 @@ void __init setup_smp(void)continue ; }if (cpuid >=NR_CPUS ) { -pr_warn ("Invalid cpuid [%d] for hartid [%d]\n" , +pr_warn ("Invalid cpuid [%d] for hartid [%lu]\n" , cpuid, hart);break ; }
drivers/clocksource/timer-riscv.c +8 -7
@@ -92,20 +92,21 @@ static irqreturn_t riscv_timer_interrupt(int irq, void *dev_id)static int __init riscv_timer_init_dt (struct device_node *n) { -int cpuid, hartid, error; +int cpuid, error; +unsigned long hartid;struct device_node *child;struct irq_domain *domain; - hartid =riscv_of_processor_hartid (n); -if (hartid <0 ) { -pr_warn ("Not valid hartid for node [%pOF] error = [%d]\n" , + error =riscv_of_processor_hartid (n, &hartid); +if (error <0 ) { +pr_warn ("Not valid hartid for node [%pOF] error = [%lu]\n" , n, hartid); -return hartid; +return error; } cpuid =riscv_hartid_to_cpuid (hartid);if (cpuid <0 ) { -pr_warn ("Invalid cpuid for hartid [%d]\n" , hartid); +pr_warn ("Invalid cpuid for hartid [%lu]\n" , hartid);return cpuid; }
@@ -131,7 +132,7 @@ static int __init riscv_timer_init_dt(struct device_node *n)return -ENODEV ; } -pr_info ("%s: Registering clocksource cpuid [%d] hartid [%d]\n" , +pr_info ("%s: Registering clocksource cpuid [%d] hartid [%lu]\n" , __func__, cpuid, hartid); error =clocksource_register_hz (&riscv_clocksource, riscv_timebase);if (error) {
drivers/irqchip/irq-riscv-intc.c +4 -3
@@ -95,10 +95,11 @@ static const struct irq_domain_ops riscv_intc_domain_ops = {static int __init riscv_intc_init (struct device_node *node,struct device_node *parent) { -int rc, hartid; +int rc; +unsigned long hartid; - hartid =riscv_of_parent_hartid (node); -if (hartid <0 ) { + rc =riscv_of_parent_hartid (node, &hartid); +if (rc <0 ) {pr_warn ("unable to find hart id for %pOF\n" , node);return 0 ; }
drivers/irqchip/irq-sifive-plic.c +4 -3
@@ -315,7 +315,8 @@ static int __init plic_init(struct device_node *node,for (i =0 ; i < nr_contexts; i++) {struct of_phandle_args parent;irq_hw_number_t hwirq; -int cpu, hartid; +int cpu; +unsigned long hartid;if (of_irq_parse_one (node, i, &parent)) {pr_err ("failed to parse parent for context %d.\n" , i);
@@ -329,8 +330,8 @@ static int __init plic_init(struct device_node *node,if (parent.args[0 ] !=RV_IRQ_EXT )continue ; - hartid =riscv_of_parent_hartid (parent.np); -if (hartid <0 ) { + error =riscv_of_parent_hartid (parent.np, &hartid); +if (error <0 ) {pr_warn ("failed to parse hart ID for context %d.\n" , i);continue ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 290/332 RISC-V: Dont print details of CPUs disabled in DT
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anup Patel <[email protected]>
[ Upstream commit d2721bb165b3ee00dd23525885381af07fec852a ]
Early boot stages may disable CPU DT nodes for unavailable CPUs based on SKU, pinstraps, eFuse, etc. Currently, the riscv_early_of_processor_hartid() prints details of a CPU if it is disabled in DT which has no value and gives a false impression to the users that there some issue with the CPU.
--- arch/riscv/kernel/cpu.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
arch/riscv/kernel/cpu.c +1 -3
@@ -27,10 +27,8 @@ int riscv_of_processor_hartid(struct device_node *node, unsigned long *hart)return -ENODEV ; } -if (!of_device_is_available (node)) { -pr_info ("CPU with hartid=%lu is not available\n" , *hart); +if (!of_device_is_available (node))return -ENODEV ; - }if (of_property_read_string (node,"riscv,isa" , &isa)) {pr_warn ("CPU with hartid=%lu has no \"riscv,isa\" property\n" , *hart);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 291/332 USB: serial: option: add UNISOC UIS7720
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Renjun Wang <[email protected]>
commit 71c07570b918f000de5d0f7f1bf17a2887e303b5 upstream.
Add support for UNISOC (Spreadtrum) UIS7720 (A7720) module.
T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1782 ProdID=4064 Rev=04.04 S: Manufacturer=Unisoc-phone S: Product=Unisoc-phone S: SerialNumber=0123456789ABCDEF C: #Ifs= 9 Cfg#= 1 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
0&1: RNDIS, 2: LOG, 3: DIAG, 4&5: AT Ports, 6&7: AT2 Ports, 8: ADB
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -617,6 +617,7 @@ static void option_instat_callback(struc#define UNISOC_VENDOR_ID 0x1782/* TOZED LT70-C based on UNISOC SL8563 uses UNISOC's vendor ID */ #define TOZED_PRODUCT_LT70C 0x4055 +#define UNISOC_PRODUCT_UIS7720 0x4064/* Luat Air72*U series based on UNISOC UIS8910 uses UNISOC's vendor ID */ #define LUAT_PRODUCT_AIR720U 0x4e00
@@ -2466,6 +2467,7 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9291, 0xff, 0xff, 0x30) }, { USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9291, 0xff, 0xff, 0x40) }, { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, TOZED_PRODUCT_LT70C, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, UNISOC_PRODUCT_UIS7720, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, LUAT_PRODUCT_AIR720U, 0xff, 0, 0) }, { USB_DEVICE_INTERFACE_CLASS(0x1bbb, 0x0530, 0xff), /* TCL IK512 MBIM */ .driver_info = NCTRL(1) },
Greg Kroah-Hartman
maintainerPATCH 292/332 USB: serial: option: add Quectel RG255C
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Reinhard Speyerer <[email protected]>
commit 89205c60c0fc96b73567a2e9fe27ee3f59d01193 upstream.
Add support for Quectel RG255C devices to complement commit 5c964c8a97c1 ("net: usb: qmi_wwan: add Quectel RG255C").
The composition is DM / NMEA / AT / QMI.
T: Bus=01 Lev=02 Prnt=99 Port=01 Cnt=02 Dev#=110 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0316 Rev= 5.15 S: Manufacturer=Quectel S: Product=RG255C-GL S: SerialNumber=xxxxxxxx C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=86(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
--- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -273,6 +273,7 @@ static void option_instat_callback(struc#define QUECTEL_PRODUCT_EM05CN 0x0312#define QUECTEL_PRODUCT_EM05G_GR 0x0313#define QUECTEL_PRODUCT_EM05G_RS 0x0314 +#define QUECTEL_PRODUCT_RG255C 0x0316#define QUECTEL_PRODUCT_EM12 0x0512#define QUECTEL_PRODUCT_RM500Q 0x0800#define QUECTEL_PRODUCT_RM520N 0x0801
@@ -1271,6 +1272,9 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM500K, 0xff, 0x00, 0x00) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG650V, 0xff, 0xff, 0x30) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG650V, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C, 0xff, 0xff, 0x30) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C, 0xff, 0xff, 0x40) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
Greg Kroah-Hartman
maintainerPATCH 293/332 USB: serial: option: add Telit FN920C04 ECM compositions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: LI Qingwu <[email protected]>
commit 622865c73ae30f254abdf182f4b66cccbe3e0f10 upstream.
Add support for the Telit Cinterion FN920C04 module when operating in ECM (Ethernet Control Model) mode. The following USB product IDs are used by the module when AT#USBCFG is set to 3 or 7.
0x10A3: ECM + tty (NMEA) + tty (DUN) [+ tty (DIAG)]
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10a3 Rev= 5.15 S: Manufacturer=Telit Cinterion S: Product=FN920 S: SerialNumber=76e7cb38 C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
0x10A8: ECM + tty (DUN) + tty (AUX) [+ tty (DIAG)]
T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10a8 Rev= 5.15 S: Manufacturer=Telit Cinterion S: Product=FN920 S: SerialNumber=76e7cb38 C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Adding these IDs allows the option driver to automatically create the corresponding /dev/ttyUSB* ports under ECM mode.
Tested with FN920C04 under ECM configuration (USBCFG=3 and 7).
--- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -1403,10 +1403,14 @@ static const struct usb_device_id option .driver_info = RSVD(0) | NCTRL(3) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a2, 0xff), /* Telit FN920C04 (MBIM) */ .driver_info = NCTRL(4) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a3, 0xff), /* Telit FN920C04 (ECM) */ + .driver_info = NCTRL(4) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a4, 0xff), /* Telit FN20C04 (rmnet) */ .driver_info = RSVD(0) | NCTRL(3) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a7, 0xff), /* Telit FN920C04 (MBIM) */ .driver_info = NCTRL(4) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a8, 0xff), /* Telit FN920C04 (ECM) */ + .driver_info = NCTRL(4) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a9, 0xff), /* Telit FN20C04 (rmnet) */ .driver_info = RSVD(0) | NCTRL(2) | RSVD(3) | RSVD(4) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10aa, 0xff), /* Telit FN920C04 (MBIM) */
Greg Kroah-Hartman
maintainerPATCH 294/332 usb/core/quirks: Add Huawei ME906S to wakeup quirk
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tim Guttzeit <[email protected]>
commit dfc2cf4dcaa03601cd4ca0f7def88b2630fca6ab upstream.
The list of Huawei LTE modules needing the quirk fixing spurious wakeups was missing the IDs of the Huawei ME906S module, therefore suspend did not work.
--- drivers/usb/core/quirks.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/core/quirks.c +2 -0
@@ -462,6 +462,8 @@ static const struct usb_device_id usb_qu/* Huawei 4G LTE module */ { USB_DEVICE(0x12d1, 0x15bb), .driver_info = USB_QUIRK_DISCONNECT_SUSPEND }, + { USB_DEVICE(0x12d1, 0x15c1), .driver_info = + USB_QUIRK_DISCONNECT_SUSPEND }, { USB_DEVICE(0x12d1, 0x15c3), .driver_info = USB_QUIRK_DISCONNECT_SUSPEND },
Greg Kroah-Hartman
maintainerPATCH 295/332 usb: raw-gadget: do not limit transfer length
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Konovalov <[email protected]>
commit 37b9dd0d114a0e38c502695e30f55a74fb0c37d0 upstream.
Drop the check on the maximum transfer length in Raw Gadget for both control and non-control transfers.
Limiting the transfer length causes a problem with emulating USB devices whose full configuration descriptor exceeds PAGE_SIZE in length.
Overall, there does not appear to be any reason to enforce any kind of transfer length limit on the Raw Gadget side for either control or non-control transfers, so let's just drop the related check.
--- drivers/usb/gadget/legacy/raw_gadget.c | 2 -- 1 file changed, 2 deletions(-)
drivers/usb/gadget/legacy/raw_gadget.c +0 -2
@@ -619,8 +619,6 @@ static void *raw_alloc_io_data(struct usreturn ERR_PTR (-EINVAL );if (!usb_raw_io_flags_valid (io->flags))return ERR_PTR (-EINVAL ); -if (io->length >PAGE_SIZE ) -return ERR_PTR (-EINVAL );if (get_from_user) data =memdup_user (ptr +sizeof (*io), io->length);else {
Greg Kroah-Hartman
maintainerPATCH 296/332 xhci: dbc: enable back DbC in resume if it was enabled before suspend
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit 2bbd38fcd29670e46c0fdb9cd0e90507a8a1bf6a upstream.
DbC is currently only enabled back if it's in configured state during suspend.
If system is suspended after DbC is enabled, but before the device is properly enumerated by the host, then DbC would not be enabled back in resume.
Always enable DbC back in resume if it's suspended in enabled, connected, or configured state
--- drivers/usb/host/xhci-dbgcap.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/usb/host/xhci-dbgcap.c +8 -1
@@ -1147,8 +1147,15 @@ int xhci_dbc_suspend(struct xhci_hcd *xhif (!dbc)return 0 ; -if (dbc->state ==DS_CONFIGURED ) +switch (dbc->state) { +case DS_ENABLED : +case DS_CONNECTED : +case DS_CONFIGURED : dbc->resume_required =1 ; +break ; +default : +break ; + }xhci_dbc_stop (dbc);
Greg Kroah-Hartman
maintainerPATCH 297/332 binder: remove "invalid inc weak" check
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alice Ryhl <[email protected]>
commit d90eeb8ecd227c204ab6c34a17b372bd950b7aa2 upstream.
There are no scenarios where a weak increment is invalid on binder_node. The only possible case where it could be invalid is if the kernel delivers BR_DECREFS to the process that owns the node, and then increments the weak refcount again, effectively "reviving" a dead node.
However, that is not possible: when the BR_DECREFS command is delivered, the kernel removes and frees the binder_node. The fact that you were able to call binder_inc_node_nilocked() implies that the node is not yet destroyed, which implies that BR_DECREFS has not been delivered to userspace, so incrementing the weak refcount is valid.
Note that it's currently possible to trigger this condition if the owner calls BINDER_THREAD_EXIT while node->has_weak_ref is true. This causes BC_INCREFS on binder_ref instances to fail when they should not.
--- drivers/android/binder.c | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-)
drivers/android/binder.c +1 -10
@@ -1204,17 +1204,8 @@ static int binder_inc_node_nilocked(stru }else {if (!internal) node->local_weak_refs++; -if (!node->has_weak_ref &&list_empty (&node->work.entry)) { -if (target_list ==NULL ) { -pr_err ("invalid inc weak node for %d\n" , - node->debug_id); -return -EINVAL ; - } -/* -* See comment above -*/ +if (!node->has_weak_ref && target_list &&list_empty (&node->work.entry))binder_enqueue_work_ilocked (&node->work, target_list); - } }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 298/332 comedi: fix divide-by-zero in comedi_buf_munge()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepanshu Kartikey <[email protected]>
commit 87b318ba81dda2ee7b603f4f6c55e78ec3e95974 upstream.
The comedi_buf_munge() function performs a modulo operation async->munge_chan %= async->cmd.chanlist_len without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path.
Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging.
This prevents potential kernel panics from malformed user commands.
--- drivers/staging/comedi/comedi_buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/comedi/comedi_buf.c +1 -1
@@ -369,7 +369,7 @@ static unsigned int comedi_buf_munge(strunsigned int count =0 ;const unsigned int num_sample_bytes =comedi_bytes_per_sample (s); -if (!s->munge || (async->cmd.flags &CMDF_RAWDATA )) { +if (!s->munge || (async->cmd.flags &CMDF_RAWDATA ) || async->cmd.chanlist_len ==0 ) { async->munge_count += num_bytes; count = num_bytes; }else {
Greg Kroah-Hartman
maintainerPATCH 299/332 mei: me: add wildcat lake P DID
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Usyskin <[email protected]>
commit 410d6c2ad4d1a88efa0acbb9966693725b564933 upstream.
Add Wildcat Lake P device id.
--- drivers/misc/mei/hw-me-regs.h | 2 ++ drivers/misc/mei/pci-me.c | 2 ++ 2 files changed, 4 insertions(+)
drivers/misc/mei/hw-me-regs.h +2 -0
@@ -120,6 +120,8 @@#define MEI_DEV_ID_PTL_H 0xE370/* Panther Lake H */ #define MEI_DEV_ID_PTL_P 0xE470/* Panther Lake P */ +#define MEI_DEV_ID_WCL_P 0x4D70/* Wildcat Lake P */ +/* * MEI HW Section */
drivers/misc/mei/pci-me.c +2 -0
@@ -126,6 +126,8 @@ static const struct pci_device_id mei_me {MEI_PCI_DEVICE(MEI_DEV_ID_PTL_H, MEI_ME_PCH15_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_PTL_P, MEI_ME_PCH15_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_WCL_P, MEI_ME_PCH15_CFG)}, +/* required last entry */ {0, } };
Greg Kroah-Hartman
maintainerPATCH 300/332 most: usb: Fix use-after-free in hdm_disconnect
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Victoria Votokina <[email protected]>
commit 4b1270902609ef0d935ed2faa2ea6d122bd148f5 upstream.
hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing.
The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts).
Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface().
This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.
--- drivers/most/most_usb.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
drivers/most/most_usb.c +4 -7
@@ -929,6 +929,10 @@ static void release_mdev(struct device * {struct most_dev *mdev =to_mdev_from_dev (dev); +kfree (mdev->busy_urbs); +kfree (mdev->cap); +kfree (mdev->conf); +kfree (mdev->ep_address);kfree (mdev); }/**
@@ -1121,13 +1125,6 @@ static void hdm_disconnect(struct usb_inif (mdev->dci)device_unregister (&mdev->dci->dev);most_deregister_interface (&mdev->iface); - -kfree (mdev->busy_urbs); -kfree (mdev->cap); -kfree (mdev->conf); -kfree (mdev->ep_address); -put_device (&mdev->dci->dev); -put_device (&mdev->dev); }static int hdm_suspend (struct usb_interface *interface,pm_message_t message)
Greg Kroah-Hartman
maintainerPATCH 301/332 most: usb: hdm_probe: Fix calling put_device() before device initialization
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Victoria Votokina <[email protected]>
commit a8cc9e5fcb0e2eef21513a4fec888f5712cb8162 upstream.
The early error path in hdm_probe() can jump to err_free_mdev before &mdev->dev has been initialized with device_initialize(). Calling put_device(&mdev->dev) there triggers a device core WARN and ends up invoking kref_put(&kobj->kref, kobject_release) on an uninitialized kobject.
In this path the private struct was only kmalloc'ed and the intended release is effectively kfree(mdev) anyway, so free it directly instead of calling put_device() on an uninitialized device.
This removes the WARNING and fixes the pre-initialization error path.
--- drivers/most/most_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/most/most_usb.c +1 -1
@@ -1097,7 +1097,7 @@ err_free_cap: err_free_conf:kfree (mdev->conf); err_free_mdev: -put_device (&mdev->dev); +kfree (mdev);return ret; }
Greg Kroah-Hartman
maintainerPATCH 302/332 serial: 8250_exar: add support for Advantech 2 port card with Device ID 0x0018
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Eckert <[email protected]>
commit e7cbce761fe3fcbcb49bcf30d4f8ca5e1a9ee2a0 upstream.
The Advantech 2-port serial card with PCI vendor=0x13fe and device=0x0018 has a 'XR17V35X' chip installed on the circuit board. Therefore, this driver can be used instead of theu outdated out-of-tree driver from the manufacturer.
--- drivers/tty/serial/8250/8250_exar.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/tty/serial/8250/8250_exar.c +11 -0
@@ -33,6 +33,8 @@#define PCI_DEVICE_ID_ACCESSIO_COM_4SM 0x10db#define PCI_DEVICE_ID_ACCESSIO_COM_8SM 0x10ea +#define PCI_DEVICE_ID_ADVANTECH_XR17V352 0x0018 +#define PCI_DEVICE_ID_COMMTECH_4224PCI335 0x0002#define PCI_DEVICE_ID_COMMTECH_4222PCI335 0x0004#define PCI_DEVICE_ID_COMMTECH_2324PCI335 0x000a
@@ -815,6 +817,12 @@ static const struct exar8250_board pbn_f .exit = pci_xr17v35x_exit, }; +static const struct exar8250_board pbn_adv_XR17V352 = { + .num_ports =2 , + .setup = pci_xr17v35x_setup, + .exit = pci_xr17v35x_exit, +}; +static const struct exar8250_board pbn_exar_XR17V4358 = { .num_ports =12 , .setup = pci_xr17v35x_setup,
@@ -884,6 +892,9 @@ static const struct pci_device_id exar_pUSR_DEVICE (XR17C152 ,2980 , pbn_exar_XR17C15x),USR_DEVICE (XR17C152 ,2981 , pbn_exar_XR17C15x), +/* ADVANTECH devices */ +EXAR_DEVICE (ADVANTECH ,XR17V352 , pbn_adv_XR17V352), +/* Exar Corp. XR17C15[248] Dual/Quad/Octal UART */ EXAR_DEVICE (EXAR ,XR17C152 , pbn_exar_XR17C15x), EXAR_DEVICE(EXAR, XR17C154, pbn_exar_XR17C15x),
Greg Kroah-Hartman
maintainerPATCH 303/332 arm64: cputype: Add Neoverse-V3AE definitions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit 3bbf004c4808e2c3241e5c1ad6cc102f38a03c39 upstream.
Add cputype definitions for Neoverse-V3AE. These will be used for errata detection in subsequent patches.
These values can be found in the Neoverse-V3AE TRM:
https://developer.arm.com/documentation/SDEN-2615521/9-0/
... in section A.6.1 ("MIDR_EL1, Main ID Register").
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -92,6 +92,7 @@#define ARM_CPU_PART_NEOVERSE_V2 0xD4F#define ARM_CPU_PART_CORTEX_A720 0xD81#define ARM_CPU_PART_CORTEX_X4 0xD82 +#define ARM_CPU_PART_NEOVERSE_V3AE 0xD83#define ARM_CPU_PART_NEOVERSE_V3 0xD84#define ARM_CPU_PART_CORTEX_X925 0xD85#define ARM_CPU_PART_CORTEX_A725 0xD87
@@ -157,6 +158,7 @@#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2)#define MIDR_CORTEX_A720 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720)#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4) +#define MIDR_NEOVERSE_V3AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3AE)#define MIDR_NEOVERSE_V3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3)#define MIDR_CORTEX_X925 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X925)#define MIDR_CORTEX_A725 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A725)
Greg Kroah-Hartman
maintainerPATCH 304/332 arm64: errata: Apply workarounds for Neoverse-V3AE
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit 0c33aa1804d101c11ba1992504f17a42233f0e11 upstream.
Neoverse-V3AE is also affected by erratum #3312417, as described in its Software Developer Errata Notice (SDEN) document:
Neoverse V3AE (MP172) SDEN v9.0, erratum 3312417
https://developer.arm.com/documentation/SDEN-2615521/9-0/
Enable the workaround for Neoverse-V3AE, and document this.
--- Documentation/arm64/silicon-errata.rst | 2 ++ arch/arm64/Kconfig | 1 + arch/arm64/kernel/cpu_errata.c | 1 + 3 files changed, 4 insertions(+)
Documentation/arm64/silicon-errata.rst +2 -0
@@ -144,6 +144,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-V3AE | #3312417 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-500 | #841119,826419 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+
arch/arm64/Kconfig +1 -0
@@ -718,6 +718,7 @@ config ARM64_ERRATUM_3194386 * ARM Neoverse-V1 erratum 3324341 * ARM Neoverse V2 erratum 3324336 * ARM Neoverse-V3 erratum 3312417 + * ARM Neoverse-V3AE erratum 3312417 On affected cores "MSR SSBS, #0" instructions may not affect subsequent speculative instructions, which may permit unexepected
arch/arm64/kernel/cpu_errata.c +1 -0
@@ -386,6 +386,7 @@ static const struct midr_range erratum_sMIDR_ALL_VERSIONS (MIDR_NEOVERSE_V1 ),MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V2 ),MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V3 ), + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3AE), {} };#endif
Greg Kroah-Hartman
maintainerPATCH 305/332 vsock: fix lock inversion in vsock_assign_transport()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefano Garzarella <[email protected]>
commit f7c877e7535260cc7a21484c994e8ce7e8cb6780 upstream.
Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.
The issue was introduced by commit 687aa0c5581b ("vsock: Fix transport_* TOCTOU") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created.
Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().
--- net/vmw_vsock/af_vsock.c | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-)
net/vmw_vsock/af_vsock.c +19 -19
@@ -479,12 +479,26 @@ int vsock_assign_transport(struct vsock_ goto err; } -if (vsk->transport) { -if (vsk->transport == new_transport) { - ret =0 ; - goto err; - } +if (vsk->transport && vsk->transport == new_transport) { + ret =0 ; + goto err; + } + +/* We increase the module refcnt to prevent the transport unloading +* while there are open sockets assigned to it. +*/ +if (!new_transport || !try_module_get (new_transport->module)) { + ret = -ENODEV ; + goto err; + } + +/* It's safe to release the mutex after a successful try_module_get(). +* Whichever transport `new_transport` points at, it won't go away until +* the last module_put() below or in vsock_deassign_transport(). +*/ +mutex_unlock (&vsock_register_mutex); +if (vsk->transport) {/* transport->release() must be called with sock lock acquired. * This path can only be taken during vsock_stream_connect(), * where we have already held the sock lock.
@@ -504,20 +518,6 @@ int vsock_assign_transport(struct vsock_ vsk->peer_shutdown =0 ; } -/* We increase the module refcnt to prevent the transport unloading -* while there are open sockets assigned to it. -*/ -if (!new_transport || !try_module_get (new_transport->module)) { - ret = -ENODEV ; - goto err; - } - -/* It's safe to release the mutex after a successful try_module_get(). -* Whichever transport `new_transport` points at, it won't go away until -* the last module_put() below or in vsock_deassign_transport(). -*/ -mutex_unlock (&vsock_register_mutex); - ret = new_transport->init (vsk, psk);if (ret) {module_put (new_transport->module);
Greg Kroah-Hartman
maintainerPATCH 306/332 media: s5p-mfc: remove an unused/uninitialized variable
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 7fa37ba25a1dfc084e24ea9acc14bf1fad8af14c ]
The s5p_mfc_cmd_args structure in the v6 driver is never used, not initialized to anything other than zero, but as of clang-21 this causes a warning:
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c:45:7: error: variable 'h2r_args' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
45 | &h2r_args);
| ^~~~~~~~
Just remove this for simplicity. Since the function is also called through a callback, this does require adding a trivial wrapper with the correct prototype.
--- drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c | 35 ++++++++---------------- 1 file changed, 13 insertions(+), 22 deletions(-)
drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c +13 -22
@@ -14,8 +14,7 @@#include "s5p_mfc_opr.h" #include "s5p_mfc_cmd_v6.h" -static int s5p_mfc_cmd_host2risc_v6 (struct s5p_mfc_dev *dev,int cmd, -struct s5p_mfc_cmd_args *args) +static int s5p_mfc_cmd_host2risc_v6 (struct s5p_mfc_dev *dev,int cmd) {mfc_debug (2 ,"Issue the command: %d\n" , cmd);
@@ -31,7 +30,6 @@ static int s5p_mfc_cmd_host2risc_v6(strustatic int s5p_mfc_sys_init_cmd_v6 (struct s5p_mfc_dev *dev) { -struct s5p_mfc_cmd_args h2r_args;struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size->priv;int ret;
@@ -41,33 +39,23 @@ static int s5p_mfc_sys_init_cmd_v6(strucmfc_write (dev, dev->ctx_buf.dma,S5P_FIMV_CONTEXT_MEM_ADDR_V6 );mfc_write (dev, buf_size->dev_ctx,S5P_FIMV_CONTEXT_MEM_SIZE_V6 ); -return s5p_mfc_cmd_host2risc_v6 (dev,S5P_FIMV_H2R_CMD_SYS_INIT_V6 , - &h2r_args); +return s5p_mfc_cmd_host2risc_v6 (dev,S5P_FIMV_H2R_CMD_SYS_INIT_V6 ); }static int s5p_mfc_sleep_cmd_v6 (struct s5p_mfc_dev *dev) { -struct s5p_mfc_cmd_args h2r_args; - -memset (&h2r_args,0 ,sizeof (struct s5p_mfc_cmd_args )); -return s5p_mfc_cmd_host2risc_v6 (dev,S5P_FIMV_H2R_CMD_SLEEP_V6 , - &h2r_args); +return s5p_mfc_cmd_host2risc_v6 (dev,S5P_FIMV_H2R_CMD_SLEEP_V6 ); }static int s5p_mfc_wakeup_cmd_v6 (struct s5p_mfc_dev *dev) { -struct s5p_mfc_cmd_args h2r_args; - -memset (&h2r_args,0 ,sizeof (struct s5p_mfc_cmd_args )); -return s5p_mfc_cmd_host2risc_v6 (dev,S5P_FIMV_H2R_CMD_WAKEUP_V6 , - &h2r_args); +return s5p_mfc_cmd_host2risc_v6 (dev,S5P_FIMV_H2R_CMD_WAKEUP_V6 ); }/* Open a new instance and get its number */ static int s5p_mfc_open_inst_cmd_v6 (struct s5p_mfc_ctx *ctx) {struct s5p_mfc_dev *dev = ctx->dev; -struct s5p_mfc_cmd_args h2r_args;int codec_type;mfc_debug (2 ,"Requested codec mode: %d\n" , ctx->codec_mode);
@@ -129,23 +117,20 @@ static int s5p_mfc_open_inst_cmd_v6(strumfc_write (dev, ctx->ctx.size,S5P_FIMV_CONTEXT_MEM_SIZE_V6 );mfc_write (dev,0 ,S5P_FIMV_D_CRC_CTRL_V6 );/* no crc */ -return s5p_mfc_cmd_host2risc_v6 (dev,S5P_FIMV_H2R_CMD_OPEN_INSTANCE_V6 , - &h2r_args); +return s5p_mfc_cmd_host2risc_v6 (dev,S5P_FIMV_H2R_CMD_OPEN_INSTANCE_V6 ); }/* Close instance */ static int s5p_mfc_close_inst_cmd_v6 (struct s5p_mfc_ctx *ctx) {struct s5p_mfc_dev *dev = ctx->dev; -struct s5p_mfc_cmd_args h2r_args;int ret =0 ; dev->curr_ctx = ctx->num;if (ctx->state !=MFCINST_FREE ) {mfc_write (dev, ctx->inst_no,S5P_FIMV_INSTANCE_ID_V6 ); ret =s5p_mfc_cmd_host2risc_v6 (dev, -S5P_FIMV_H2R_CMD_CLOSE_INSTANCE_V6 , - &h2r_args); +S5P_FIMV_H2R_CMD_CLOSE_INSTANCE_V6 ); }else { ret = -EINVAL ; }
@@ -153,9 +138,15 @@ static int s5p_mfc_close_inst_cmd_v6(strreturn ret; } +static int s5p_mfc_cmd_host2risc_v6_args (struct s5p_mfc_dev *dev,int cmd, +struct s5p_mfc_cmd_args *ignored) +{ +return s5p_mfc_cmd_host2risc_v6 (dev, cmd); +} +/* Initialize cmd function pointers for MFC v6 */ static struct s5p_mfc_hw_cmds s5p_mfc_cmds_v6 = { - .cmd_host2risc = s5p_mfc_cmd_host2risc_v6, + .cmd_host2risc = s5p_mfc_cmd_host2risc_v6_args, .sys_init_cmd = s5p_mfc_sys_init_cmd_v6, .sleep_cmd = s5p_mfc_sleep_cmd_v6, .wakeup_cmd = s5p_mfc_wakeup_cmd_v6,
Greg Kroah-Hartman
maintainerPATCH 307/332 padata: Reset next CPU when reorder sequence wraps around
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiao Liang <[email protected]>
[ Upstream commit 501302d5cee0d8e8ec2c4a5919c37e0df9abc99b ]
When seq_nr wraps around, the next reorder job with seq 0 is hashed to the first CPU in padata_do_serial(). Correspondingly, need reset pd->cpu to the first one when pd->processed wraps around. Otherwise, if the number of used CPUs is not a power of 2, padata_find_next() will be checking a wrong list, hence deadlock.
--- kernel/padata.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
kernel/padata.c +5 -1
@@ -295,7 +295,11 @@ static struct padata_priv *padata_find_nif (remove_object) {list_del_init (&padata->list); ++pd->processed; - pd->cpu =cpumask_next_wrap (cpu, pd->cpumask.pcpu,-1 , false); +/* When sequence wraps around, reset to the first CPU. */ +if (unlikely (pd->processed ==0 )) + pd->cpu =cpumask_first (pd->cpumask.pcpu); +else + pd->cpu =cpumask_next_wrap (cpu, pd->cpumask.pcpu,-1 , false); }spin_unlock (&reorder->lock);
Greg Kroah-Hartman
maintainerPATCH 308/332 iio: imu: inv_icm42600: use = { } instead of memset()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Lechner <[email protected]>
[ Upstream commit 352112e2d9aab6a156c2803ae14eb89a9fd93b7d ]
Use { } instead of memset() to zero-initialize stack memory to simplify the code.
Stable-dep-of: 466f7a2fef2a ("iio: imu: inv_icm42600: Avoid configuring if already pm_runtime suspended")
--- drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c | 5 ++--- drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c | 5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-)
drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c +2 -3
@@ -751,7 +751,8 @@ int inv_icm42600_accel_parse_fifo(structconst int8_t *temp;unsigned int odr;int64_t ts_val; -struct inv_icm42600_accel_buffer buffer; +/* buffer is copied to userspace, zeroing it to avoid any data leak */ +struct inv_icm42600_accel_buffer buffer = { };/* parse all fifo packets */ for (i =0 , no =0 ; i < st->fifo.count; i += size, ++no) {
@@ -770,8 +771,6 @@ int inv_icm42600_accel_parse_fifo(structinv_icm42600_timestamp_apply_odr (ts, st->fifo.period, st->fifo.nb.total, no); -/* buffer is copied to userspace, zeroing it to avoid any data leak */ -memset (&buffer,0 ,sizeof (buffer));memcpy (&buffer.accel, accel,sizeof (buffer.accel));/* convert 8 bits FIFO temperature in high resolution format */ buffer.temp = temp ? (*temp *64 ) :0 ;
drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c +2 -3
@@ -762,7 +762,8 @@ int inv_icm42600_gyro_parse_fifo(structconst int8_t *temp;unsigned int odr;int64_t ts_val; -struct inv_icm42600_gyro_buffer buffer; +/* buffer is copied to userspace, zeroing it to avoid any data leak */ +struct inv_icm42600_gyro_buffer buffer = { };/* parse all fifo packets */ for (i =0 , no =0 ; i < st->fifo.count; i += size, ++no) {
@@ -781,8 +782,6 @@ int inv_icm42600_gyro_parse_fifo(structinv_icm42600_timestamp_apply_odr (ts, st->fifo.period, st->fifo.nb.total, no); -/* buffer is copied to userspace, zeroing it to avoid any data leak */ -memset (&buffer,0 ,sizeof (buffer));memcpy (&buffer.gyro, gyro,sizeof (buffer.gyro));/* convert 8 bits FIFO temperature in high resolution format */ buffer.temp = temp ? (*temp *64 ) :0 ;
Greg Kroah-Hartman
maintainerPATCH 309/332 iio: imu: inv_icm42600: Avoid configuring if already pm_runtime suspended
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Nyekjaer <[email protected]>
[ Upstream commit 466f7a2fef2a4e426f809f79845a1ec1aeb558f4 ]
Do as in suspend, skip resume configuration steps if the device is already pm_runtime suspended. This avoids reconfiguring a device that is already in the correct low-power state and ensures that pm_runtime handles the power state transitions properly.
--- drivers/iio/imu/inv_icm42600/inv_icm42600_core.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/iio/imu/inv_icm42600/inv_icm42600_core.c +6 -5
@@ -680,17 +680,15 @@ EXPORT_SYMBOL_GPL(inv_icm42600_core_probstatic int __maybe_unused inv_icm42600_suspend (struct device *dev) {struct inv_icm42600_state *st =dev_get_drvdata (dev); -int ret; +int ret =0 ;mutex_lock (&st->lock); st->suspended.gyro = st->conf.gyro.mode; st->suspended.accel = st->conf.accel.mode; st->suspended.temp = st->conf.temp_en; -if (pm_runtime_suspended (dev)) { - ret =0 ; +if (pm_runtime_suspended (dev)) goto out_unlock; - }/* disable FIFO data streaming */ if (st->fifo.on) {
@@ -722,10 +720,13 @@ static int __maybe_unused inv_icm42600_rstruct inv_icm42600_state *st =dev_get_drvdata (dev);struct inv_icm42600_timestamp *gyro_ts =iio_priv (st->indio_gyro);struct inv_icm42600_timestamp *accel_ts =iio_priv (st->indio_accel); -int ret; +int ret =0 ;mutex_lock (&st->lock); +if (pm_runtime_suspended (dev)) + goto out_unlock; + ret =inv_icm42600_enable_regulator_vddio (st);if (ret) goto out_unlock;
Greg Kroah-Hartman
maintainerPATCH 310/332 PM: runtime: Add new devm functions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bence Csókás <[email protected]>
[ Upstream commit 73db799bf5efc5a04654bb3ff6c9bf63a0dfa473 ]
Add devm_pm_runtime_set_active_enabled() anddevm_pm_runtime_get_noresume() for simplifying
common cases in drivers.
Stable-dep-of: 0792c1984a45 ("iio: imu: inv_icm42600: Simplify pm_runtime setup")
--- drivers/base/power/runtime.c | 44 +++++++++++++++++++++++++++++++++++++++++++ include/linux/pm_runtime.h | 4 +++ 2 files changed, 48 insertions(+)
drivers/base/power/runtime.c +44 -0
@@ -1479,6 +1479,32 @@ void pm_runtime_enable(struct device *de }EXPORT_SYMBOL_GPL (pm_runtime_enable); +static void pm_runtime_set_suspended_action (void *data) +{ +pm_runtime_set_suspended (data); +} + +/** +* devm_pm_runtime_set_active_enabled - set_active version of devm_pm_runtime_enable. +* +* @dev: Device to handle. +*/ +int devm_pm_runtime_set_active_enabled (struct device *dev) +{ +int err; + + err =pm_runtime_set_active (dev); +if (err) +return err; + + err =devm_add_action_or_reset (dev, pm_runtime_set_suspended_action, dev); +if (err) +return err; + +return devm_pm_runtime_enable (dev); +} +EXPORT_SYMBOL_GPL (devm_pm_runtime_set_active_enabled); +static void pm_runtime_disable_action (void *data) {pm_runtime_dont_use_autosuspend (data);
@@ -1501,6 +1527,24 @@ int devm_pm_runtime_enable(struct device }EXPORT_SYMBOL_GPL (devm_pm_runtime_enable); +static void pm_runtime_put_noidle_action (void *data) +{ +pm_runtime_put_noidle (data); +} + +/** +* devm_pm_runtime_get_noresume - devres-enabled version of pm_runtime_get_noresume. +* +* @dev: Device to handle. +*/ +int devm_pm_runtime_get_noresume (struct device *dev) +{ +pm_runtime_get_noresume (dev); + +return devm_add_action_or_reset (dev, pm_runtime_put_noidle_action, dev); +} +EXPORT_SYMBOL_GPL (devm_pm_runtime_get_noresume); +/** * pm_runtime_forbid - Block runtime PM of a device. * @dev: Device to handle.
include/linux/pm_runtime.h +4 -0
@@ -61,7 +61,9 @@ extern void pm_runtime_new_link(struct dextern void pm_runtime_drop_link (struct device_link *link);extern void pm_runtime_release_supplier (struct device_link *link); +int devm_pm_runtime_set_active_enabled (struct device *dev);extern int devm_pm_runtime_enable (struct device *dev); +int devm_pm_runtime_get_noresume (struct device *dev);/** * pm_runtime_get_if_in_use - Conditionally bump up runtime PM usage counter.
@@ -258,7 +260,9 @@ static inline void __pm_runtime_disable(static inline void pm_runtime_allow (struct device *dev) {}static inline void pm_runtime_forbid (struct device *dev) {} +static inline int devm_pm_runtime_set_active_enabled (struct device *dev) {return 0 ; }static inline int devm_pm_runtime_enable (struct device *dev) {return 0 ; } +static inline int devm_pm_runtime_get_noresume (struct device *dev) {return 0 ; }static inline void pm_suspend_ignore_children (struct device *dev,bool enable) {}static inline void pm_runtime_get_noresume (struct device *dev) {}
Greg Kroah-Hartman
maintainerPATCH 311/332 iio: imu: inv_icm42600: Simplify pm_runtime setup
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Nyekjaer <[email protected]>
[ Upstream commit 0792c1984a45ccd7a296d6b8cb78088bc99a212e ]
Rework the power management in inv_icm42600_core_probe() to use devm_pm_runtime_set_active_enabled(), which simplifies the runtime PM setup by handling activation and enabling in one step. Remove the separate inv_icm42600_disable_pm callback, as it's no longer needed with the devm-managed approach.
Using devm_pm_runtime_enable() also fixes the missing disable of autosuspend.
Update inv_icm42600_disable_vddio_reg() to only disable the regulator if the device is not suspended i.e. powered-down, preventing unbalanced disables.
Also remove redundant error msg on regulator_disable(), the regulator framework already emits an error message when regulator_disable() fails.
This simplifies the PM setup and avoids manipulating the usage counter unnecessarily.
--- drivers/iio/imu/inv_icm42600/inv_icm42600_core.c | 24 ++++++----------------- 1 file changed, 7 insertions(+), 17 deletions(-)
drivers/iio/imu/inv_icm42600/inv_icm42600_core.c +7 -17
@@ -550,20 +550,12 @@ static void inv_icm42600_disable_vdd_regstatic void inv_icm42600_disable_vddio_reg (void *_data) {struct inv_icm42600_state *st = _data; -const struct device *dev =regmap_get_device (st->map); -int ret; - - ret =regulator_disable (st->vddio_supply); -if (ret) -dev_err (dev,"failed to disable vddio error %d\n" , ret); -} +struct device *dev =regmap_get_device (st->map); -static void inv_icm42600_disable_pm (void *_data) -{ -struct device *dev = _data; +if (pm_runtime_status_suspended (dev)) +return ; -pm_runtime_put_sync (dev); -pm_runtime_disable (dev); +regulator_disable (st->vddio_supply); } int inv_icm42600_core_probe(struct regmap *regmap, int chip, int irq,
@@ -660,16 +652,14 @@ int inv_icm42600_core_probe(struct regmareturn ret;/* setup runtime power management */ - ret =pm_runtime_set_active (dev); + ret =devm_pm_runtime_set_active_enabled (dev);if (ret)return ret; -pm_runtime_get_noresume (dev); -pm_runtime_enable (dev); +pm_runtime_set_autosuspend_delay (dev,INV_ICM42600_SUSPEND_DELAY_MS );pm_runtime_use_autosuspend (dev); -pm_runtime_put (dev); -return devm_add_action_or_reset (dev, inv_icm42600_disable_pm, dev); +return ret; }EXPORT_SYMBOL_GPL (inv_icm42600_core_probe);
Greg Kroah-Hartman
maintainerPATCH 312/332 NFSD: Rework encoding and decoding of nfsd4_deviceid
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Bashirov <[email protected]>
[ Upstream commit 832738e4b325b742940761e10487403f9aad13e8 ]
Compilers may optimize the layout of C structures, so we should not rely on sizeof struct and memcpy to encode and decode XDR structures. The byte order of the fields should also be taken into account.
This patch adds the correct functions to handle the deviceid4 structure and removes the pad field, which is currently not used by NFSD, from the runtime state. The server's byte order is preserved because the deviceid4 blob on the wire is only used as a cookie by the client.
Stable-dep-of: d68886bae76a ("NFSD: Fix last write offset handling in layoutcommit")
--- fs/nfsd/blocklayoutxdr.c | 7 ++----- fs/nfsd/flexfilelayoutxdr.c | 3 +-- fs/nfsd/nfs4layouts.c | 1 - fs/nfsd/nfs4xdr.c | 14 +------------- fs/nfsd/xdr4.h | 36 +++++++++++++++++++++++++++++++++++- 5 files changed, 39 insertions(+), 22 deletions(-)
fs/nfsd/blocklayoutxdr.c +2 -5
@@ -29,8 +29,7 @@ nfsd4_block_encode_layoutget(struct xdr_ *p++ =cpu_to_be32 (len); *p++ =cpu_to_be32 (1 );/* we always return a single extent */ - p =xdr_encode_opaque_fixed (p, &b->vol_id, -sizeof (struct nfsd4_deviceid )); + p =svcxdr_encode_deviceid4 (p, &b->vol_id); p =xdr_encode_hyper (p, b->foff); p =xdr_encode_hyper (p, b->len); p =xdr_encode_hyper (p, b->soff);
@@ -145,9 +144,7 @@ nfsd4_block_decode_layoutupdate(__be32 *for (i =0 ; i < nr_iomaps; i++) {struct pnfs_block_extent bex; -memcpy (&bex.vol_id, p,sizeof (struct nfsd4_deviceid )); - p +=XDR_QUADLEN (sizeof (struct nfsd4_deviceid )); - + p =svcxdr_decode_deviceid4 (p, &bex.vol_id); p =xdr_decode_hyper (p, &bex.foff);if (bex.foff & (block_size -1 )) { dprintk("%s: unaligned offset 0x%llx\n",
fs/nfsd/flexfilelayoutxdr.c +1 -2
@@ -54,8 +54,7 @@ nfsd4_ff_encode_layoutget(struct xdr_str *p++ =cpu_to_be32 (1 );/* single mirror */ *p++ =cpu_to_be32 (1 );/* single data server */ - p =xdr_encode_opaque_fixed (p, &fl->deviceid, -sizeof (struct nfsd4_deviceid )); + p =svcxdr_encode_deviceid4 (p, &fl->deviceid); *p++ =cpu_to_be32 (1 );/* efficiency */
fs/nfsd/nfs4layouts.c +0 -1
@@ -120,7 +120,6 @@ nfsd4_set_deviceid(struct nfsd4_deviceid id->fsid_idx = fhp->fh_export->ex_devid_map->idx; id->generation = device_generation; - id->pad =0 ;return 0 ; }
fs/nfsd/nfs4xdr.c +1 -13
@@ -566,18 +566,6 @@ nfsd4_decode_state_owner4(struct nfsd4_c }#ifdef CONFIG_NFSD_PNFS -static __be32 -nfsd4_decode_deviceid4 (struct nfsd4_compoundargs *argp, -struct nfsd4_deviceid *devid) -{ -__be32 *p; - - p =xdr_inline_decode (argp->xdr,NFS4_DEVICEID4_SIZE ); -if (!p) -return nfserr_bad_xdr; -memcpy (devid, p,sizeof (*devid)); -return nfs_ok; -} static __be32 nfsd4_decode_layoutupdate4(struct nfsd4_compoundargs *argp,
@@ -1733,7 +1721,7 @@ nfsd4_decode_getdeviceinfo(struct nfsd4___be32 status;memset (gdev,0 ,sizeof (*gdev)); - status =nfsd4_decode_deviceid4 (argp, &gdev->gd_devid); + status =nfsd4_decode_deviceid4 (argp->xdr, &gdev->gd_devid);if (status)return status;if (xdr_stream_decode_u32 (argp->xdr, &gdev->gd_layout_type) <0 )
fs/nfsd/xdr4.h +35 -1
@@ -459,9 +459,43 @@ struct nfsd4_reclaim_complete {struct nfsd4_deviceid {u64 fsid_idx;u32 generation; -u32 pad; }; +static inline __be32 * +svcxdr_encode_deviceid4 (__be32 *p,const struct nfsd4_deviceid *devid) +{ +__be64 *q = (__be64 *)p; + + *q = (__force __be64 )devid->fsid_idx; + p +=2 ; + *p++ = (__force __be32 )devid->generation; + *p++ = xdr_zero; +return p; +} + +static inline __be32 * +svcxdr_decode_deviceid4 (__be32 *p,struct nfsd4_deviceid *devid) +{ +__be64 *q = (__be64 *)p; + + devid->fsid_idx = (__force u64)(*q); + p +=2 ; + devid->generation = (__force u32)(*p++); + p++;/* NFSD does not use the remaining octets */ +return p; +} + +static inline __be32 +nfsd4_decode_deviceid4 (struct xdr_stream *xdr,struct nfsd4_deviceid *devid) +{ +__be32 *p =xdr_inline_decode (xdr,NFS4_DEVICEID4_SIZE ); + +if (unlikely (!p)) +return nfserr_bad_xdr; +svcxdr_decode_deviceid4 (p, devid); +return nfs_ok; +} +struct nfsd4_layout_seg {u32 iomode;u64 offset;
Greg Kroah-Hartman
maintainerPATCH 313/332 NFSD: Minor cleanup in layoutcommit processing
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Bashirov <[email protected]>
[ Upstream commit 274365a51d88658fb51cca637ba579034e90a799 ]
Remove dprintk in nfsd4_layoutcommit. These are not needed in day to day usage, and the information is also available in Wireshark when capturing NFS traffic.
Stable-dep-of: d68886bae76a ("NFSD: Fix last write offset handling in layoutcommit")
--- fs/nfsd/nfs4proc.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)
fs/nfsd/nfs4proc.c +3 -9
@@ -2278,18 +2278,12 @@ nfsd4_layoutcommit(struct svc_rqst *rqst inode =d_inode (current_fh->fh_dentry); nfserr = nfserr_inval; -if (new_size <= seg->offset) { -dprintk ("pnfsd: last write before layout segment\n" ); +if (new_size <= seg->offset) goto out; - } -if (new_size > seg->offset + seg->length) { -dprintk ("pnfsd: last write beyond layout segment\n" ); +if (new_size > seg->offset + seg->length) goto out; - } -if (!lcp->lc_newoffset && new_size >i_size_read (inode)) { -dprintk ("pnfsd: layoutcommit beyond EOF\n" ); +if (!lcp->lc_newoffset && new_size >i_size_read (inode)) goto out; - } nfserr = nfsd4_preprocess_layout_stateid(rqstp, cstate, &lcp->lc_sid, false, lcp->lc_layout_type,
Greg Kroah-Hartman
maintainerPATCH 314/332 NFSD: Fix last write offset handling in layoutcommit
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Bashirov <[email protected]>
[ Upstream commit d68886bae76a4b9b3484d23e5b7df086f940fa38 ]
The data type of loca_last_write_offset is newoffset4 and is switched on a boolean value, no_newoffset, that indicates if a previous write occurred or not. If no_newoffset is FALSE, an offset is not given. This means that client does not try to update the file size. Thus, server should not try to calculate new file size and check if it fits into the segment range. See RFC 8881, section 12.5.4.2.
Sometimes the current incorrect logic may cause clients to hang when trying to sync an inode. If layoutcommit fails, the client marks the inode as dirty again.
--- fs/nfsd/blocklayout.c | 5 ++--- fs/nfsd/nfs4proc.c | 30 +++++++++++++++--------------- 2 files changed, 17 insertions(+), 18 deletions(-)
fs/nfsd/blocklayout.c +2 -3
@@ -121,7 +121,6 @@ static __be32 nfsd4_block_commit_blocks(struct inode *inode, struct nfsd4_layoutcommit *lcp, struct iomap *iomaps, int nr_iomaps) { - loff_t new_size = lcp->lc_last_wr + 1; struct iattr iattr = { .ia_valid = 0 };int error;
@@ -131,9 +130,9 @@ nfsd4_block_commit_blocks(struct inode * iattr.ia_valid |=ATTR_ATIME |ATTR_CTIME |ATTR_MTIME ; iattr.ia_atime = iattr.ia_ctime = iattr.ia_mtime = lcp->lc_mtime; -if (new_size >i_size_read (inode)) { +if (lcp->lc_size_chg) { iattr.ia_valid |=ATTR_SIZE ; - iattr.ia_size = new_size; + iattr.ia_size = lcp->lc_newsize; } error = inode->i_sb->s_export_op->commit_blocks(inode, iomaps,
fs/nfsd/nfs4proc.c +15 -15
@@ -2262,7 +2262,6 @@ nfsd4_layoutcommit(struct svc_rqst *rqstconst struct nfsd4_layout_seg *seg = &lcp->lc_seg;struct svc_fh *current_fh = &cstate->current_fh;const struct nfsd4_layout_ops *ops; -loff_t new_size = lcp->lc_last_wr +1 ;struct inode *inode;struct nfs4_layout_stateid *ls;__be32 nfserr;
@@ -2277,13 +2276,21 @@ nfsd4_layoutcommit(struct svc_rqst *rqst goto out; inode =d_inode (current_fh->fh_dentry); - nfserr = nfserr_inval; -if (new_size <= seg->offset) - goto out; -if (new_size > seg->offset + seg->length) - goto out; -if (!lcp->lc_newoffset && new_size >i_size_read (inode)) - goto out; + lcp->lc_size_chg = false; +if (lcp->lc_newoffset) { +loff_t new_size = lcp->lc_last_wr +1 ; + + nfserr = nfserr_inval; +if (new_size <= seg->offset) + goto out; +if (new_size > seg->offset + seg->length) + goto out; + +if (new_size >i_size_read (inode)) { + lcp->lc_size_chg = true; + lcp->lc_newsize = new_size; + } + } nfserr = nfsd4_preprocess_layout_stateid(rqstp, cstate, &lcp->lc_sid, false, lcp->lc_layout_type,
@@ -2299,13 +2306,6 @@ nfsd4_layoutcommit(struct svc_rqst *rqst/* LAYOUTCOMMIT does not require any serialization */ mutex_unlock (&ls->ls_mutex); -if (new_size >i_size_read (inode)) { - lcp->lc_size_chg =1 ; - lcp->lc_newsize = new_size; - }else { - lcp->lc_size_chg =0 ; - } - nfserr = ops->proc_layoutcommit (inode, lcp);nfs4_put_stid (&ls->ls_stid); out:
Greg Kroah-Hartman
maintainerPATCH 315/332 KEYS: trusted_tpm1: Compare HMAC values in constant time
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
[ Upstream commit eed0e3d305530066b4fc5370107cff8ef1a0d229 ]
To prevent timing attacks, HMAC value comparison needs to be constant time. Replace the memcmp() with the correct function, crypto_memneq().
[For the Fixes commit I used the commit that introduced the memcmp(). It predates the introduction of crypto_memneq(), but it was still a bug at the time even though a helper function didn't exist yet.]
--- security/keys/trusted-keys/trusted_tpm1.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
security/keys/trusted-keys/trusted_tpm1.c +4 -3
@@ -9,6 +9,7 @@*/ #include <crypto/hash_info.h> +#include <crypto/algapi.h> #include <linux/uaccess.h> #include <linux/module.h> #include <linux/init.h>
@@ -248,7 +249,7 @@ int TSS_checkhmac1(unsigned char *bufferif (ret <0 ) goto out; -if (memcmp (testhmac, authdata,SHA1_DIGEST_SIZE )) +if (crypto_memneq (testhmac, authdata,SHA1_DIGEST_SIZE )) ret = -EINVAL ; out:kfree_sensitive (sdesc);
@@ -341,7 +342,7 @@ static int TSS_checkhmac2(unsigned char TPM_NONCE_SIZE, ononce, 1, continueflag1, 0, 0);if (ret <0 ) goto out; -if (memcmp (testhmac1, authdata1,SHA1_DIGEST_SIZE )) { +if (crypto_memneq (testhmac1, authdata1,SHA1_DIGEST_SIZE )) { ret = -EINVAL ; goto out; }
@@ -350,7 +351,7 @@ static int TSS_checkhmac2(unsigned char TPM_NONCE_SIZE, ononce, 1, continueflag2, 0, 0);if (ret <0 ) goto out; -if (memcmp (testhmac2, authdata2,SHA1_DIGEST_SIZE )) +if (crypto_memneq (testhmac2, authdata2,SHA1_DIGEST_SIZE )) ret = -EINVAL ; out:kfree_sensitive (sdesc);
Greg Kroah-Hartman
maintainerPATCH 316/332 crypto: rockchip - Fix dma_unmap_sg() nents value
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Fourier <[email protected]>
[ Upstream commit 21140e5caf019e4a24e1ceabcaaa16bd693b393f ]
The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned.
--- drivers/crypto/rockchip/rk3288_crypto_ahash.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/crypto/rockchip/rk3288_crypto_ahash.c +1 -2
@@ -236,10 +236,9 @@ static int rk_hash_unprepare(struct cryp { struct ahash_request *areq = container_of(breq, struct ahash_request, base);struct crypto_ahash *tfm =crypto_ahash_reqtfm (areq); -struct rk_ahash_rctx *rctx =ahash_request_ctx (areq);struct rk_ahash_ctx *tctx =crypto_ahash_ctx (tfm); -dma_unmap_sg (tctx->dev->dev, areq->src, rctx->nrsg,DMA_TO_DEVICE ); +dma_unmap_sg (tctx->dev->dev, areq->src,sg_nents (areq->src),DMA_TO_DEVICE );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 317/332 PCI: tegra194: Handle errors in BPMP response
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vidya Sagar <[email protected]>
[ Upstream commit f8c9ad46b00453a8c075453f3745f8d263f44834 ]
The return value from tegra_bpmp_transfer() indicates the success or failure of the IPC transaction with BPMP. If the transaction succeeded, we also need to check the actual command's result code.
If we don't have error handling for tegra_bpmp_transfer(), we will set the pcie->ep_state to EP_STATE_ENABLED even when the tegra_bpmp_transfer() command fails. Thus, the pcie->ep_state will get out of sync with reality, and any further PERST# assert + deassert will be a no-op and will not trigger the hardware initialization sequence.
This is because pex_ep_event_pex_rst_deassert() checks the current pcie->ep_state, and does nothing if the current state is already EP_STATE_ENABLED.
Thus, it is important to have error handling for tegra_bpmp_transfer(), such that the pcie->ep_state can not get out of sync with reality, so that we will try to initialize the hardware not only during the first PERST# assert + deassert, but also during any succeeding PERST# assert + deassert.
One example where this fix is needed is when using a rock5b as host. During the initial PERST# assert + deassert (triggered by the bootloader on the rock5b) pex_ep_event_pex_rst_deassert() will get called, but for some unknown reason, the tegra_bpmp_transfer() call to initialize the PHY fails. Once Linux has been loaded on the rock5b, the PCIe driver will once again assert + deassert PERST#. However, without tegra_bpmp_transfer() error handling, this second PERST# assert + deassert will not trigger the hardware initialization sequence.
With tegra_bpmp_transfer() error handling, the second PERST# assert + deassert will once again trigger the hardware to be initialized and this time the tegra_bpmp_transfer() succeeds.
--- drivers/pci/controller/dwc/pcie-tegra194.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)
drivers/pci/controller/dwc/pcie-tegra194.c +16 -2
@@ -1160,6 +1160,7 @@ static int tegra_pcie_bpmp_set_ctrl_statstruct mrq_uphy_response resp;struct tegra_bpmp_message msg;struct mrq_uphy_request req; +int err;/* Controller-5 doesn't need to have its state set by BPMP-FW */ if (pcie->cid ==5 )
@@ -1179,7 +1180,13 @@ static int tegra_pcie_bpmp_set_ctrl_stat msg.rx.data = &resp; msg.rx.size =sizeof (resp); -return tegra_bpmp_transfer (pcie->bpmp, &msg); + err =tegra_bpmp_transfer (pcie->bpmp, &msg); +if (err) +return err; +if (msg.rx.ret) +return -EINVAL ; + +return 0 ; } static int tegra_pcie_bpmp_set_pll_state(struct tegra_pcie_dw *pcie,
@@ -1188,6 +1195,7 @@ static int tegra_pcie_bpmp_set_pll_statestruct mrq_uphy_response resp;struct tegra_bpmp_message msg;struct mrq_uphy_request req; +int err;memset (&req,0 ,sizeof (req));memset (&resp,0 ,sizeof (resp));
@@ -1207,7 +1215,13 @@ static int tegra_pcie_bpmp_set_pll_state msg.rx.data = &resp; msg.rx.size =sizeof (resp); -return tegra_bpmp_transfer (pcie->bpmp, &msg); + err =tegra_bpmp_transfer (pcie->bpmp, &msg); +if (err) +return err; +if (msg.rx.ret) +return -EINVAL ; + +return 0 ; }static void tegra_pcie_downstream_dev_to_D0 (struct tegra_pcie_dw *pcie)
Greg Kroah-Hartman
maintainerPATCH 318/332 wifi: ath11k: HAL SRNG: dont deinitialize and re-initialize again
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Muhammad Usama Anjum <[email protected]>
[ Upstream commit 32be3ca4cf78b309dfe7ba52fe2d7cc3c23c5634 ]
Don't deinitialize and reinitialize the HAL helpers. The dma memory is deallocated and there is high possibility that we'll not be able to get the same memory allocated from dma when there is high memory pressure.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.6
--- drivers/net/wireless/ath/ath11k/core.c | 6 +----- drivers/net/wireless/ath/ath11k/hal.c | 16 ++++++++++++++++ drivers/net/wireless/ath/ath11k/hal.h | 1 + 3 files changed, 18 insertions(+), 5 deletions(-)
drivers/net/wireless/ath/ath11k/core.c +1 -5
@@ -710,14 +710,10 @@ static int ath11k_core_reconfigure_on_crmutex_unlock (&ab->core_lock);ath11k_dp_free (ab); -ath11k_hal_srng_deinit (ab); +ath11k_hal_srng_clear (ab); ab->free_vdev_map = (1LL << (ab->num_radios *TARGET_NUM_VDEVS )) -1 ; - ret =ath11k_hal_srng_init (ab); -if (ret) -return ret; -clear_bit (ATH11K_FLAG_CRASH_FLUSH , &ab->dev_flags); ret =ath11k_core_qmi_firmware_ready (ab);
drivers/net/wireless/ath/ath11k/hal.c +16 -0
@@ -1317,6 +1317,22 @@ void ath11k_hal_srng_deinit(struct ath11 }EXPORT_SYMBOL (ath11k_hal_srng_deinit); +void ath11k_hal_srng_clear (struct ath11k_base *ab) +{ +/* No need to memset rdp and wrp memory since each individual +* segment would get cleared in ath11k_hal_srng_src_hw_init() +* and ath11k_hal_srng_dst_hw_init(). +*/ +memset (ab->hal.srng_list,0 , +sizeof (ab->hal.srng_list)); +memset (ab->hal.shadow_reg_addr,0 , +sizeof (ab->hal.shadow_reg_addr)); + ab->hal.avail_blk_resource =0 ; + ab->hal.current_blk_index =0 ; + ab->hal.num_shadow_reg_configured =0 ; +} +EXPORT_SYMBOL (ath11k_hal_srng_clear); +void ath11k_hal_dump_srng_stats (struct ath11k_base *ab) {struct hal_srng *srng;
drivers/net/wireless/ath/ath11k/hal.h +1 -0
@@ -940,6 +940,7 @@ int ath11k_hal_srng_setup(struct ath11k_ struct hal_srng_params *params);int ath11k_hal_srng_init (struct ath11k_base *ath11k);void ath11k_hal_srng_deinit (struct ath11k_base *ath11k); +void ath11k_hal_srng_clear (struct ath11k_base *ab);void ath11k_hal_dump_srng_stats (struct ath11k_base *ab);void ath11k_hal_srng_get_shadow_config (struct ath11k_base *ab,u32 **cfg,u32 *len);
Greg Kroah-Hartman
maintainerPATCH 319/332 PCI: j721e: Fix programming sequence of "strap" settings
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Siddharth Vadapalli <[email protected]>
[ Upstream commit f842d3313ba179d4005096357289c7ad09cec575 ]
The Cadence PCIe Controller integrated in the TI K3 SoCs supports both Root-Complex and Endpoint modes of operation. The Glue Layer allows "strapping" the Mode of operation of the Controller, the Link Speed and the Link Width. This is enabled by programming the "PCIEn_CTRL" register (n corresponds to the PCIe instance) within the CTRL_MMR memory-mapped register space. The "reset-values" of the registers are also different depending on the mode of operation.
Since the PCIe Controller latches onto the "reset-values" immediately after being powered on, if the Glue Layer configuration is not done while the PCIe Controller is off, it will result in the PCIe Controller latching onto the wrong "reset-values". In practice, this will show up as a wrong representation of the PCIe Controller's capability structures in the PCIe Configuration Space. Some such capabilities which are supported by the PCIe Controller in the Root-Complex mode but are incorrectly latched onto as being unsupported are:
- Link Bandwidth Notification
- Alternate Routing ID (ARI) Forwarding Support
- Next capability offset within Advanced Error Reporting (AER) capability
Fix this by powering off the PCIe Controller before programming the "strap" settings and powering it on after that. The runtime PM APIs namely pm_runtime_put_sync() and pm_runtime_get_sync() will decrement and increment the usage counter respectively, causing GENPD to power off and power on the PCIe Controller.
--- drivers/pci/controller/cadence/pci-j721e.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
drivers/pci/controller/cadence/pci-j721e.c +25 -0
@@ -227,6 +227,25 @@ static int j721e_pcie_ctrl_init(struct jreturn PTR_ERR (syscon); } +/* +* The PCIe Controller's registers have different "reset-values" +* depending on the "strap" settings programmed into the PCIEn_CTRL +* register within the CTRL_MMR memory-mapped register space. +* The registers latch onto a "reset-value" based on the "strap" +* settings sampled after the PCIe Controller is powered on. +* To ensure that the "reset-values" are sampled accurately, power +* off the PCIe Controller before programming the "strap" settings +* and power it on after that. The runtime PM APIs namely +* pm_runtime_put_sync() and pm_runtime_get_sync() will decrement and +* increment the usage counter respectively, causing GENPD to power off +* and power on the PCIe Controller. +*/ + ret =pm_runtime_put_sync (dev); +if (ret <0 ) { +dev_err (dev,"Failed to power off PCIe Controller\n" ); +return ret; + } + ret =j721e_pcie_set_mode (pcie, syscon);if (ret <0 ) {dev_err (dev,"Failed to set pci mode\n" );
@@ -245,6 +264,12 @@ static int j721e_pcie_ctrl_init(struct jreturn ret; } + ret =pm_runtime_get_sync (dev); +if (ret <0 ) { +dev_err (dev,"Failed to power on PCIe Controller\n" ); +return ret; + } +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 320/332 PCI: Add sysfs attribute for device power state
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maximilian Luz <[email protected]>
[ Upstream commit 80a129afb75cba8434fc5071bd6919172442315c ]
While PCI power states D0-D3hot can be queried from user-space via lspci, D3cold cannot. lspci cannot provide an accurate value when the device is in D3cold as it has to restore the device to D0 before it can access its power state via the configuration space, leading to it reporting D0 or another on-state. Thus lspci cannot be used to diagnose power consumption issues for devices that can enter D3cold or to ensure that devices properly enter D3cold at all.
Add a new sysfs device attribute for the PCI power state, showing the current power state as seen by the kernel.
Stable-dep-of: 48991e493507 ("PCI/sysfs: Ensure devices are powered for config reads")
--- Documentation/ABI/testing/sysfs-bus-pci | 9 +++++++++ drivers/pci/pci-sysfs.c | 10 ++++++++++ 2 files changed, 19 insertions(+)
Documentation/ABI/testing/sysfs-bus-pci +9 -0
@@ -377,3 +377,12 @@ Contact: Heiner Kallweit <hkallweit1@gma Description: If ASPM is supported for an endpoint, these files can be used to disable or enable the individual power management states. Write y/1/on to enable, n/0/off to disable. + +What: /sys/bus/pci/devices/.../power_state +Date: November 2020 +Contact: Linux PCI developers <[email protected]> +Description: + This file contains the current PCI power state of the device. + The value comes from the PCI kernel device state and can be one + of: "unknown", "error", "D0", D1", "D2", "D3hot", "D3cold". + The file is read only.
drivers/pci/pci-sysfs.c +10 -0
@@ -124,6 +124,15 @@ static ssize_t cpulistaffinity_show(stru }static DEVICE_ATTR_RO (cpulistaffinity); +static ssize_t power_state_show (struct device *dev, +struct device_attribute *attr,char *buf) +{ +struct pci_dev *pdev =to_pci_dev (dev); + +return sprintf (buf,"%s\n" ,pci_power_name (pdev->current_state)); +} +static DEVICE_ATTR_RO (power_state); +/* show resources */ static ssize_t resource_show (struct device *dev,struct device_attribute *attr,char *buf)
@@ -603,6 +612,7 @@ static ssize_t driver_override_show(strustatic DEVICE_ATTR_RW (driver_override);static struct attribute *pci_dev_attrs[] = { + &dev_attr_power_state.attr, &dev_attr_resource.attr, &dev_attr_vendor.attr, &dev_attr_device.attr,
Greg Kroah-Hartman
maintainerPATCH 321/332 PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Wilczyński <[email protected]>
[ Upstream commit ad025f8e46f3dbf09b1bf8d7a5b4ce858df74544 ]
The sysfs_emit() and sysfs_emit_at() functions were introduced to make it less ambiguous which function is preferred when writing to the output buffer in a device attribute's "show" callback [1].
Convert the PCI sysfs object "show" functions from sprintf(), snprintf() and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the latter is aware of the PAGE_SIZE buffer and correctly returns the number of bytes written into the buffer.
No functional change intended.
[1] Documentation/filesystems/sysfs.rst
Stable-dep-of: 48991e493507 ("PCI/sysfs: Ensure devices are powered for config reads")
--- drivers/pci/pci-label.c | 10 ++---- drivers/pci/pci-sysfs.c | 72 ++++++++++++++++++++++++------------------------ 2 files changed, 40 insertions(+), 42 deletions(-)
drivers/pci/pci-label.c +4 -6
@@ -62,13 +62,11 @@ static size_t find_smbios_instance_strin donboard->devfn == devfn) {if (buf) {if (attribute ==SMBIOS_ATTR_INSTANCE_SHOW ) -return scnprintf (buf,PAGE_SIZE , -"%d\n" , - donboard->instance); +return sysfs_emit (buf,"%d\n" , + donboard->instance);else if (attribute ==SMBIOS_ATTR_LABEL_SHOW ) -return scnprintf (buf,PAGE_SIZE , -"%s\n" , - dmi->name); +return sysfs_emit (buf,"%s\n" , + dmi->name); }return strlen (dmi->name); }
drivers/pci/pci-sysfs.c +36 -36
209 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 322/332 PCI/sysfs: Ensure devices are powered for config reads
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
[ Upstream commit 48991e4935078b05f80616c75d1ee2ea3ae18e58 ]
The "max_link_width", "current_link_speed", "current_link_width", "secondary_bus_number", and "subordinate_bus_number" sysfs files all access config registers, but they don't check the runtime PM state. If the device is in D3cold or a parent bridge is suspended, we may see -EINVAL, bogus values, or worse, depending on implementation details.
Wrap these access in pci_config_pm_runtime_{get,put}() like most of the rest of the similar sysfs attributes.
Notably, "max_link_speed" does not access config registers; it returns a cached value since d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds").
--- drivers/pci/pci-sysfs.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
drivers/pci/pci-sysfs.c +19 -1
@@ -174,8 +174,14 @@ static ssize_t max_link_width_show(struc struct device_attribute *attr, char *buf) { struct pci_dev *pdev = to_pci_dev(dev); +ssize_t ret; -return sysfs_emit (buf,"%u\n" ,pcie_get_width_cap (pdev)); +/* We read PCI_EXP_LNKCAP, so we need the device to be accessible. */ +pci_config_pm_runtime_get (pdev); + ret =sysfs_emit (buf,"%u\n" ,pcie_get_width_cap (pdev)); +pci_config_pm_runtime_put (pdev); + +return ret; }static DEVICE_ATTR_RO (max_link_width);
@@ -187,7 +193,10 @@ static ssize_t current_link_speed_show(sint err;enum pci_bus_speed speed; +pci_config_pm_runtime_get (pci_dev); err =pcie_capability_read_word (pci_dev,PCI_EXP_LNKSTA , &linkstat); +pci_config_pm_runtime_put (pci_dev); +if (err)return -EINVAL ;
@@ -204,7 +213,10 @@ static ssize_t current_link_width_show(su16 linkstat;int err; +pci_config_pm_runtime_get (pci_dev); err =pcie_capability_read_word (pci_dev,PCI_EXP_LNKSTA , &linkstat); +pci_config_pm_runtime_put (pci_dev); +if (err)return -EINVAL ;
@@ -221,7 +233,10 @@ static ssize_t secondary_bus_number_showu8 sec_bus;int err; +pci_config_pm_runtime_get (pci_dev); err =pci_read_config_byte (pci_dev,PCI_SECONDARY_BUS , &sec_bus); +pci_config_pm_runtime_put (pci_dev); +if (err)return -EINVAL ;
@@ -237,7 +252,10 @@ static ssize_t subordinate_bus_number_shu8 sub_bus;int err; +pci_config_pm_runtime_get (pci_dev); err =pci_read_config_byte (pci_dev,PCI_SUBORDINATE_BUS , &sub_bus); +pci_config_pm_runtime_put (pci_dev); +if (err)return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 323/332 ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
[ Upstream commit 8ecb790ea8c3fc69e77bace57f14cf0d7c177bd8 ]
Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.
Message-ID: <[email protected]>
--- fs/ext4/super.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
fs/ext4/super.c +4 -6
@@ -4282,18 +4282,16 @@ static int ext4_fill_super(struct super_ }if (sbi->s_es->s_mount_opts[0 ]) { -char *s_mount_opts =kstrndup (sbi->s_es->s_mount_opts, -sizeof (sbi->s_es->s_mount_opts), -GFP_KERNEL ); -if (!s_mount_opts) - goto failed_mount; +char s_mount_opts[65 ]; + +strscpy_pad (s_mount_opts, sbi->s_es->s_mount_opts, +sizeof (s_mount_opts));if (!parse_options (s_mount_opts, sb, &journal_devnum, &journal_ioprio,0 )) {ext4_msg (sb,KERN_WARNING ,"failed to parse options in superblock: %s" , s_mount_opts); } -kfree (s_mount_opts); } sbi->s_def_mount_opt = sbi->s_mount_opt; if (!parse_options((char *) data, sb, &journal_devnum,
Greg Kroah-Hartman
maintainerPATCH 324/332 spi: cadence-quadspi: Flush posted register writes before DAC access
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pratyush Yadav <[email protected]>
[ Upstream commit 1ad55767e77a853c98752ed1e33b68049a243bd7 ]
cqspi_read_setup() and cqspi_write_setup() program the address width as the last step in the setup. This is likely to be immediately followed by a DAC region read/write. On TI K3 SoCs the DAC region is on a different endpoint from the register region. This means that the order of the two operations is not guaranteed, and they might be reordered at the interconnect level. It is possible that the DAC read/write goes through before the address width update goes through. In this situation if the previous command used a different address width the OSPI command is sent with the wrong number of address bytes, resulting in an invalid command and undefined behavior.
Read back the size register to make sure the write gets flushed before accessing the DAC region.
Message-ID: <[email protected]>
--- drivers/spi/spi-cadence-quadspi.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/spi/spi-cadence-quadspi.c +2 -0
@@ -474,6 +474,7 @@ static int cqspi_read_setup(struct cqspi reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK ; reg |= (op->addr.nbytes -1 );writel (reg, reg_base +CQSPI_REG_SIZE ); +readl (reg_base +CQSPI_REG_SIZE );/* Flush posted write. */ return 0 ; }
@@ -587,6 +588,7 @@ static int cqspi_write_setup(struct cqsp reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK ; reg |= (op->addr.nbytes -1 );writel (reg, reg_base +CQSPI_REG_SIZE ); +readl (reg_base +CQSPI_REG_SIZE );/* Flush posted write. */ return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 325/332 drm/amdgpu: use atomic functions with memory barriers for vm fault info
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gui-Dong Han <[email protected]>
[ Upstream commit 6df8e84aa6b5b1812cc2cacd6b3f5ccbb18cda2b ]
The atomic variable vm_fault_info_updated is used to synchronize access to adev->gmc.vm_fault_info between the interrupt handler and get_vm_fault_info().
The default atomic functions like atomic_set() and atomic_read() do not provide memory barriers. This allows for CPU instruction reordering, meaning the memory accesses to vm_fault_info and the vm_fault_info_updated flag are not guaranteed to occur in the intended order. This creates a race condition that can lead to inconsistent or stale data being used.
The previous implementation, which used an explicit mb(), was incomplete and inefficient. It failed to account for all potential CPU reorderings, such as the access of vm_fault_info being reordered before the atomic_read of the flag. This approach is also more verbose and less performant than using the proper atomic functions with acquire/release semantics.
Fix this by switching to atomic_set_release() and atomic_read_acquire(). These functions provide the necessary acquire and release semantics, which act as memory barriers to ensure the correct order of operations. It is also more efficient and idiomatic than using explicit full memory barriers.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 ++--- drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 7 +++---- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 7 +++---- 3 files changed, 8 insertions(+), 11 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +2 -3
@@ -1640,10 +1640,9 @@ int amdgpu_amdkfd_gpuvm_get_vm_fault_infstruct amdgpu_device *adev; adev = (struct amdgpu_device *)kgd; -if (atomic_read (&adev->gmc.vm_fault_info_updated) ==1 ) { +if (atomic_read_acquire (&adev->gmc.vm_fault_info_updated) ==1 ) { *mem = *adev->gmc.vm_fault_info; -mb (); -atomic_set (&adev->gmc.vm_fault_info_updated,0 ); +atomic_set_release (&adev->gmc.vm_fault_info_updated,0 ); }return 0 ; }
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c +3 -4
@@ -1067,7 +1067,7 @@ static int gmc_v7_0_sw_init(void *handle GFP_KERNEL);if (!adev->gmc.vm_fault_info)return -ENOMEM ; -atomic_set (&adev->gmc.vm_fault_info_updated,0 ); +atomic_set_release (&adev->gmc.vm_fault_info_updated,0 );return 0 ; }
@@ -1297,7 +1297,7 @@ static int gmc_v7_0_process_interrupt(st vmid =REG_GET_FIELD (status,VM_CONTEXT1_PROTECTION_FAULT_STATUS ,VMID );if (amdgpu_amdkfd_is_kfd_vmid (adev, vmid) - && !atomic_read (&adev->gmc.vm_fault_info_updated)) { + && !atomic_read_acquire (&adev->gmc.vm_fault_info_updated)) {struct kfd_vm_fault_info *info = adev->gmc.vm_fault_info; u32 protections = REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS,
@@ -1313,8 +1313,7 @@ static int gmc_v7_0_process_interrupt(st info->prot_read = protections &0x8 ? true : false; info->prot_write = protections &0x10 ? true : false; info->prot_exec = protections &0x20 ? true : false; -mb (); -atomic_set (&adev->gmc.vm_fault_info_updated,1 ); +atomic_set_release (&adev->gmc.vm_fault_info_updated,1 ); }return 0 ;
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c +3 -4
@@ -1199,7 +1199,7 @@ static int gmc_v8_0_sw_init(void *handle GFP_KERNEL);if (!adev->gmc.vm_fault_info)return -ENOMEM ; -atomic_set (&adev->gmc.vm_fault_info_updated,0 ); +atomic_set_release (&adev->gmc.vm_fault_info_updated,0 );return 0 ; }
@@ -1488,7 +1488,7 @@ static int gmc_v8_0_process_interrupt(st vmid =REG_GET_FIELD (status,VM_CONTEXT1_PROTECTION_FAULT_STATUS ,VMID );if (amdgpu_amdkfd_is_kfd_vmid (adev, vmid) - && !atomic_read (&adev->gmc.vm_fault_info_updated)) { + && !atomic_read_acquire (&adev->gmc.vm_fault_info_updated)) {struct kfd_vm_fault_info *info = adev->gmc.vm_fault_info; u32 protections = REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS,
@@ -1504,8 +1504,7 @@ static int gmc_v8_0_process_interrupt(st info->prot_read = protections &0x8 ? true : false; info->prot_write = protections &0x10 ? true : false; info->prot_exec = protections &0x20 ? true : false; -mb (); -atomic_set (&adev->gmc.vm_fault_info_updated,1 ); +atomic_set_release (&adev->gmc.vm_fault_info_updated,1 ); }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 326/332 vfs: Dont leak disconnected dentries on umount
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
[ Upstream commit 56094ad3eaa21e6621396cc33811d8f72847a834 ]
When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.
--- fs/dcache.c | 2 ++ 1 file changed, 2 insertions(+)
fs/dcache.c +2 -0
@@ -1801,6 +1801,8 @@ struct dentry *d_alloc(struct dentry * p__dget_dlock (parent); dentry->d_parent = parent;list_add (&dentry->d_child, &parent->d_subdirs); +if (parent->d_flags &DCACHE_DISCONNECTED ) + dentry->d_flags |=DCACHE_DISCONNECTED ;spin_unlock (&parent->d_lock);return dentry;
Greg Kroah-Hartman
maintainerPATCH 327/332 NFSD: Define a proc_layoutcommit for the FlexFiles layout type
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever <[email protected]>
[ Upstream commit 4b47a8601b71ad98833b447d465592d847b4dc77 ]
Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.
--- fs/nfsd/flexfilelayout.c | 8 ++++++++ 1 file changed, 8 insertions(+)
fs/nfsd/flexfilelayout.c +8 -0
@@ -125,6 +125,13 @@ nfsd4_ff_proc_getdeviceinfo(struct superreturn 0 ; } +static __be32 +nfsd4_ff_proc_layoutcommit (struct inode *inode, +struct nfsd4_layoutcommit *lcp) +{ +return nfs_ok; +} +const struct nfsd4_layout_ops ff_layout_ops = { .notify_types =NOTIFY_DEVICEID4_DELETE |NOTIFY_DEVICEID4_CHANGE ,
@@ -133,4 +140,5 @@ const struct nfsd4_layout_ops ff_layout_ .encode_getdeviceinfo = nfsd4_ff_encode_getdeviceinfo, .proc_layoutget = nfsd4_ff_proc_layoutget, .encode_layoutget = nfsd4_ff_encode_layoutget, + .proc_layoutcommit = nfsd4_ff_proc_layoutcommit, };
Greg Kroah-Hartman
maintainerPATCH 328/332 fuse: fix livelock in synchronous file put from fuseblk workers
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Darrick J. Wong" <[email protected]>
[ Upstream commit 26e5c67deb2e1f42a951f022fdf5b9f7eb747b01 ]
I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server:
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
But the /weird/ part is that the fuseblk server threads are waiting for responses from itself:
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that:
"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion).
Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously.
Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands.
Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.
--- fs/fuse/file.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
fs/fuse/file.c +7 -1
@@ -324,8 +324,14 @@ void fuse_release_common(struct file *fi* Make the release synchronous if this is a fuseblk mount, * synchronous RELEASE is allowed (and desirable) in this case * because the server can be trusted not to screw up. +* +* Always use the asynchronous file put because the current thread +* might be the fuse server. This can happen if a process starts some +* aio and closes the fd before the aio completes. Since aio takes its +* own ref to the file, the IO completion has to drop the ref, which is +* how the fuse server can end up closing its clients' files. */ -fuse_file_put (ff, ff->fm->fc->destroy, isdir); +fuse_file_put (ff, false, isdir); }static int fuse_open (struct inode *inode,struct file *file)
Greg Kroah-Hartman
maintainerPATCH 329/332 arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kaushlendra Kumar <[email protected]>
[ Upstream commit 2eead19334516c8e9927c11b448fbe512b1f18a1 ]
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:
"The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().
--- drivers/base/arch_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/arch_topology.c +1 -1
@@ -196,7 +196,7 @@ bool __init topology_parse_cpu_capacity(* frequency (by keeping the initial freq_factor value). */ cpu_clk =of_clk_get (cpu_node,0 ); -if (!PTR_ERR_OR_ZERO (cpu_clk)) { +if (!IS_ERR_OR_NULL (cpu_clk)) {per_cpu (freq_factor, cpu) =clk_get_rate (cpu_clk) /1000 ;clk_put (cpu_clk);
Greg Kroah-Hartman
maintainerPATCH 330/332 net: rtnetlink: fix module reference count leak issue in rtnetlink_rcv_msg
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhengchao Shao <[email protected]>
commit 5b22f62724a0a09e00d301abf5b57b0c12be8a16 upstream.
When bulk delete command is received in the rtnetlink_rcv_msg function, if bulk delete is not supported, module_put is not called to release the reference counting. As a result, module reference count is leaked.
--- net/core/rtnetlink.c | 1 + 1 file changed, 1 insertion(+)
net/core/rtnetlink.c +1 -0
@@ -5624,6 +5624,7 @@ static int rtnetlink_rcv_msg(struct sk_bif (kind ==RTNL_KIND_DEL && (nlh->nlmsg_flags &NLM_F_BULK ) && !(flags &RTNL_FLAG_BULK_DEL_SUPPORTED )) {NL_SET_ERR_MSG (extack,"Bulk delete is not supported" ); +module_put (owner); goto err_unlock; }
Greg Kroah-Hartman
maintainerPATCH 331/332 RISC-V: Dont fail in riscv_of_parent_hartid() for disabled HARTs
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anup Patel <[email protected]>
commit c4676f8dc1e12e68d6511f9ed89707fdad4c962c upstream.
The riscv_of_processor_hartid() used by riscv_of_parent_hartid() fails for HARTs disabled in the DT. This results in the following warning thrown by the RISC-V INTC driver for the E-core on SiFive boards:
[ 0.000000] riscv-intc: unable to find hart id for /cpus/cpu@0/interrupt-controller
The riscv_of_parent_hartid() is only expected to read the hartid from the DT so we directly call of_get_cpu_hwid() instead of calling riscv_of_processor_hartid().
--- arch/riscv/kernel/cpu.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
arch/riscv/kernel/cpu.c +6 -5
@@ -50,13 +50,14 @@ int riscv_of_processor_hartid(struct dev*/ int riscv_of_parent_hartid (struct device_node *node,unsigned long *hartid) { -int rc; -for (; node; node = node->parent) {if (of_device_is_compatible (node,"riscv" )) { - rc =riscv_of_processor_hartid (node, hartid); -if (!rc) -return 0 ; + *hartid = (unsigned long )of_get_cpu_hwid (node,0 ); +if (*hartid == ~0UL ) { +pr_warn ("Found CPU without hart ID\n" ); +return -ENODEV ; + } +return 0 ; } }
Greg Kroah-Hartman
maintainerPATCH 332/332 fsdax: Fix infinite loop in dax_iomap_rw()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Jinlin <[email protected]>
commit 17d9c15c9b9e7fb285f7ac5367dfb5f00ff575e3 upstream.
I got an infinite loop and a WARNING report when executing a tail command in virtiofs.
WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0 Modules linked in: CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7 Call Trace: <TASK> dax_iomap_rw+0xea/0x620 ? __this_cpu_preempt_check+0x13/0x20 fuse_dax_read_iter+0x47/0x80 fuse_file_read_iter+0xae/0xd0 new_sync_read+0xfe/0x180 ? 0xffffffff81000000 vfs_read+0x14d/0x1a0 ksys_read+0x6d/0xf0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The tail command will call read() with a count of 0. In this case, iomap_iter() will report this WARNING, and always return 1 which casuing the infinite loop in dax_iomap_rw().
Fixing by checking count whether is 0 in dax_iomap_rw().
--- fs/dax.c | 3 +++ 1 file changed, 3 insertions(+)
fs/dax.c +3 -0
@@ -1219,6 +1219,9 @@ dax_iomap_rw(struct kiocb *iocb, structloff_t done =0 ;int ret; +if (!iomi.len) +return 0 ; +if (iov_iter_rw (iter) ==WRITE ) {lockdep_assert_held_write (&iomi.inode->i_rwsem); iomi.flags |=IOMAP_WRITE ;
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.246 release. There are 332 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 Wed, 29 Oct 2025 18:34:15 +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.246-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
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.246 release. There are 332 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 Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
5.10.246-rc1 built and run on x86_64 test system with no errors or regressions:
Slade
Greg Kroah-Hartman wrote on Mon, Oct 27, 2025 at 07:30:53PM +0100:
Quoted 5 lines
This is the start of the stable review cycle for the 5.10.246 release. There are 332 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 Wed, 29 Oct 2025 18:34:15 +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.246-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.
Tested 65dbbe3ff059 ("Linux 5.10.246-rc1") on:
- arm i.MX6ULL (Armadillo 640)
- arm64 i.MX8MP (Armadillo G4)
No obvious regression in dmesg or basic tests:
Signature · 1 line
Dominique Martinet
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.10.246 release. There are 332 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.
I'm seeing failures on risc-v:
arch/riscv/kernel/cpu.c: In function 'riscv_of_processor_hartid':
2246arch/riscv/kernel/cpu.c:24:26: error: implicit declaration of function 'of_get_cpu_hwid'; did you mean 'of_get_cpu_node'? [-Werror=implicit-function-declaration] 2247
24 | *hart = (unsigned long) of_get_cpu_hwid(node, 0);
2248
| ^~~~~~~~~~~~~~~
2249
| of_get_cpu_node
2250arch/riscv/kernel/cpufeature.c: In function 'riscv_fill_hwcap':
2251arch/riscv/kernel/cpufeature.c:107:16: warning: unused variable 'ext_end' [-Wunused-variable] 2252
107 | const char *ext_end = isa;
2253
| ^~~~~~~
2254
cc1: some warnings being treated as errors
2255
make[2]: *** [scripts/Makefile.build:286: arch/riscv/kernel/cpu.o] Error 1 2256
make[2]: *** Waiting for unfinished jobs....
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/11870647387
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/2123716079
Best regards,
Pavel
Signature · 2 lines
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.246 release. There are 332 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 Wed, 29 Oct 2025 18:34:15 +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.246-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
67 tests: 67 pass, 0 failLinux version: 5.10.246-rc1-g65dbbe3ff059
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