All of lore.kernel.org
 help / color / mirror / Atom feed
From: "bhe@redhat.com" <bhe@redhat.com>
To: Jaeseon Sim <jason.sim@samsung.com>
Cc: "urezki@gmail.com" <urezki@gmail.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
Date: Fri, 22 Sep 2023 17:34:46 +0800	[thread overview]
Message-ID: <ZQ1ftk5yDBv+p6A4@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20230922062704epcms1p1722f24d4489a0435b339ce21db754ded@epcms1p1>

Hi Jaeseon,

On 09/22/23 at 03:27pm, Jaeseon Sim wrote:
> There's panic issue as follows when do alloc_vmap_area:
> 
> Kernel panic - not syncing: kernel: panic_on_warn set ...
> 
> page allocation failure: order:0, mode:0x800(GFP_NOWAIT)
> Call Trace:
> warn_alloc+0xf4/0x190
> __alloc_pages_slowpath+0xe0c/0xffc
> __alloc_pages+0x250/0x2d0
> new_slab+0x17c/0x4e0
> ___slab_alloc+0x4e4/0x8a8
> __slab_alloc+0x34/0x6c
> kmem_cache_alloc+0x20c/0x2f0
> adjust_va_to_fit_type
> __alloc_vmap_area
> alloc_vmap_area+0x298/0x7fc
> __get_vm_area_node+0x10c/0x1b4
> __vmalloc_node_range+0x19c/0x7c0
> 
> Commit 1b23ff80b399 ("mm/vmalloc: invoke classify_va_fit_type() in
> adjust_va_to_fit_type()") moved classify_va_fit_type() into
> adjust_va_to_fit_type() and used WARN_ON_ONCE() to handle return
> value of adjust_va_to_fit_type(), just as classify_va_fit_type()
> was handled.

I don't get what you are fixing. In commit 1b23ff80b399, we have
"if (WARN_ON_ONCE(type == NOTHING_FIT))", it's the same as the current
code. You set panic_on_warn, it will panic in old code before commit
1b23ff80b399. Isn't it an expected behaviour?

> 
> There is another path in adjust_va_to_fit_type() which could
> return failure and will be handled in alloc_vmap_area().
> Remove WARN_ON_ONCE() for this case.
> 
> Fixes: 45c62fc2897d ("mm/vmalloc: Remove WARN_ON_ONCE related to adjust_va_to_fit_type")

The commit id for Fixes tag is wrong.

> Signed-off-by: Jaeseon Sim <jason.sim@samsung.com>
> ---
>  mm/vmalloc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index ef8599d394fd..4a82b6525d48 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1522,7 +1522,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 +4143,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;
>  
> -- 
> 2.17.1
> 



  reply	other threads:[~2023-09-22  9:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20230922061715epcms1p7cd5a37f4bba0abf4bc159b844bd8ee65@epcms1p1>
2023-09-22  6:27 ` [PATCH] mm/vmalloc: Remove WARN_ON_ONCE related to adjust_va_to_fit_type Jaeseon Sim
2023-09-22  9:34   ` bhe [this message]
2023-09-22  9:42     ` bhe
2023-09-25 10:51       ` Jaeseon Sim
2023-09-25 13:40         ` Uladzislau Rezki
2023-09-26  5:21           ` Jaeseon Sim
2023-09-26  6:05             ` Uladzislau Rezki
2023-09-26 12:05               ` Jaeseon Sim
2023-09-26 12:35                 ` Uladzislau Rezki
2023-09-27 11:49                   ` Uladzislau Rezki
2023-09-27 13:33                     ` bhe
2023-09-27 15:25                       ` Uladzislau Rezki
2023-09-22 13:41   ` Uladzislau Rezki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZQ1ftk5yDBv+p6A4@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=jaewon31.kim@samsung.com \
    --cc=jason.sim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=urezki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.