* [PATCH 5.10 01/11] module: Expose module_init_layout_section()
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
@ 2023-08-31 11:09 ` Greg Kroah-Hartman
2023-08-31 11:09 ` [PATCH 5.10 02/11] arm64: module-plts: inline linux/moduleloader.h Greg Kroah-Hartman
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:09 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Adam Johnston, James Morse,
Luis Chamberlain
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <james.morse@arm.com>
commit 2abcc4b5a64a65a2d2287ba0be5c2871c1552416 upstream.
module_init_layout_section() choses whether the core module loader
considers a section as init or not. This affects the placement of the
exit section when module unloading is disabled. This code will never run,
so it can be free()d once the module has been initialised.
arm and arm64 need to count the number of PLTs they need before applying
relocations based on the section name. The init PLTs are stored separately
so they can be free()d. arm and arm64 both use within_module_init() to
decide which list of PLTs to use when applying the relocation.
Because within_module_init()'s behaviour changes when module unloading
is disabled, both architecture would need to take this into account when
counting the PLTs.
Today neither architecture does this, meaning when module unloading is
disabled there are insufficient PLTs in the init section to load some
modules, resulting in warnings:
| WARNING: CPU: 2 PID: 51 at arch/arm64/kernel/module-plts.c:99 module_emit_plt_entry+0x184/0x1cc
| Modules linked in: crct10dif_common
| CPU: 2 PID: 51 Comm: modprobe Not tainted 6.5.0-rc4-yocto-standard-dirty #15208
| Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
| pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : module_emit_plt_entry+0x184/0x1cc
| lr : module_emit_plt_entry+0x94/0x1cc
| sp : ffffffc0803bba60
[...]
| Call trace:
| module_emit_plt_entry+0x184/0x1cc
| apply_relocate_add+0x2bc/0x8e4
| load_module+0xe34/0x1bd4
| init_module_from_file+0x84/0xc0
| __arm64_sys_finit_module+0x1b8/0x27c
| invoke_syscall.constprop.0+0x5c/0x104
| do_el0_svc+0x58/0x160
| el0_svc+0x38/0x110
| el0t_64_sync_handler+0xc0/0xc4
| el0t_64_sync+0x190/0x194
Instead of duplicating module_init_layout_section()s logic, expose it.
Reported-by: Adam Johnston <adam.johnston@arm.com>
Fixes: 055f23b74b20 ("module: check for exit sections in layout_sections() instead of module_init_section()")
Cc: stable@vger.kernel.org
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/moduleloader.h | 5 +++++
kernel/module.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
--- a/include/linux/moduleloader.h
+++ b/include/linux/moduleloader.h
@@ -39,6 +39,11 @@ bool module_init_section(const char *nam
*/
bool module_exit_section(const char *name);
+/* Describes whether within_module_init() will consider this an init section
+ * or not. This behaviour changes with CONFIG_MODULE_UNLOAD.
+ */
+bool module_init_layout_section(const char *sname);
+
/*
* Apply the given relocation to the (simplified) ELF. Return -error
* or 0.
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2280,7 +2280,7 @@ void *__symbol_get(const char *symbol)
}
EXPORT_SYMBOL_GPL(__symbol_get);
-static bool module_init_layout_section(const char *sname)
+bool module_init_layout_section(const char *sname)
{
#ifndef CONFIG_MODULE_UNLOAD
if (module_exit_section(sname))
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 02/11] arm64: module-plts: inline linux/moduleloader.h
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
2023-08-31 11:09 ` [PATCH 5.10 01/11] module: Expose module_init_layout_section() Greg Kroah-Hartman
@ 2023-08-31 11:09 ` Greg Kroah-Hartman
2023-08-31 11:09 ` [PATCH 5.10 03/11] arm64: module: Use module_init_layout_section() to spot init sections Greg Kroah-Hartman
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:09 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, Kees Cook,
Ard Biesheuvel, Catalin Marinas
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit 60a0aab7463ee69296692d980b96510ccce3934e upstream.
module_frob_arch_sections() is declared in moduleloader.h, but
that is not included before the definition:
arch/arm64/kernel/module-plts.c:286:5: error: no previous prototype for 'module_frob_arch_sections' [-Werror=missing-prototypes]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20230516160642.523862-11-arnd@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kernel/module-plts.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm64/kernel/module-plts.c
+++ b/arch/arm64/kernel/module-plts.c
@@ -7,6 +7,7 @@
#include <linux/ftrace.h>
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/moduleloader.h>
#include <linux/sort.h>
static struct plt_entry __get_adrp_add_pair(u64 dst, u64 pc,
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 03/11] arm64: module: Use module_init_layout_section() to spot init sections
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
2023-08-31 11:09 ` [PATCH 5.10 01/11] module: Expose module_init_layout_section() Greg Kroah-Hartman
2023-08-31 11:09 ` [PATCH 5.10 02/11] arm64: module-plts: inline linux/moduleloader.h Greg Kroah-Hartman
@ 2023-08-31 11:09 ` Greg Kroah-Hartman
2023-08-31 11:09 ` [PATCH 5.10 04/11] ARM: " Greg Kroah-Hartman
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:09 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Adam Johnston, James Morse,
Catalin Marinas, Luis Chamberlain
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <james.morse@arm.com>
commit f928f8b1a2496e7af95b860f9acf553f20f68f16 upstream.
Today module_frob_arch_sections() spots init sections from their
'init' prefix, and uses this to keep the init PLTs separate from the rest.
module_emit_plt_entry() uses within_module_init() to determine if a
location is in the init text or not, but this depends on whether
core code thought this was an init section.
Naturally the logic is different.
module_init_layout_section() groups the init and exit text together if
module unloading is disabled, as the exit code will never run. The result
is kernels with this configuration can't load all their modules because
there are not enough PLTs for the combined init+exit section.
This results in the following:
| WARNING: CPU: 2 PID: 51 at arch/arm64/kernel/module-plts.c:99 module_emit_plt_entry+0x184/0x1cc
| Modules linked in: crct10dif_common
| CPU: 2 PID: 51 Comm: modprobe Not tainted 6.5.0-rc4-yocto-standard-dirty #15208
| Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
| pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : module_emit_plt_entry+0x184/0x1cc
| lr : module_emit_plt_entry+0x94/0x1cc
| sp : ffffffc0803bba60
[...]
| Call trace:
| module_emit_plt_entry+0x184/0x1cc
| apply_relocate_add+0x2bc/0x8e4
| load_module+0xe34/0x1bd4
| init_module_from_file+0x84/0xc0
| __arm64_sys_finit_module+0x1b8/0x27c
| invoke_syscall.constprop.0+0x5c/0x104
| do_el0_svc+0x58/0x160
| el0_svc+0x38/0x110
| el0t_64_sync_handler+0xc0/0xc4
| el0t_64_sync+0x190/0x194
A previous patch exposed module_init_layout_section(), use that so the
logic is the same.
Reported-by: Adam Johnston <adam.johnston@arm.com>
Tested-by: Adam Johnston <adam.johnston@arm.com>
Fixes: 055f23b74b20 ("module: check for exit sections in layout_sections() instead of module_init_section()")
Cc: <stable@vger.kernel.org> # 5.15.x: 60a0aab7463ee69 arm64: module-plts: inline linux/moduleloader.h
Cc: <stable@vger.kernel.org> # 5.15.x
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kernel/module-plts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/module-plts.c
+++ b/arch/arm64/kernel/module-plts.c
@@ -343,7 +343,7 @@ int module_frob_arch_sections(Elf_Ehdr *
if (nents)
sort(rels, nents, sizeof(Elf64_Rela), cmp_rela, NULL);
- if (!str_has_prefix(secstrings + dstsec->sh_name, ".init"))
+ if (!module_init_layout_section(secstrings + dstsec->sh_name))
core_plts += count_plts(syms, rels, numrels,
sechdrs[i].sh_info, dstsec);
else
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 04/11] ARM: module: Use module_init_layout_section() to spot init sections
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2023-08-31 11:09 ` [PATCH 5.10 03/11] arm64: module: Use module_init_layout_section() to spot init sections Greg Kroah-Hartman
@ 2023-08-31 11:09 ` Greg Kroah-Hartman
2023-08-31 11:09 ` [PATCH 5.10 05/11] mhi: pci_generic: Fix implicit conversion warning Greg Kroah-Hartman
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:09 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, James Morse, Luis Chamberlain
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <james.morse@arm.com>
commit a6846234f45801441f0e31a8b37f901ef0abd2df upstream.
Today module_frob_arch_sections() spots init sections from their
'init' prefix, and uses this to keep the init PLTs separate from the rest.
get_module_plt() uses within_module_init() to determine if a
location is in the init text or not, but this depends on whether
core code thought this was an init section.
Naturally the logic is different.
module_init_layout_section() groups the init and exit text together if
module unloading is disabled, as the exit code will never run. The result
is kernels with this configuration can't load all their modules because
there are not enough PLTs for the combined init+exit section.
A previous patch exposed module_init_layout_section(), use that so the
logic is the same.
Fixes: 055f23b74b20 ("module: check for exit sections in layout_sections() instead of module_init_section()")
Cc: stable@vger.kernel.org
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/kernel/module-plts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/kernel/module-plts.c
+++ b/arch/arm/kernel/module-plts.c
@@ -256,7 +256,7 @@ int module_frob_arch_sections(Elf_Ehdr *
/* sort by type and symbol index */
sort(rels, numrels, sizeof(Elf32_Rel), cmp_rel, NULL);
- if (strncmp(secstrings + dstsec->sh_name, ".init", 5) != 0)
+ if (!module_init_layout_section(secstrings + dstsec->sh_name))
core_plts += count_plts(syms, dstsec->sh_addr, rels,
numrels, s->sh_info);
else
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 05/11] mhi: pci_generic: Fix implicit conversion warning
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2023-08-31 11:09 ` [PATCH 5.10 04/11] ARM: " Greg Kroah-Hartman
@ 2023-08-31 11:09 ` Greg Kroah-Hartman
2023-08-31 11:09 ` [PATCH 5.10 06/11] Revert "drm/amdgpu: install stub fence into potential unused fence pointers" Greg Kroah-Hartman
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:09 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Loic Poulain, kernel test robot,
Nathan Chancellor, Manivannan Sadhasivam, Guenter Roeck
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Loic Poulain <loic.poulain@linaro.org>
commit 4ea6fa2cb921cb17812501a27c3761037d64a217 upstream.
Fix the following warning with explicit cast:
warning: implicit conversion from 'unsigned long long' to
'dma_addr_t' (aka 'unsigned int')
mhi_cntrl->iova_stop = DMA_BIT_MASK(info->dma_data_width);
Fixes: 855a70c12021 ("bus: mhi: Add MHI PCI support for WWAN modems")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/bus/mhi/host/pci_generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/bus/mhi/host/pci_generic.c
+++ b/drivers/bus/mhi/host/pci_generic.c
@@ -273,7 +273,7 @@ static int mhi_pci_probe(struct pci_dev
mhi_cntrl_config = info->config;
mhi_cntrl->cntrl_dev = &pdev->dev;
mhi_cntrl->iova_start = 0;
- mhi_cntrl->iova_stop = DMA_BIT_MASK(info->dma_data_width);
+ mhi_cntrl->iova_stop = (dma_addr_t)DMA_BIT_MASK(info->dma_data_width);
mhi_cntrl->fw_image = info->fw;
mhi_cntrl->edl_image = info->edl;
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 06/11] Revert "drm/amdgpu: install stub fence into potential unused fence pointers"
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2023-08-31 11:09 ` [PATCH 5.10 05/11] mhi: pci_generic: Fix implicit conversion warning Greg Kroah-Hartman
@ 2023-08-31 11:09 ` Greg Kroah-Hartman
2023-08-31 11:09 ` [PATCH 5.10 07/11] Revert "MIPS: Alchemy: fix dbdma2" Greg Kroah-Hartman
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:09 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Guenter Roeck, From: Chia-I Wu,
Christian König, Lang Yu, Alex Deucher, Sasha Levin
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 04bd3a362d2f1788272776bd8b10e5a012e69b77 which is
commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 upstream.
It is reported to cause lots of log spam, so it should be dropped for
now.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/27d08b24-3581-4451-b8db-5df144784d6a@roeck-us.net
Reported-by: From: Chia-I Wu <olvaffe@gmail.com>
Link: https://lore.kernel.org/r/CAPaKu7RTgAMBLHbwtp4zgiBSDrTFtAj07k5qMzkuLQy2Zr+sZA@mail.gmail.com
Cc: Christian König <christian.koenig@amd.com>
Cc: Lang Yu <Lang.Yu@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2155,7 +2155,6 @@ struct amdgpu_bo_va *amdgpu_vm_bo_add(st
amdgpu_vm_bo_base_init(&bo_va->base, vm, bo);
bo_va->ref_count = 1;
- bo_va->last_pt_update = dma_fence_get_stub();
INIT_LIST_HEAD(&bo_va->valids);
INIT_LIST_HEAD(&bo_va->invalids);
@@ -2868,8 +2867,7 @@ int amdgpu_vm_init(struct amdgpu_device
vm->update_funcs = &amdgpu_vm_cpu_funcs;
else
vm->update_funcs = &amdgpu_vm_sdma_funcs;
-
- vm->last_update = dma_fence_get_stub();
+ vm->last_update = NULL;
vm->last_unlocked = dma_fence_get_stub();
mutex_init(&vm->eviction_lock);
@@ -3044,7 +3042,7 @@ int amdgpu_vm_make_compute(struct amdgpu
vm->update_funcs = &amdgpu_vm_sdma_funcs;
}
dma_fence_put(vm->last_update);
- vm->last_update = dma_fence_get_stub();
+ vm->last_update = NULL;
vm->is_compute_context = true;
if (vm->pasid) {
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 07/11] Revert "MIPS: Alchemy: fix dbdma2"
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2023-08-31 11:09 ` [PATCH 5.10 06/11] Revert "drm/amdgpu: install stub fence into potential unused fence pointers" Greg Kroah-Hartman
@ 2023-08-31 11:09 ` Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.10 08/11] rcu: Prevent expedited GP from enabling tick on offline CPU Greg Kroah-Hartman
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:09 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Guenter Roeck, Thomas Bogendoerfer,
Sasha Levin
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 619672bf2d04cdc1bc3925defd0312c2ef11e5d0 which is
commit 2d645604f69f3a772d58ead702f9a8e84ab2b342 upstream.
It breaks the build, so should be dropped.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/5b30ff73-46cb-1d1e-3823-f175dbfbd91b@roeck-us.net
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/alchemy/common/dbdma.c | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
--- a/arch/mips/alchemy/common/dbdma.c
+++ b/arch/mips/alchemy/common/dbdma.c
@@ -30,7 +30,6 @@
*
*/
-#include <linux/dma-map-ops.h> /* for dma_default_coherent */
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/slab.h>
@@ -624,18 +623,17 @@ u32 au1xxx_dbdma_put_source(u32 chanid,
dp->dscr_cmd0 &= ~DSCR_CMD0_IE;
/*
- * There is an erratum on certain Au1200/Au1550 revisions that could
- * result in "stale" data being DMA'ed. It has to do with the snoop
- * logic on the cache eviction buffer. dma_default_coherent is set
- * to false on these parts.
+ * There is an errata on the Au1200/Au1550 parts that could result
+ * in "stale" data being DMA'ed. It has to do with the snoop logic on
+ * the cache eviction buffer. DMA_NONCOHERENT is on by default for
+ * these parts. If it is fixed in the future, these dma_cache_inv will
+ * just be nothing more than empty macros. See io.h.
*/
- if (!dma_default_coherent)
- dma_cache_wback_inv(KSEG0ADDR(buf), nbytes);
+ dma_cache_wback_inv((unsigned long)buf, nbytes);
dp->dscr_cmd0 |= DSCR_CMD0_V; /* Let it rip */
wmb(); /* drain writebuffer */
dma_cache_wback_inv((unsigned long)dp, sizeof(*dp));
ctp->chan_ptr->ddma_dbell = 0;
- wmb(); /* force doorbell write out to dma engine */
/* Get next descriptor pointer. */
ctp->put_ptr = phys_to_virt(DSCR_GET_NXTPTR(dp->dscr_nxtptr));
@@ -687,18 +685,17 @@ u32 au1xxx_dbdma_put_dest(u32 chanid, dm
dp->dscr_source1, dp->dscr_dest0, dp->dscr_dest1);
#endif
/*
- * There is an erratum on certain Au1200/Au1550 revisions that could
- * result in "stale" data being DMA'ed. It has to do with the snoop
- * logic on the cache eviction buffer. dma_default_coherent is set
- * to false on these parts.
+ * There is an errata on the Au1200/Au1550 parts that could result in
+ * "stale" data being DMA'ed. It has to do with the snoop logic on the
+ * cache eviction buffer. DMA_NONCOHERENT is on by default for these
+ * parts. If it is fixed in the future, these dma_cache_inv will just
+ * be nothing more than empty macros. See io.h.
*/
- if (!dma_default_coherent)
- dma_cache_inv(KSEG0ADDR(buf), nbytes);
+ dma_cache_inv((unsigned long)buf, nbytes);
dp->dscr_cmd0 |= DSCR_CMD0_V; /* Let it rip */
wmb(); /* drain writebuffer */
dma_cache_wback_inv((unsigned long)dp, sizeof(*dp));
ctp->chan_ptr->ddma_dbell = 0;
- wmb(); /* force doorbell write out to dma engine */
/* Get next descriptor pointer. */
ctp->put_ptr = phys_to_virt(DSCR_GET_NXTPTR(dp->dscr_nxtptr));
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 08/11] rcu: Prevent expedited GP from enabling tick on offline CPU
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2023-08-31 11:09 ` [PATCH 5.10 07/11] Revert "MIPS: Alchemy: fix dbdma2" Greg Kroah-Hartman
@ 2023-08-31 11:10 ` Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.10 09/11] rcu-tasks: Fix IPI failure handling in trc_wait_for_one_reader Greg Kroah-Hartman
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:10 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Paul E. McKenney,
Joel Fernandes (Google)
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul E. McKenney <paulmck@kernel.org>
commit 147f04b14adde831eb4a0a1e378667429732f9e8 upstream.
If an RCU expedited grace period starts just when a CPU is in the process
of going offline, so that the outgoing CPU has completed its pass through
stop-machine but has not yet completed its final dive into the idle loop,
RCU will attempt to enable that CPU's scheduling-clock tick via a call
to tick_dep_set_cpu(). For this to happen, that CPU has to have been
online when the expedited grace period completed its CPU-selection phase.
This is pointless: The outgoing CPU has interrupts disabled, so it cannot
take a scheduling-clock tick anyway. In addition, the tick_dep_set_cpu()
function's eventual call to irq_work_queue_on() will splat as follows:
smpboot: CPU 1 is now offline
WARNING: CPU: 6 PID: 124 at kernel/irq_work.c:95
+irq_work_queue_on+0x57/0x60
Modules linked in:
CPU: 6 PID: 124 Comm: kworker/6:2 Not tainted 5.15.0-rc1+ #3
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
+rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
Workqueue: rcu_gp wait_rcu_exp_gp
RIP: 0010:irq_work_queue_on+0x57/0x60
Code: 8b 05 1d c7 ea 62 a9 00 00 f0 00 75 21 4c 89 ce 44 89 c7 e8
+9b 37 fa ff ba 01 00 00 00 89 d0 c3 4c 89 cf e8 3b ff ff ff eb ee <0f> 0b eb b7
+0f 0b eb db 90 48 c7 c0 98 2a 02 00 65 48 03 05 91
6f
RSP: 0000:ffffb12cc038fe48 EFLAGS: 00010282
RAX: 0000000000000001 RBX: 0000000000005208 RCX: 0000000000000020
RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff9ad01f45a680
RBP: 000000000004c990 R08: 0000000000000001 R09: ffff9ad01f45a680
R10: ffffb12cc0317db0 R11: 0000000000000001 R12: 00000000fffecee8
R13: 0000000000000001 R14: 0000000000026980 R15: ffffffff9e53ae00
FS: 0000000000000000(0000) GS:ffff9ad01f580000(0000)
+knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000000de0c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
tick_nohz_dep_set_cpu+0x59/0x70
rcu_exp_wait_wake+0x54e/0x870
? sync_rcu_exp_select_cpus+0x1fc/0x390
process_one_work+0x1ef/0x3c0
? process_one_work+0x3c0/0x3c0
worker_thread+0x28/0x3c0
? process_one_work+0x3c0/0x3c0
kthread+0x115/0x140
? set_kthread_struct+0x40/0x40
ret_from_fork+0x22/0x30
---[ end trace c5bf75eb6aa80bc6 ]---
This commit therefore avoids invoking tick_dep_set_cpu() on offlined
CPUs to limit both futility and false-positive splats.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/rcu/tree_exp.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -507,7 +507,10 @@ static void synchronize_rcu_expedited_wa
if (rdp->rcu_forced_tick_exp)
continue;
rdp->rcu_forced_tick_exp = true;
- tick_dep_set_cpu(cpu, TICK_DEP_BIT_RCU_EXP);
+ preempt_disable();
+ if (cpu_online(cpu))
+ tick_dep_set_cpu(cpu, TICK_DEP_BIT_RCU_EXP);
+ preempt_enable();
}
}
j = READ_ONCE(jiffies_till_first_fqs);
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 09/11] rcu-tasks: Fix IPI failure handling in trc_wait_for_one_reader
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2023-08-31 11:10 ` [PATCH 5.10 08/11] rcu: Prevent expedited GP from enabling tick on offline CPU Greg Kroah-Hartman
@ 2023-08-31 11:10 ` Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.10 10/11] rcu-tasks: Wait for trc_read_check_handler() IPIs Greg Kroah-Hartman
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:10 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Neeraj Upadhyay, Paul E. McKenney,
Joel Fernandes
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neeraj Upadhyay <neeraju@codeaurora.org>
commit 46aa886c483f57ef13cd5ea0a85e70b93eb1d381 upstream.
The trc_wait_for_one_reader() function is called at multiple stages
of trace rcu-tasks GP function, rcu_tasks_wait_gp():
- First, it is called as part of per task function -
rcu_tasks_trace_pertask(), for all non-idle tasks. As part of per task
processing, this function add the task in the holdout list and if the
task is currently running on a CPU, it sends IPI to the task's CPU.
The IPI handler takes action depending on whether task is in trace
rcu-tasks read side critical section or not:
- a. If the task is in trace rcu-tasks read side critical section
(t->trc_reader_nesting != 0), the IPI handler sets the task's
->trc_reader_special.b.need_qs, so that this task notifies exit
from its outermost read side critical section (by decrementing
trc_n_readers_need_end) to the GP handling function.
trc_wait_for_one_reader() also increments trc_n_readers_need_end,
so that the trace rcu-tasks GP handler function waits for this
task's read side exit notification. The IPI handler also sets
t->trc_reader_checked to true, and no further IPIs are sent for
this task, for this trace rcu-tasks grace period and this
task can be removed from holdout list.
- b. If the task is in the process of exiting its trace rcu-tasks
read side critical section, (t->trc_reader_nesting < 0), defer
this task's processing to future calls to trc_wait_for_one_reader().
- c. If task is not in rcu-task read side critical section,
t->trc_reader_nesting == 0, ->trc_reader_checked is set for this
task, so that this task is removed from holdout list.
- Second, trc_wait_for_one_reader() is called as part of post scan, in
function rcu_tasks_trace_postscan(), for all idle tasks.
- Third, in function check_all_holdout_tasks_trace(), this function is
called for each task in the holdout list, but only if there isn't
a pending IPI for the task (->trc_ipi_to_cpu == -1). This function
removed the task from holdout list, if IPI handler has completed the
required work, to ensure that the current trace rcu-tasks grace period
either waits for this task, or this task is not in a trace rcu-tasks
read side critical section.
Now, considering the scenario where smp_call_function_single() fails in
first case, inside rcu_tasks_trace_pertask(). In this case,
->trc_ipi_to_cpu is set to the current CPU for that task. This will
result in trc_wait_for_one_reader() getting skipped in third case,
inside check_all_holdout_tasks_trace(), for this task. This further
results in ->trc_reader_checked never getting set for this task,
and the task not getting removed from holdout list. This can cause
the current trace rcu-tasks grace period to stall.
Fix the above problem, by resetting ->trc_ipi_to_cpu to -1, on
smp_call_function_single() failure, so that future IPI calls can
be send for this task.
Note that all three of the trc_wait_for_one_reader() function's
callers (rcu_tasks_trace_pertask(), rcu_tasks_trace_postscan(),
check_all_holdout_tasks_trace()) hold cpu_read_lock(). This means
that smp_call_function_single() cannot race with CPU hotplug, and thus
should never fail. Therefore, also add a warning in order to report
any such failure in case smp_call_function_single() grows some other
reason for failure.
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Joel Fernandes <joel@joelfernandes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/rcu/tasks.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/kernel/rcu/tasks.h
+++ b/kernel/rcu/tasks.h
@@ -958,9 +958,11 @@ static void trc_wait_for_one_reader(stru
if (smp_call_function_single(cpu, trc_read_check_handler, t, 0)) {
// Just in case there is some other reason for
// failure than the target CPU being offline.
+ WARN_ONCE(1, "%s(): smp_call_function_single() failed for CPU: %d\n",
+ __func__, cpu);
rcu_tasks_trace.n_ipis_fails++;
per_cpu(trc_ipi_to_cpu, cpu) = false;
- t->trc_ipi_to_cpu = cpu;
+ t->trc_ipi_to_cpu = -1;
}
}
}
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 10/11] rcu-tasks: Wait for trc_read_check_handler() IPIs
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2023-08-31 11:10 ` [PATCH 5.10 09/11] rcu-tasks: Fix IPI failure handling in trc_wait_for_one_reader Greg Kroah-Hartman
@ 2023-08-31 11:10 ` Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.10 11/11] rcu-tasks: Add trc_inspect_reader() checks for exiting critical section Greg Kroah-Hartman
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:10 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Paul E. McKenney, Joel Fernandes
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul E. McKenney <paulmck@kernel.org>
commit cbe0d8d91415c9692fe88191940d98952b6855d9 upstream.
Currently, RCU Tasks Trace initializes the trc_n_readers_need_end counter
to the value one, increments it before each trc_read_check_handler()
IPI, then decrements it within trc_read_check_handler() if the target
task was in a quiescent state (or if the target task moved to some other
CPU while the IPI was in flight), complaining if the new value was zero.
The rationale for complaining is that the initial value of one must be
decremented away before zero can be reached, and this decrement has not
yet happened.
Except that trc_read_check_handler() is initiated with an asynchronous
smp_call_function_single(), which might be significantly delayed. This
can result in false-positive complaints about the counter reaching zero.
This commit therefore waits for in-flight IPI handlers to complete before
decrementing away the initial value of one from the trc_n_readers_need_end
counter.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Joel Fernandes <joel@joelfernandes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/rcu/tasks.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/kernel/rcu/tasks.h
+++ b/kernel/rcu/tasks.h
@@ -1083,14 +1083,28 @@ static void check_all_holdout_tasks_trac
}
}
+static void rcu_tasks_trace_empty_fn(void *unused)
+{
+}
+
/* Wait for grace period to complete and provide ordering. */
static void rcu_tasks_trace_postgp(struct rcu_tasks *rtp)
{
+ int cpu;
bool firstreport;
struct task_struct *g, *t;
LIST_HEAD(holdouts);
long ret;
+ // Wait for any lingering IPI handlers to complete. Note that
+ // if a CPU has gone offline or transitioned to userspace in the
+ // meantime, all IPI handlers should have been drained beforehand.
+ // Yes, this assumes that CPUs process IPIs in order. If that ever
+ // changes, there will need to be a recheck and/or timed wait.
+ for_each_online_cpu(cpu)
+ if (smp_load_acquire(per_cpu_ptr(&trc_ipi_to_cpu, cpu)))
+ smp_call_function_single(cpu, rcu_tasks_trace_empty_fn, NULL, 1);
+
// Remove the safety count.
smp_mb__before_atomic(); // Order vs. earlier atomics
atomic_dec(&trc_n_readers_need_end);
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 5.10 11/11] rcu-tasks: Add trc_inspect_reader() checks for exiting critical section
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2023-08-31 11:10 ` [PATCH 5.10 10/11] rcu-tasks: Wait for trc_read_check_handler() IPIs Greg Kroah-Hartman
@ 2023-08-31 11:10 ` Greg Kroah-Hartman
2023-08-31 20:22 ` [PATCH 5.10 00/11] 5.10.194-rc1 review Florian Fainelli
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2023-08-31 11:10 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Paul E. McKenney, Joel Fernandes
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul E. McKenney <paulmck@kernel.org>
commit 18f08e758f34e6dfe0668bee51bd2af7adacf381 upstream.
Currently, trc_inspect_reader() treats a task exiting its RCU Tasks
Trace read-side critical section the same as being within that critical
section. However, this can fail because that task might have already
checked its .need_qs field, which means that it might never decrement
the all-important trc_n_readers_need_end counter. Of course, for that
to happen, the task would need to never again execute an RCU Tasks Trace
read-side critical section, but this really could happen if the system's
last trampoline was removed. Note that exit from such a critical section
cannot be treated as a quiescent state due to the possibility of nested
critical sections. This means that if trc_inspect_reader() sees a
negative nesting value, it must set up to try again later.
This commit therefore ignores tasks that are exiting their RCU Tasks
Trace read-side critical sections so that they will be rechecked later.
[ paulmck: Apply feedback from Neeraj Upadhyay and Boqun Feng. ]
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Joel Fernandes <joel@joelfernandes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/rcu/tasks.h | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/kernel/rcu/tasks.h
+++ b/kernel/rcu/tasks.h
@@ -874,7 +874,7 @@ reset_ipi:
static bool trc_inspect_reader(struct task_struct *t, void *arg)
{
int cpu = task_cpu(t);
- bool in_qs = false;
+ int nesting;
bool ofl = cpu_is_offline(cpu);
if (task_curr(t)) {
@@ -894,18 +894,18 @@ static bool trc_inspect_reader(struct ta
n_heavy_reader_updates++;
if (ofl)
n_heavy_reader_ofl_updates++;
- in_qs = true;
+ nesting = 0;
} else {
// The task is not running, so C-language access is safe.
- in_qs = likely(!t->trc_reader_nesting);
+ nesting = t->trc_reader_nesting;
}
- // Mark as checked so that the grace-period kthread will
- // remove it from the holdout list.
- t->trc_reader_checked = true;
-
- if (in_qs)
- return true; // Already in quiescent state, done!!!
+ // If not exiting a read-side critical section, mark as checked
+ // so that the grace-period kthread will remove it from the
+ // holdout list.
+ t->trc_reader_checked = nesting >= 0;
+ if (nesting <= 0)
+ return !nesting; // If in QS, done, otherwise try again later.
// The task is in a read-side critical section, so set up its
// state so that it will awaken the grace-period kthread upon exit
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 5.10 00/11] 5.10.194-rc1 review
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2023-08-31 11:10 ` [PATCH 5.10 11/11] rcu-tasks: Add trc_inspect_reader() checks for exiting critical section Greg Kroah-Hartman
@ 2023-08-31 20:22 ` Florian Fainelli
2023-09-01 9:28 ` Sudip Mukherjee (Codethink)
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Florian Fainelli @ 2023-08-31 20:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw, rwarsow,
conor
On 8/31/23 04:09, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.194 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Sep 2023 11:08:22 +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.194-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-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:
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 5.10 00/11] 5.10.194-rc1 review
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2023-08-31 20:22 ` [PATCH 5.10 00/11] 5.10.194-rc1 review Florian Fainelli
@ 2023-09-01 9:28 ` Sudip Mukherjee (Codethink)
2023-09-01 11:59 ` Naresh Kamboju
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Sudip Mukherjee (Codethink) @ 2023-09-01 9:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli, srw, rwarsow,
conor
Hi Greg,
On Thu, Aug 31, 2023 at 01:09:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.194 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Sep 2023 11:08:22 +0000.
> Anything received after that time might be too late.
Build test (gcc version 11.4.1 20230829):
mips: 63 configs -> no failure
arm: 104 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> 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]
[1]. https://openqa.qa.codethink.co.uk/tests/4881
[2]. https://openqa.qa.codethink.co.uk/tests/4902
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
--
Regards
Sudip
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 5.10 00/11] 5.10.194-rc1 review
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2023-09-01 9:28 ` Sudip Mukherjee (Codethink)
@ 2023-09-01 11:59 ` Naresh Kamboju
2023-09-01 15:50 ` Shuah Khan
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Naresh Kamboju @ 2023-09-01 11:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor
On Thu, 31 Aug 2023 at 16:40, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.10.194 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Sep 2023 11:08:22 +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.194-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.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.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 5.10.194-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: e25611a229ff9e907889923c2702d817003bc228
* git describe: v5.10.193-12-ge25611a229ff
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.193-12-ge25611a229ff
## Test Regressions (compared to v5.10.193)
## Metric Regressions (compared to v5.10.193)
## Test Fixes (compared to v5.10.193)
## Metric Fixes (compared to v5.10.193)
## Test result summary
total: 97983, pass: 79078, fail: 2772, skip: 16068, xfail: 65
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 112 total, 112 passed, 0 failed
* arm64: 43 total, 43 passed, 0 failed
* i386: 35 total, 35 passed, 0 failed
* mips: 27 total, 26 passed, 1 failed
* parisc: 4 total, 0 passed, 4 failed
* powerpc: 25 total, 24 passed, 1 failed
* riscv: 12 total, 11 passed, 1 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 14 total, 12 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 37 total, 37 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 5.10 00/11] 5.10.194-rc1 review
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2023-09-01 11:59 ` Naresh Kamboju
@ 2023-09-01 15:50 ` Shuah Khan
2023-09-01 19:58 ` Jon Hunter
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Shuah Khan @ 2023-09-01 15:50 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, Shuah Khan
On 8/31/23 05:09, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.194 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Sep 2023 11:08:22 +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.194-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 5.10 00/11] 5.10.194-rc1 review
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2023-09-01 15:50 ` Shuah Khan
@ 2023-09-01 19:58 ` Jon Hunter
2023-09-02 4:18 ` Guenter Roeck
2023-09-18 21:33 ` Naresh Kamboju
17 siblings, 0 replies; 19+ messages in thread
From: Jon Hunter @ 2023-09-01 19:58 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, linux-tegra, stable
On Thu, 31 Aug 2023 13:09:52 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.194 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Sep 2023 11:08:22 +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.194-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-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:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
75 tests: 75 pass, 0 fail
Linux version: 5.10.194-rc1-ge25611a229ff
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-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 5.10 00/11] 5.10.194-rc1 review
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2023-09-01 19:58 ` Jon Hunter
@ 2023-09-02 4:18 ` Guenter Roeck
2023-09-18 21:33 ` Naresh Kamboju
17 siblings, 0 replies; 19+ messages in thread
From: Guenter Roeck @ 2023-09-02 4:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor
On Thu, Aug 31, 2023 at 01:09:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.194 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Sep 2023 11:08:22 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 487 pass: 487 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 5.10 00/11] 5.10.194-rc1 review
2023-08-31 11:09 [PATCH 5.10 00/11] 5.10.194-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2023-09-02 4:18 ` Guenter Roeck
@ 2023-09-18 21:33 ` Naresh Kamboju
17 siblings, 0 replies; 19+ messages in thread
From: Naresh Kamboju @ 2023-09-18 21:33 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor
On Thu, 31 Aug 2023 at 16:40, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.10.194 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Sep 2023 11:08:22 +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.194-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.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.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 5.10.195-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: 95379666b7a68327e8f4c3a0dbf28ae0c479ab4c
* git describe: v5.10.194-407-g95379666b7a6
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.194-407-g95379666b7a6
## Test Regressions (compared to v5.10.194)
## Metric Regressions (compared to v5.10.194)
## Test Fixes (compared to v5.10.194)
## Metric Fixes (compared to v5.10.194)
## Test result summary
total: 80823, pass: 63120, fail: 2111, skip: 15541, xfail: 51
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 111 total, 111 passed, 0 failed
* arm64: 38 total, 38 passed, 0 failed
* i386: 28 total, 28 passed, 0 failed
* mips: 23 total, 23 passed, 0 failed
* parisc: 3 total, 0 passed, 3 failed
* powerpc: 23 total, 23 passed, 0 failed
* riscv: 8 total, 8 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 11 total, 11 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 33 total, 33 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 19+ messages in thread