Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
From:   Uladzislau Rezki <urezki@gmail.com>
Date:   Tue, 26 Sep 2023 14:35:21 +0200
To:     Jaeseon Sim <jason.sim@samsung.com>
Cc:     Uladzislau Rezki <urezki@gmail.com>,
        "bhe@redhat.com" <bhe@redhat.com>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "hch@infradead.org" <hch@infradead.org>,
        "lstoakes@gmail.com" <lstoakes@gmail.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Jaewon Kim <jaewon31.kim@samsung.com>
Subject: Re: [PATCH] mm/vmalloc: Remove WARN_ON_ONCE related to
 adjust_va_to_fit_type
Message-ID: <ZRLQCTh9zNIp9OH7@pc636>
References: <ZRJ0wtzu+ZD7ALqs@pc636>
 <ZRGN0DkJ/MHsYloz@pc636>
 <ZQ1ha+wIaTJ9+aU8@MiWiFi-R3L-srv>
 <20230922062704epcms1p1722f24d4489a0435b339ce21db754ded@epcms1p1>
 <ZQ1ftk5yDBv+p6A4@MiWiFi-R3L-srv>
 <20230925105154epcms1p782c335c2355f39a9b583489c56e972f6@epcms1p7>
 <20230926052158epcms1p7fd7f3e3f523e5209977d3f5c62e85afa@epcms1p7>
 <CGME20230922061715epcms1p7cd5a37f4bba0abf4bc159b844bd8ee65@epcms1p4>
 <20230926120549epcms1p4d41733c1c3698bd00eaa7e5ea0de041d@epcms1p4>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230926120549epcms1p4d41733c1c3698bd00eaa7e5ea0de041d@epcms1p4>
Precedence: bulk

On Tue, Sep 26, 2023 at 09:05:49PM +0900, Jaeseon Sim wrote:
> > > > 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.
>
Agree. You are really in a low memory condition. We end up here only if
pre-loading also has not succeeded, i.e. GFP_KERNEL also fails.

But i agree with you, we should "improve the warning" because we drain
and repeat.

> 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)".
> 
This is good but i think it should be improved further. We need to
understand from the warning when no memory and when there is no a
vmap space, so:

- if NOTHING_FIT, we should WARN() for sure;
- Second place in the pcpu_get_vm_area(), we do not use NE_FIT. Only in
  the begging after boot, but potentially we can trigger -ENOMEM and we
  should warn in this case. Otherwise you just hide it;
- And last one if after repeating we still do not manage to allocate.

--
Uladzislau Rezki