Skip to contentSkip to conversation

Fix ext4 xfstests failure

PATCH In review Rishabh Bhatnagar 2 participants 3 messages Jan 31, 2023 – Feb 3, 2023

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover Fix ext4 xfstests failure

While running xfstests on 4.14.304 version we see a warning being generated in one of ext4 tests with the following stack trace.

WARNING: CPU: 4 PID: 15332 at mm/util.c:414
kvmalloc_node+0x67/0x70
ext4_expand_extra_isize_ea+0x2b4/0x870 [ext4]
__ext4_expand_extra_isize+0xcb/0x120 [ext4]
ext4_mark_inode_dirty+0x1a5/0x1d0 [ext4]
ext4_ext_truncate+0x1f/0x90 [ext4]
ext4_truncate+0x363/0x400 [ext4]
ext4_setattr+0x392/0xa00 [ext4]
notify_change+0x300/0x420
? ext4_xattr_security_set+0x20/0x20 [ext4]
do_truncate+0x75/0xc0
? ext4_release_file+0xa0/0xa0 [ext4]
path_openat+0x737/0x16f0
do_filp_open+0x9b/0x110
? __check_object_size+0xb4/0x190
? do_sys_open+0x1bd/0x250
do_sys_open+0x1bd/0x250
do_syscall_64+0x67/0x110
entry_SYSCALL_64_after_hwframe+0x59/0xbe

It seems rebase to 4.14.304 brings a bunch of ext4 changes. Commit ext4: allocate extended attribute value in vmalloc area (73c44f61dab180b5f2dee9f15397aba36a75a882) tries to allocate buffer using kvmalloc with improper flags that generates this warning. To fix backport an upstream commit mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags (170f26afa0481c72af93aa61b7398b5663451651). This removes the WARN_ON and fallsback to kmalloc if correct flags are not passed.

Michal Hocko (1):
mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags

 mm/util.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
Signature · 1 line
2.38.1
#1 lore raw

PATCH 1/1 mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags

From: Michal Hocko <[email protected]>

Commit ce91f6ee5b3bbbad8caff61b1c46d845c8db19bf upstream.

kvmalloc warned about incompatible gfp_mask to catch abusers (mostly GFP_NOFS) with an intention that this will motivate authors of the code to fix those. Linus argues that this just motivates people to do even more hacks like

	if (gfp == GFP_KERNEL)
		kvmalloc
	else
		kmalloc

I haven't seen this happening much (Linus pointed to bucket_lock special cases an atomic allocation but my git foo hasn't found much more) but it is true that we can grow those in future. Therefore Linus suggested to simply not fallback to vmalloc for incompatible gfp flags and rather stick with the kmalloc path.

---
Changelog:
- Removed lib/bucket_locks.c diff as not present in 4.14

 mm/util.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
mm/util.c +4 -2
index 84e775f5216f..7d80c8119dce 100644
@@ -400,7 +400,8 @@ EXPORT_SYMBOL(vm_mmap);
  * __GFP_RETRY_MAYFAIL is supported, and it should be used only if kmalloc is
  * preferable to the vmalloc fallback, due to visible performance drawbacks.
  *
- * Any use of gfp flags outside of GFP_KERNEL should be consulted with mm people.
+ * Please note that any use of gfp flags outside of GFP_KERNEL is careful to not
+ * fall back to vmalloc.
  */
 void *kvmalloc_node(size_t size, gfp_t flags, int node)
 {
@@ -411,7 +412,8 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
 	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
 	 * so the given set of flags has to be compatible.
 	 */
-	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
+	if ((flags & GFP_KERNEL) != GFP_KERNEL)
+		return kmalloc_node(size, flags, node);
 
 	/*
 	 * We want to attempt a large physically contiguous block first because
Signature · 1 line
2.38.1
maintainer
#2 lore raw
In reply to Rishabh Bhatnagar
Quoted 33 lines · Rishabh Bhatnagar

While running xfstests on 4.14.304 version we see a warning being generated in one of ext4 tests with the following stack trace.

WARNING: CPU: 4 PID: 15332 at mm/util.c:414
kvmalloc_node+0x67/0x70
ext4_expand_extra_isize_ea+0x2b4/0x870 [ext4]
__ext4_expand_extra_isize+0xcb/0x120 [ext4]
ext4_mark_inode_dirty+0x1a5/0x1d0 [ext4]
ext4_ext_truncate+0x1f/0x90 [ext4]
ext4_truncate+0x363/0x400 [ext4]
ext4_setattr+0x392/0xa00 [ext4]
notify_change+0x300/0x420
? ext4_xattr_security_set+0x20/0x20 [ext4]
do_truncate+0x75/0xc0
? ext4_release_file+0xa0/0xa0 [ext4]
path_openat+0x737/0x16f0
do_filp_open+0x9b/0x110
? __check_object_size+0xb4/0x190
? do_sys_open+0x1bd/0x250
do_sys_open+0x1bd/0x250
do_syscall_64+0x67/0x110
entry_SYSCALL_64_after_hwframe+0x59/0xbe

It seems rebase to 4.14.304 brings a bunch of ext4 changes. Commit ext4: allocate extended attribute value in vmalloc area (73c44f61dab180b5f2dee9f15397aba36a75a882) tries to allocate buffer using kvmalloc with improper flags that generates this warning. To fix backport an upstream commit mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags (170f26afa0481c72af93aa61b7398b5663451651). This removes the WARN_ON and fallsback to kmalloc if correct flags are not passed.

Quoted 9 lines

Michal Hocko (1):
mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags

 mm/util.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
Signature · 1 line
2.38.1

Now queued up, thanks.

greg k-h