Skip to contentSkip to conversation

5.4.25-stable review

PATCH In review Greg Kroah-Hartman 3 participants 177 messages Mar 10, 2020 – Mar 11, 2020 Page 2 of 2

Subsystems (3)
Stable branch USB EFI
lore
Share & tools
lore
author maintainer
#167 lore raw

PATCH 167/168 efi/x86: Handle by-ref arguments covering multiple pages in mixed mode

In reply to Greg Kroah-Hartman

From: Ard Biesheuvel <[email protected]>

commit 8319e9d5ad98ffccd19f35664382c73cea216193 upstream.

The mixed mode runtime wrappers are fragile when it comes to how the memory referred to by its pointer arguments are laid out in memory, due to the fact that it translates these addresses to physical addresses that the runtime services can dereference when running in 1:1 mode. Since vmalloc'ed pages (including the vmap'ed stack) are not contiguous in the physical address space, this scheme only works if the referenced memory objects do not cross page boundaries.

Currently, the mixed mode runtime service wrappers require that all by-ref arguments that live in the vmalloc space have a size that is a power of 2, and are aligned to that same value. While this is a sensible way to construct an object that is guaranteed not to cross a page boundary, it is overly strict when it comes to checking whether a given object violates this requirement, as we can simply take the physical address of the first and the last byte, and verify that they point into the same physical page.

When this check fails, we emit a WARN(), but then simply proceed with the call, which could cause data corruption if the next physical page belongs to a mapping that is entirely unrelated.

Given that with vmap'ed stacks, this condition is much more likely to trigger, let's relax the condition a bit, but fail the runtime service call if it does trigger.

Fixes f6697df36bdf0bf7 ("x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y")
Signed-off-by Ard Biesheuvel <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>
Cc [email protected]
Cc Ingo Molnar <[email protected]>
Cc Thomas Gleixner <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 arch/x86/platform/efi/efi_64.c |   45 +++++++++++++++++++++++------------------
 1 file changed, 26 insertions(+), 19 deletions(-)
