5.15.24-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 166/172 Makefile.extrawarn: Move -Wunaligned-access to W=1
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
commit 1cf5f151d25fcca94689efd91afa0253621fb33a upstream.
-Wunaligned-access is a new warning in clang that is default enabled for arm and arm64 under certain circumstances within the clang frontend (see LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows 1284 total/70 unique instances of this warning (most of the instances are in header files), which is quite noisy.
To keep a normal build green through CONFIG_WERROR, only show this warning with W=1, which will allow automated build systems to catch new instances of the warning so that the total number can be driven down to zero eventually since catching unaligned accesses at compile time would be generally useful.
--- scripts/Makefile.extrawarn | 1 + 1 file changed, 1 insertion(+)
scripts/Makefile.extrawarn +1 -0
@@ -51,6 +51,7 @@ KBUILD_CFLAGS += -Wno-sign-compare KBUILD_CFLAGS += -Wno-format-zero-length KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast) KBUILD_CFLAGS += -Wno-tautological-constant-out-of-range-compare +KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access) endif endif
Greg Kroah-Hartman
maintainerPATCH 167/172 scsi: lpfc: Remove NVMe support if kernel has NVME_FC disabled
In reply to Greg Kroah-HartmanFrom: James Smart <[email protected]>
commit c80b27cfd93ba9f5161383f798414609e84729f3 upstream.
The driver is initiating NVMe PRLIs to determine device NVMe support. This should not be occurring if CONFIG_NVME_FC support is disabled.
Correct this by changing the default value for FC4 support. Currently it defaults to FCP and NVMe. With change, when NVME_FC support is not enabled in the kernel, the default value is just FCP.
--- drivers/scsi/lpfc/lpfc.h | 13 ++++++++++--- drivers/scsi/lpfc/lpfc_attr.c | 4 ++-- 2 files changed, 12 insertions(+), 5 deletions(-)
drivers/scsi/lpfc/lpfc.h +10 -3
@@ -1163,6 +1163,16 @@ struct lpfc_hba {uint32_t cfg_hostmem_hgp;uint32_t cfg_log_verbose;uint32_t cfg_enable_fc4_type; +#define LPFC_ENABLE_FCP 1 +#define LPFC_ENABLE_NVME 2 +#define LPFC_ENABLE_BOTH 3 +#if (IS_ENABLED (CONFIG_NVME_FC )) +#define LPFC_MAX_ENBL_FC4_TYPE LPFC_ENABLE_BOTH +#define LPFC_DEF_ENBL_FC4_TYPE LPFC_ENABLE_BOTH +#else +#define LPFC_MAX_ENBL_FC4_TYPE LPFC_ENABLE_FCP +#define LPFC_DEF_ENBL_FC4_TYPE LPFC_ENABLE_FCP +#endif uint32_t cfg_aer_support;uint32_t cfg_sriov_nr_virtfn;uint32_t cfg_request_firmware_upgrade;
@@ -1184,9 +1194,6 @@ struct lpfc_hba {uint32_t cfg_ras_fwlog_func;uint32_t cfg_enable_bbcr;/* Enable BB Credit Recovery */ uint32_t cfg_enable_dpp;/* Enable Direct Packet Push */ -#define LPFC_ENABLE_FCP 1 -#define LPFC_ENABLE_NVME 2 -#define LPFC_ENABLE_BOTH 3uint32_t cfg_enable_pbde;uint32_t cfg_enable_mi;struct nvmet_fc_target_port *targetport;
drivers/scsi/lpfc/lpfc_attr.c +2 -2
@@ -3978,8 +3978,8 @@ LPFC_ATTR_R(nvmet_mrq_post,* 3 - register both FCP and NVME * Supported values are [1,3]. Default value is 3 */ -LPFC_ATTR_R (enable_fc4_type,LPFC_ENABLE_BOTH , -LPFC_ENABLE_FCP ,LPFC_ENABLE_BOTH , +LPFC_ATTR_R (enable_fc4_type,LPFC_DEF_ENBL_FC4_TYPE , +LPFC_ENABLE_FCP ,LPFC_MAX_ENBL_FC4_TYPE ,"Enable FC4 Protocol support - FCP / NVME" );/*
Greg Kroah-Hartman
maintainerPATCH 168/172 scsi: lpfc: Reduce log messages seen after firmware download
In reply to Greg Kroah-HartmanFrom: James Smart <[email protected]>
commit 5852ed2a6a39c862c8a3fdf646e1f4e01b91d710 upstream.
Messages around firmware download were incorrectly tagged as being related to discovery trace events. Thus, firmware download status ended up dumping the trace log as well as the firmware update message. As there were a couple of log messages in this state, the trace log was dumped multiple times.
Resolve this by converting from trace events to SLI events.
--- drivers/scsi/lpfc/lpfc_init.c | 2 +- drivers/scsi/lpfc/lpfc_sli.c | 8 +++++++- 2 files changed, 8 insertions(+), 2 deletions(-)
drivers/scsi/lpfc/lpfc_init.c +1 -1
@@ -2055,7 +2055,7 @@ lpfc_handle_eratt_s4(struct lpfc_hba *ph }if (reg_err1 ==SLIPORT_ERR1_REG_ERR_CODE_2 && reg_err2 ==SLIPORT_ERR2_REG_FW_RESTART ) { -lpfc_printf_log (phba,KERN_ERR ,LOG_TRACE_EVENT , +lpfc_printf_log (phba,KERN_ERR ,LOG_SLI ,"3143 Port Down: Firmware Update " "Detected\n" ); en_rn_msg = false;
drivers/scsi/lpfc/lpfc_sli.c +7 -1
@@ -13366,6 +13366,7 @@ lpfc_sli4_eratt_read(struct lpfc_hba *phuint32_t uerr_sta_hi, uerr_sta_lo;uint32_t if_type, portsmphr;struct lpfc_register portstat_reg; +u32 logmask;/* * For now, use the SLI4 device internal unrecoverable error
@@ -13416,7 +13417,12 @@ lpfc_sli4_eratt_read(struct lpfc_hba *phreadl (phba->sli4_hba.u.if_type2.ERR1regaddr); phba->work_status[1 ] =readl (phba->sli4_hba.u.if_type2.ERR2regaddr); -lpfc_printf_log (phba,KERN_ERR ,LOG_TRACE_EVENT , + logmask =LOG_TRACE_EVENT ; +if (phba->work_status[0 ] == +SLIPORT_ERR1_REG_ERR_CODE_2 && + phba->work_status[1 ] ==SLIPORT_ERR2_REG_FW_RESTART ) + logmask =LOG_SLI ; +lpfc_printf_log (phba,KERN_ERR , logmask,"2885 Port Status Event: " "port status reg 0x%x, " "port smphr reg 0x%x, "
Greg Kroah-Hartman
maintainerPATCH 169/172 MIPS: octeon: Fix missed PTR->PTR_WD conversion
In reply to Greg Kroah-HartmanFrom: Thomas Bogendoerfer <[email protected]>
commit 50317b636e7184d15126e2dfc83db0963a38d31e upstream.
--- arch/mips/cavium-octeon/octeon-memcpy.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/cavium-octeon/octeon-memcpy.S +1 -1
@@ -74,7 +74,7 @@ #define EXC(inst_reg,addr,handler) \ 9: inst_reg, addr; \ .section __ex_table,"a"; \ - PTR 9b, handler; \ + PTR_WD 9b, handler; \ .previous /*
Greg Kroah-Hartman
maintainerPATCH 170/172 arm64: dts: imx8mq: fix lcdif port node
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
commit 91f6d5f181f6629dd74ab71759fe92d3f4eff966 upstream.
The port node does not have a unit-address, remove it. This fixes the warnings:
lcd-controller@30320000: 'port' is a required property lcd-controller@30320000: 'port@0' does not match any of the regexes:
'pinctrl-[0-9]+'
--- arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/freescale/imx8mq.dtsi +1 -1
@@ -526,7 +526,7 @@ assigned-clock-rates = <0>, <0>, <0>, <594000000>; status = "disabled"; - port@0 { + port { lcdif_mipi_dsi: endpoint { remote-endpoint = <&mipi_dsi_lcdif_in>; };
Greg Kroah-Hartman
maintainerPATCH 171/172 perf: Fix list corruption in perf_cgroup_switch()
In reply to Greg Kroah-HartmanFrom: Song Liu <[email protected]>
commit 5f4e5ce638e6a490b976ade4a40017b40abb2da0 upstream.
There's list corruption on cgrp_cpuctx_list. This happens on the following path:
perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list)
cpu_ctx_sched_in
ctx_sched_in
ctx_pinned_sched_in
merge_sched_in
perf_cgroup_event_disable: remove the event from the list
Use list_for_each_entry_safe() to allow removing an entry during iteration.
--- kernel/events/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/events/core.c +2 -2
@@ -839,7 +839,7 @@ static DEFINE_PER_CPU(struct list_head,*/ static void perf_cgroup_switch (struct task_struct *task,int mode) { -struct perf_cpu_context *cpuctx; +struct perf_cpu_context *cpuctx, *tmp;struct list_head *list;unsigned long flags;
@@ -850,7 +850,7 @@ static void perf_cgroup_switch(struct talocal_irq_save (flags); list =this_cpu_ptr (&cgrp_cpuctx_list); -list_for_each_entry (cpuctx, list, cgrp_cpuctx_entry) { +list_for_each_entry_safe (cpuctx, tmp, list, cgrp_cpuctx_entry) {WARN_ON_ONCE (cpuctx->ctx.nr_cgroups ==0 );perf_ctx_lock (cpuctx, cpuctx->task_ctx);
Greg Kroah-Hartman
maintainerPATCH 172/172 iommu: Fix potential use-after-free during probe
In reply to Greg Kroah-HartmanFrom: Vijayanand Jitta <[email protected]>
commit b54240ad494300ff0994c4539a531727874381f4 upstream.
Kasan has reported the following use after free on dev->iommu. when a device probe fails and it is in process of freeing dev->iommu in dev_iommu_free function, a deferred_probe_work_func runs in parallel and tries to access dev->iommu->fwspec in of_iommu_configure path thus causing use after free.
BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4 Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153 Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x33c show_stack+0x18/0x24 dump_stack_lvl+0x16c/0x1e0 print_address_description+0x84/0x39c __kasan_report+0x184/0x308 kasan_report+0x50/0x78 __asan_load8+0xc0/0xc4 of_iommu_configure+0xb4/0x4a4 of_dma_configure_id+0x2fc/0x4d4 platform_dma_configure+0x40/0x5c really_probe+0x1b4/0xb74 driver_probe_device+0x11c/0x228 __device_attach_driver+0x14c/0x304 bus_for_each_drv+0x124/0x1b0 __device_attach+0x25c/0x334 device_initial_probe+0x24/0x34 bus_probe_device+0x78/0x134 deferred_probe_work_func+0x130/0x1a8 process_one_work+0x4c8/0x970 worker_thread+0x5c8/0xaec kthread+0x1f8/0x220 ret_from_fork+0x10/0x18 Allocated by task 1: ____kasan_kmalloc+0xd4/0x114 __kasan_kmalloc+0x10/0x1c kmem_cache_alloc_trace+0xe4/0x3d4 __iommu_probe_device+0x90/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Freed by task 1: kasan_set_track+0x4c/0x84 kasan_set_free_info+0x28/0x4c ____kasan_slab_free+0x120/0x15c __kasan_slab_free+0x18/0x28 slab_free_freelist_hook+0x204/0x2fc kfree+0xfc/0x3a4 __iommu_probe_device+0x284/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180
Fix this by setting dev->iommu to NULL first and then freeing dev_iommu structure in dev_iommu_free function.
--- drivers/iommu/iommu.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/iommu/iommu.c +7 -2
@@ -206,9 +206,14 @@ static struct dev_iommu *dev_iommu_get(sstatic void dev_iommu_free (struct device *dev) { -iommu_fwspec_free (dev); -kfree (dev->iommu); +struct dev_iommu *param = dev->iommu; + dev->iommu =NULL ; +if (param->fwspec) { +fwnode_handle_put (param->fwspec->iommu_fwnode); +kfree (param->fwspec); + } +kfree (param); }static int __iommu_probe_device (struct device *dev,struct list_head *group_list)
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +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.15.24-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
On Linux mainline master branch with arm64 clang-nigtly build failed due to following errors and warnings.
Now it is also noticed on stable-rc 5.15 and 5.16.
net/ipv4/tcp_input.c: clang: error: clang frontend command failed with exit code 139 (use -v to see invocation)
https://github.com/llvm/llvm-project/issues/53811
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +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.15.24-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
114 tests: 114 pass, 0 failLinux version: 5.15.24-rc1-g2092ea833107
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +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.15.24-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.24-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +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.15.24-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.24-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
5.15.24-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +0000. Anything received after that time might be too late.
5.15.24-rc1 on my x86_64 test system compiled and booted with no errors or regressions.
Thanks,
Slade
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +0000. Anything received after that time might be too late.
Build results:
total: 156 pass: 156 fail: 0 Qemu test results: total: 488 pass: 488 fail: 0
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +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.15.24-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.15.24-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.15.y
* git commit: 2092ea8331071900a0b3ed6ce06daae663215b92
* git describe: v5.15.23-173-g2092ea833107
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.23-173-g2092ea833107
## Test Regressions (compared to v5.15.22-6-g722769939d60) No test regressions found.
## Metric Regressions (compared to v5.15.22-6-g722769939d60) No metric regressions found.
## Test Fixes (compared to v5.15.22-6-g722769939d60) No test fixes found.
## Metric Fixes (compared to v5.15.22-6-g722769939d60) No metric fixes found.
## Test result summary
total: 98687, pass: 84389, fail: 1195, skip: 12142, xfail: 961
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 263 total, 261 passed, 2 failed
* arm64: 42 total, 40 passed, 2 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 40 total, 37 passed, 3 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 37 total, 35 passed, 2 failed
* parisc: 14 total, 14 passed, 0 failed
* powerpc: 56 total, 40 passed, 16 failed
* riscv: 28 total, 24 passed, 4 failed
* s390: 22 total, 20 passed, 2 failed
* sh: 26 total, 24 passed, 2 failed
* sparc: 14 total, 14 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 42 total, 42 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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.
Successfully cross-compiled for arm64 (bcm2711_defconfig, clang 13.0.1) and powerpc (ps3_defconfig, gcc 11.2.0).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.24 release. There are 172 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, 16 Feb 2022 09:24:36 +0000. Anything received after that time might be too late.
Build test:
mips (gcc version 11.2.1 20220213): 62 configs -> no new failure arm (gcc version 11.2.1 20220213): 100 configs -> no new failure arm64 (gcc version 11.2.1 20220213): 3 configs -> no failure x86_64 (gcc version 11.2.1 20220213): 4 configs -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/764
[2]. https://openqa.qa.codethink.co.uk/tests/766
[3]. https://openqa.qa.codethink.co.uk/tests/767
--
Regards
Sudip