Re: [PATCH] mm/vmalloc: Remove WARN_ON_ONCE related to adjust_va_to_fit_type

[Jaeseon Sim]

> > > We do not have above code anymore:
> > Sorry, I tried to say it in a simplified way and it caused a misunderstanding.
> > 
> > <snip>
> > static __always_inline int
> > adjust_va_to_fit_type(struct rb_root *root, struct list_head *head,
> > 		      struct vmap_area *va, unsigned long nva_start_addr,
> > 		      unsigned long size)
> > 
> > 	} else if (type == NE_FIT_TYPE) {
> > 		/*
> > 		 * Split no edge of fit VA.
> > 		 *
> > 		 *     |       |
> > 		 *   L V  NVA  V R
> > 		 * |---|-------|---|
> > 		 */
> > 		lva = __this_cpu_xchg(ne_fit_preload_node, NULL);
> > 		if (unlikely(!lva)) {
> > 			/*
> > 			 * For percpu allocator we do not do any pre-allocation
> > 			 * and leave it as it is. The reason is it most likely
> > 			 * never ends up with NE_FIT_TYPE splitting. In case of
> > 			 * percpu allocations offsets and sizes are aligned to
> > 			 * fixed align request, i.e. RE_FIT_TYPE and FL_FIT_TYPE
> > 			 * are its main fitting cases.
> > 			 *
> > 			 * There are a few exceptions though, as an example it is
> > 			 * a first allocation (early boot up) when we have "one"
> > 			 * big free space that has to be split.
> > 			 *
> > 			 * Also we can hit this path in case of regular "vmap"
> > 			 * allocations, if "this" current CPU was not preloaded.
> > 			 * See the comment in alloc_vmap_area() why. If so, then
> > 			 * GFP_NOWAIT is used instead to get an extra object for
> > 			 * split purpose. That is rare and most time does not
> > 			 * occur.
> > 			 *
> > 			 * What happens if an allocation gets failed. Basically,
> > 			 * an "overflow" path is triggered to purge lazily freed
> > 			 * areas to free some memory, then, the "retry" path is
> > 			 * triggered to repeat one more time. See more details
> > 			 * in alloc_vmap_area() function.
> > 			 */
> > 			lva = kmem_cache_alloc(vmap_area_cachep, GFP_NOWAIT);
> > 			if (!lva)
> > 				return -1;
> > 		}
> > <snip>
> > 
> > Above allocation fail will meet WARN_ON_ONCE in the current kernel now.
> > Should It be handled by alloc_vmap_area()?, as you described in a comment.
> > 
> WARN_ONCE_ONCE() is a warning and not a panic, though your kernel config
> considers it as a panic. Right, we go on retry path and we can remove

Right, only in case panic_on_warn is enabled..

> the warning only for GFP_NOWAIT-alloc-error. From the other hand we
> should still have possibility to trigger a warning if an allocation
> is not successful: no vmap space or low memory condition, thus no
> physical memory.

Yes, but GFP_NOWAIT-alloc-error can easily occur for low-memory device.
How about changing fix as below?:

<snip>
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1468,6 +1468,7 @@ adjust_va_to_fit_type(struct rb_root *root, struct list_head *head,
                 */
                va->va_start = nva_start_addr + size;
        } else {
+               WARN_ON_ONCE(1);
                return -1;
        }
 
@@ -1522,7 +1523,7 @@ __alloc_vmap_area(struct rb_root *root, struct list_head *head,
 
        /* Update the free vmap_area. */
        ret = adjust_va_to_fit_type(root, head, va, nva_start_addr, size);
-       if (WARN_ON_ONCE(ret))
+       if (ret)
                return vend;
 
 #if DEBUG_AUGMENT_LOWEST_MATCH_CHECK
@@ -4143,7 +4144,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
                ret = adjust_va_to_fit_type(&free_vmap_area_root,
                                            &free_vmap_area_list,
                                            va, start, size);
-               if (WARN_ON_ONCE(unlikely(ret)))
+               if (unlikely(ret))
                        /* It is a BUG(), but trigger recovery instead. */
                        goto recovery;
 
<snip>
It will WARN_ONCE_ONCE() only if classify_va_fit_type() is "(type == NOTHING_FIT)".

> 
> > 
> > > 
> > > <snip>
> > > commit 82dd23e84be3ead53b6d584d836f51852d1096e6
> > > Author: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx>
> > > Date:   Thu Jul 11 20:58:57 2019 -0700
> > > 
> > >     mm/vmalloc.c: preload a CPU with one object for split purpose
> > > 
> > > <snip>
> > > 
> > > Which kernel are you testing?
> > 
> > I'm currently testing v6.1. 
> > The panic occurred during power on/off test.
> >
> Could you please describe in more detail your test sequence, setup and HW?

I'm testing on Samsung Exynos arm64 board with aosp platform, kernel v6.1.
I did power on/off test on hundreds of device for a week and
the same issue reproduced several times.

Thanks
Jaeseon

> 
> --
> Uladzislau Rezki