arch/x86/platform/efi/efi_64.c +26 -19
@@ -316,7 +316,7 @@ void efi_sync_low_kernel_mappings(void)
 static inline phys_addr_t
 virt_to_phys_or_null_size(void *va, unsigned long size)
 {
-	bool bad_size;
+	phys_addr_t pa;
 
 	if (!va)
 		return 0;

@@ -324,16 +324,13 @@ virt_to_phys_or_null_size(void *va, unsi
 	if (virt_addr_valid(va))
 		return virt_to_phys(va);
 
-	/*
-	 * A fully aligned variable on the stack is guaranteed not to
-	 * cross a page bounary. Try to catch strings on the stack by
-	 * checking that 'size' is a power of two.
-	 */
-	bad_size = size > PAGE_SIZE || !is_power_of_2(size);
+	pa = slow_virt_to_phys(va);
 
-	WARN_ON(!IS_ALIGNED((unsigned long)va, size) || bad_size);
+	/* check if the object crosses a page boundary */
+	if (WARN_ON((pa ^ (pa + size - 1)) & PAGE_MASK))
+		return 0;
 
-	return slow_virt_to_phys(va);
+	return pa;
 }
 
 #define virt_to_phys_or_null(addr)				\

@@ -808,8 +805,11 @@ efi_thunk_get_variable(efi_char16_t *nam
 	phys_attr = virt_to_phys_or_null(attr);
 	phys_data = virt_to_phys_or_null_size(data, *data_size);
 
-	status = efi_thunk(get_variable, phys_name, phys_vendor,
-			   phys_attr, phys_data_size, phys_data);
+	if (!phys_name || (data && !phys_data))
+		status = EFI_INVALID_PARAMETER;
+	else
+		status = efi_thunk(get_variable, phys_name, phys_vendor,
+				   phys_attr, phys_data_size, phys_data);
 
 	spin_unlock_irqrestore(&efi_runtime_lock, flags);
 

@@ -834,9 +834,11 @@ efi_thunk_set_variable(efi_char16_t *nam
 	phys_vendor = virt_to_phys_or_null(vnd);
 	phys_data = virt_to_phys_or_null_size(data, data_size);
 
-	/* If data_size is > sizeof(u32) we've got problems */
-	status = efi_thunk(set_variable, phys_name, phys_vendor,
-			   attr, data_size, phys_data);
+	if (!phys_name || !phys_data)
+		status = EFI_INVALID_PARAMETER;
+	else
+		status = efi_thunk(set_variable, phys_name, phys_vendor,
+				   attr, data_size, phys_data);
 
 	spin_unlock_irqrestore(&efi_runtime_lock, flags);
 

@@ -863,9 +865,11 @@ efi_thunk_set_variable_nonblocking(efi_c
 	phys_vendor = virt_to_phys_or_null(vnd);
 	phys_data = virt_to_phys_or_null_size(data, data_size);
 
-	/* If data_size is > sizeof(u32) we've got problems */
-	status = efi_thunk(set_variable, phys_name, phys_vendor,
-			   attr, data_size, phys_data);
+	if (!phys_name || !phys_data)
+		status = EFI_INVALID_PARAMETER;
+	else
+		status = efi_thunk(set_variable, phys_name, phys_vendor,
+				   attr, data_size, phys_data);
 
 	spin_unlock_irqrestore(&efi_runtime_lock, flags);
 

@@ -891,8 +895,11 @@ efi_thunk_get_next_variable(unsigned lon
 	phys_vendor = virt_to_phys_or_null(vnd);
 	phys_name = virt_to_phys_or_null_size(name, *name_size);
 
-	status = efi_thunk(get_next_variable, phys_name_size,
-			   phys_name, phys_vendor);
+	if (!phys_name)
+		status = EFI_INVALID_PARAMETER;
+	else
+		status = efi_thunk(get_next_variable, phys_name_size,
+				   phys_name, phys_vendor);
 
 	spin_unlock_irqrestore(&efi_runtime_lock, flags);
author maintainer
#168 lore raw

PATCH 168/168 efi: READ_ONCE rng seed size before munmap

In reply to Greg Kroah-Hartman

From: Jason A. Donenfeld <[email protected]>

commit be36f9e7517e17810ec369626a128d7948942259 upstream.

This function is consistent with using size instead of seed->size (except for one place that this patch fixes), but it reads seed->size without using READ_ONCE, which means the compiler might still do something unwanted. So, this commit simply adds the READ_ONCE wrapper.

Fixes 636259880a7e ("efi: Add support for seeding the RNG from a UEFI ...")
Signed-off-by Jason A. Donenfeld <[email protected]>
Signed-off-by Ard Biesheuvel <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>
Cc [email protected]
Cc Ingo Molnar <[email protected]>
Cc Thomas Gleixner <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/firmware/efi/efi.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/firmware/efi/efi.c +2 -2
@@ -544,7 +544,7 @@ int __init efi_config_parse_tables(void
 
 		seed = early_memremap(efi.rng_seed, sizeof(*seed));
 		if (seed != NULL) {
-			size = seed->size;
+			size = READ_ONCE(seed->size);
 			early_memunmap(seed, sizeof(*seed));
 		} else {
 			pr_err("Could not map UEFI random seed!\n");

@@ -554,7 +554,7 @@ int __init efi_config_parse_tables(void
 					      sizeof(*seed) + size);
 			if (seed != NULL) {
 				pr_notice("seeding entropy pool\n");
-				add_bootloader_randomness(seed->bits, seed->size);
+				add_bootloader_randomness(seed->bits, size);
 				early_memunmap(seed, sizeof(*seed) + size);
 			} else {
 				pr_err("Could not map UEFI random seed!\n");
#169 lore raw
In reply to Greg Kroah-Hartman
Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.25 release.

This fails to compile due to broken patch 001/168:
"block, bfq: get a ref to a group when adding it to a service tree":

..
block/bfq-wf2q.c: In function 'bfq_get_entity':
./include/linux/kernel.h:994:51: error: 'struct bfq_group' has no member named 'entity' ..

The calls to bfq_get_entity::bfqg_and_blkg_get and bfq_forget_entity::bfqg_and_blkg_put in bfq-wf2q.c need to be wrapped in #ifdef CONFIG_BFQ_GROUP_IOSCHED, otherwise the build will fail when CONFIG_BFQ_GROUP_IOSCHED is not enabled.
This horribly error-prone #ifdef mess was finally removed in upstream commit 4d8340d0d4d9. For 5.4 we'll either need that as well or add them back.

-h

author maintainer
#170 lore raw
Quoted 11 lines · Holger Hoffstätte
Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.25 release.

This fails to compile due to broken patch 001/168:
"block, bfq: get a ref to a group when adding it to a service tree":

..
block/bfq-wf2q.c: In function 'bfq_get_entity':
./include/linux/kernel.h:994:51: error: 'struct bfq_group' has no member named 'entity' ..

Quoted 5 lines

The calls to bfq_get_entity::bfqg_and_blkg_get and bfq_forget_entity::bfqg_and_blkg_put in bfq-wf2q.c need to be wrapped in #ifdef CONFIG_BFQ_GROUP_IOSCHED, otherwise the build will fail when CONFIG_BFQ_GROUP_IOSCHED is not enabled.
This horribly error-prone #ifdef mess was finally removed in upstream commit 4d8340d0d4d9. For 5.4 we'll either need that as well or add them back.

Ick, that's a mess.

I'll go drop that patch now, odd that it passed my build tests...

thanks,

greg k-h

#171 lore raw
Quoted 18 lines · Greg Kroah-Hartman
Quoted 11 lines · Holger Hoffstätte
Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.25 release.

This fails to compile due to broken patch 001/168:
"block, bfq: get a ref to a group when adding it to a service tree":

..
block/bfq-wf2q.c: In function 'bfq_get_entity':
./include/linux/kernel.h:994:51: error: 'struct bfq_group' has no member named 'entity' ..

Quoted 5 lines

The calls to bfq_get_entity::bfqg_and_blkg_get and bfq_forget_entity::bfqg_and_blkg_put in bfq-wf2q.c need to be wrapped in #ifdef CONFIG_BFQ_GROUP_IOSCHED, otherwise the build will fail when CONFIG_BFQ_GROUP_IOSCHED is not enabled.
This horribly error-prone #ifdef mess was finally removed in upstream commit 4d8340d0d4d9. For 5.4 we'll either need that as well or add them back.

Quoted 3 lines

Ick, that's a mess.

I'll go drop that patch now, odd that it passed my build tests...

Uh, please no? It fixes a rather nasty UAF when cgroups are in use. Please just add the other upstream commit as well, I confirmed it applies cleanly and fixes the problem.

thanks,
Holger

Tested-by Chris Evich
#172 lore raw
Quoted 19 lines · Holger Hoffstätte
Quoted 18 lines · Greg Kroah-Hartman
Quoted 16 lines · Holger Hoffstätte
Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.25 release.

This fails to compile due to broken patch 001/168:
"block, bfq: get a ref to a group when adding it to a service tree":

..
block/bfq-wf2q.c: In function 'bfq_get_entity':
./include/linux/kernel.h:994:51: error: 'struct bfq_group' has no member named 'entity' ..

The calls to bfq_get_entity::bfqg_and_blkg_get and bfq_forget_entity::bfqg_and_blkg_put in bfq-wf2q.c need to be wrapped in #ifdef CONFIG_BFQ_GROUP_IOSCHED, otherwise the build will fail when CONFIG_BFQ_GROUP_IOSCHED is not enabled.
This horribly error-prone #ifdef mess was finally removed in upstream commit 4d8340d0d4d9. For 5.4 we'll either need that as well or add them back.

Quoted 8 lines
Quoted 3 lines

Ick, that's a mess.

I'll go drop that patch now, odd that it passed my build tests...

Uh, please no? It fixes a rather nasty UAF when cgroups are in use. Please just add the other upstream commit as well, I confirmed it applies cleanly and fixes the problem.

Alternatively I've appended the version originally sent to the mailing list, with those #ifdefs intact. That's what I had in my tree so far, you could consider it a 5.4 backport. Other than that there's no functional difference to the upstream version.

hth,
Holger

From: Paolo Valente <[email protected]>
To: Jens Axboe <[email protected]>
Cc: [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected], Paolo Valente <[email protected]>
Subject: [PATCH BUGFIX 5/6] block, bfq: get a ref to a group when adding it to a service tree
Date: Fri, 31 Jan 2020 10:24:08 +0100

BFQ schedules generic entities, which may represent either bfq_queues or groups of bfq_queues. When an entity is inserted into a service tree, a reference must be taken, to make sure that the entity does not disappear while still referred in the tree. Unfortunately, such a reference is mistakenly taken only if the entity represents a bfq_queue. This commit takes a reference also in case the entity represents a group.

Tested-by Chris Evich <[email protected]>
Signed-off-by Paolo Valente <[email protected]>
---
 block/bfq-cgroup.c  |  2 +-
 block/bfq-iosched.h |  1 +
 block/bfq-wf2q.c    | 16 +++++++++++++++-
 3 files changed, 17 insertions(+), 2 deletions(-)
block/bfq-cgroup.c +1 -1
index c818c64766e5..f85b25fd06f2 100644
@@ -332,7 +332,7 @@ static void bfqg_put(struct bfq_group *bfqg)
 		kfree(bfqg);
 }
 
-static void bfqg_and_blkg_get(struct bfq_group *bfqg)
+void bfqg_and_blkg_get(struct bfq_group *bfqg)
 {
 	/* see comments in bfq_bic_update_cgroup for why refcounting bfqg */
 	bfqg_get(bfqg);
block/bfq-iosched.h +1 -0
index f1cb89def7f8..b9627ec7007b 100644
@@ -984,6 +984,7 @@ struct bfq_group *bfq_find_set_group(struct bfq_data *bfqd,
 struct blkcg_gq *bfqg_to_blkg(struct bfq_group *bfqg);
 struct bfq_group *bfqq_group(struct bfq_queue *bfqq);
 struct bfq_group *bfq_create_group_hierarchy(struct bfq_data *bfqd, int node);
+void bfqg_and_blkg_get(struct bfq_group *bfqg);
 void bfqg_and_blkg_put(struct bfq_group *bfqg);
 
 #ifdef CONFIG_BFQ_GROUP_IOSCHED
block/bfq-wf2q.c +15 -1
index 26776bdbdf36..ef06e0d34b5b 100644
@@ -533,7 +533,13 @@ static void bfq_get_entity(struct bfq_entity *entity)
 		bfqq->ref++;
 		bfq_log_bfqq(bfqq->bfqd, bfqq, "get_entity: %p %d",
 			     bfqq, bfqq->ref);
+#ifdef CONFIG_BFQ_GROUP_IOSCHED
+	} else
+		bfqg_and_blkg_get(container_of(entity, struct bfq_group,
+					       entity));
+#else
 	}
+#endif
 }
 
 /**

@@ -647,8 +653,16 @@ static void bfq_forget_entity(struct bfq_service_tree *st,
 
 	entity->on_st_or_in_serv = false;
 	st->wsum -= entity->weight;
-	if (bfqq && !is_in_service)
+	if (is_in_service)
+		return;
+
+	if (bfqq)
 		bfq_put_queue(bfqq);
+#ifdef CONFIG_BFQ_GROUP_IOSCHED
+	else
+		bfqg_and_blkg_put(container_of(entity, struct bfq_group,
+					       entity));
+#endif
 }
 
 /**
Signature · 1 line
2.20.1
author maintainer
#173 lore raw
In reply to Holger Hoffstätte
Quoted 19 lines · Holger Hoffstätte
Quoted 18 lines · Greg Kroah-Hartman
Quoted 16 lines · Holger Hoffstätte
Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.25 release.

This fails to compile due to broken patch 001/168:
"block, bfq: get a ref to a group when adding it to a service tree":

..
block/bfq-wf2q.c: In function 'bfq_get_entity':
./include/linux/kernel.h:994:51: error: 'struct bfq_group' has no member named 'entity' ..

The calls to bfq_get_entity::bfqg_and_blkg_get and bfq_forget_entity::bfqg_and_blkg_put in bfq-wf2q.c need to be wrapped in #ifdef CONFIG_BFQ_GROUP_IOSCHED, otherwise the build will fail when CONFIG_BFQ_GROUP_IOSCHED is not enabled.
This horribly error-prone #ifdef mess was finally removed in upstream commit 4d8340d0d4d9. For 5.4 we'll either need that as well or add them back.

Quoted 7 lines
Quoted 3 lines

Ick, that's a mess.

I'll go drop that patch now, odd that it passed my build tests...

Uh, please no? It fixes a rather nasty UAF when cgroups are in use. Please just add the other upstream commit as well, I confirmed it applies cleanly and fixes the problem.

I didn't get that from your email at all, sorry.

So, what commits, and in what order, should be applied to 5.4.y at the moment to resolve this issue?

thanks,

greg k-h

#174 lore raw
Quoted 24 lines · Greg Kroah-Hartman
Quoted 23 lines · Holger Hoffstätte
Quoted 21 lines · Greg Kroah-Hartman
Quoted 11 lines · Holger Hoffstätte
Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.25 release.

This fails to compile due to broken patch 001/168:
"block, bfq: get a ref to a group when adding it to a service tree":

..
block/bfq-wf2q.c: In function 'bfq_get_entity':
./include/linux/kernel.h:994:51: error: 'struct bfq_group' has no member named 'entity' ..

Quoted 5 lines

The calls to bfq_get_entity::bfqg_and_blkg_get and bfq_forget_entity::bfqg_and_blkg_put in bfq-wf2q.c need to be wrapped in #ifdef CONFIG_BFQ_GROUP_IOSCHED, otherwise the build will fail when CONFIG_BFQ_GROUP_IOSCHED is not enabled.
This horribly error-prone #ifdef mess was finally removed in upstream commit 4d8340d0d4d9. For 5.4 we'll either need that as well or add them back.

Ick, that's a mess.

I'll go drop that patch now, odd that it passed my build tests...

Quoted 8 lines
Quoted 3 lines

Uh, please no? It fixes a rather nasty UAF when cgroups are in use. Please just add the other upstream commit as well, I confirmed it applies cleanly and fixes the problem.

I didn't get that from your email at all, sorry.

So, what commits, and in what order, should be applied to 5.4.y at the moment to resolve this issue?

Just add upstream 4d8340d0d4d9 and it should work. Order shouldn't matter (built for me either way) unless you want to follow upstream, in which case it should come before "get a ref to a group..". Easy :)

-h

author maintainer
#175 lore raw
Quoted 29 lines · Holger Hoffstätte
Quoted 28 lines · Greg Kroah-Hartman
Quoted 26 lines · Holger Hoffstätte
Quoted 18 lines · Greg Kroah-Hartman
Quoted 11 lines · Holger Hoffstätte
Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.25 release.

This fails to compile due to broken patch 001/168:
"block, bfq: get a ref to a group when adding it to a service tree":

..
block/bfq-wf2q.c: In function 'bfq_get_entity':
./include/linux/kernel.h:994:51: error: 'struct bfq_group' has no member named 'entity' ..

Quoted 5 lines

The calls to bfq_get_entity::bfqg_and_blkg_get and bfq_forget_entity::bfqg_and_blkg_put in bfq-wf2q.c need to be wrapped in #ifdef CONFIG_BFQ_GROUP_IOSCHED, otherwise the build will fail when CONFIG_BFQ_GROUP_IOSCHED is not enabled.
This horribly error-prone #ifdef mess was finally removed in upstream commit 4d8340d0d4d9. For 5.4 we'll either need that as well or add them back.

Quoted 3 lines

Ick, that's a mess.

I'll go drop that patch now, odd that it passed my build tests...

Uh, please no? It fixes a rather nasty UAF when cgroups are in use. Please just add the other upstream commit as well, I confirmed it applies cleanly and fixes the problem.

Quoted 8 lines
Quoted 4 lines

I didn't get that from your email at all, sorry.

So, what commits, and in what order, should be applied to 5.4.y at the moment to resolve this issue?

Just add upstream 4d8340d0d4d9 and it should work. Order shouldn't matter (built for me either way) unless you want to follow upstream, in which case it should come before "get a ref to a group..". Easy :)

Ok, I've added both back now, and to the 5.5.y tree as well. Hopefully that should resolve these build issues.

thanks,

greg k-h

#176 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.25 release. There are 168 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 Thu, 12 Mar 2020 12:34:10 +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.4.25-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.4.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.

Summary
------------------------------------------------------------------------

kernel: 5.4.25-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 877097a6286abcb4d5eaa7d683640e3a86b7a95c
git describe: v5.4.24-168-g877097a6286a
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.24-168-g877097a6286a

No regressions (compared to build v5.4.24)

No fixes (compared to build v5.4.24)

Ran 26864 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-commands-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-math-tests
* ltp-mm-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* kvm-unit-tests
* ltp-crypto-tests
* ltp-cap_bounds-64k-page_size-tests
* ltp-cap_bounds-kasan-tests
* ltp-commands-64k-page_size-tests
* ltp-commands-kasan-tests
* ltp-containers-64k-page_size-tests
* ltp-containers-kasan-tests
* ltp-cpuhotplug-64k-page_size-tests
* ltp-cpuhotplug-kasan-tests
* ltp-crypto-64k-page_size-tests
* ltp-crypto-kasan-tests
* ltp-cve-64k-page_size-tests
* ltp-cve-kasan-tests
* ltp-dio-64k-page_size-tests
* ltp-dio-kasan-tests
* ltp-fcntl-locktests-64k-page_size-tests
* ltp-fcntl-locktests-kasan-tests
* ltp-filecaps-64k-page_size-tests
* ltp-filecaps-kasan-tests
* ltp-fs-64k-page_size-tests
* ltp-fs-kasan-tests
* ltp-fs_bind-64k-page_size-tests
* ltp-fs_bind-kasan-tests
* ltp-fs_perms_simple-64k-page_size-tests
* ltp-fs_perms_simple-kasan-tests
* ltp-fsx-64k-page_size-tests
* ltp-fsx-kasan-tests
* ltp-hugetlb-64k-page_size-tests
* ltp-hugetlb-kasan-tests
* ltp-io-64k-page_size-tests
* ltp-io-kasan-tests
* ltp-ipc-64k-page_size-tests
* ltp-ipc-kasan-tests
* ltp-math-64k-page_size-tests
* ltp-math-kasan-tests
* ltp-mm-64k-page_size-tests
* ltp-mm-kasan-tests
* ltp-nptl-64k-page_size-tests
* ltp-nptl-kasan-tests
* ltp-pty-64k-page_size-tests
* ltp-pty-kasan-tests
* ltp-sched-64k-page_size-tests
* ltp-sched-kasan-tests
* ltp-securebits-64k-page_size-tests
* ltp-securebits-kasan-tests
* ltp-syscalls-64k-page_size-tests
* ltp-syscalls-compat-tests
* ltp-syscalls-kasan-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

Signature · 2 lines
Linaro LKFT
https://lkft.linaro.org