linux-kernel - Re: [PATCH] replace BUG_ON to WARN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 28 Jan 2023 00:03:19 +0900
From:   Hyeonggon Yoo <42.hyeyoo@...il.com>
To:     Hyunmin Lee <hn.min.lee@...il.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Uladzislau Rezki <urezki@...il.com>,
        Christoph Hellwig <hch@...radead.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] replace BUG_ON to WARN_ON

Hello Hyunmin.

the subject line could be "mm/vmalloc: replace BUG_ON() with WARN_ON()".

On Fri, Jan 27, 2023 at 08:58:44PM +0900, Hyunmin Lee wrote:
> Replace unnacessary BUG_ON to WARN_ON. These BUG_ONs verify aruguments of a function. Thus, the WARN_ONs return an EINVAL error when their condition is true.
> 
> Co-Developed-by: Gwan-gyeong Mun <gwan-gyeong.mun@...el.com>
> Co-Developed-by: Jeungwoo Yoo <casionwoo@...il.com>
> Co-Developed-by: Sangyun Kim <sangyun.kim@....ac.kr>
> Signed-off-by: Hyunmin Lee <hn.min.lee@...il.com>
> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@...el.com>
> Signed-off-by: Jeungwoo Yoo <casionwoo@...il.com>
> Signed-off-by: Sangyun Kim <sangyun.kim@....ac.kr>
> Cc: Hyeonggon Yoo <42.hyeyoo@...il.com>

could be rephrased a little, like:

"As per the coding standards, in the event of an abnormal condition that
should not occur under normal circumstances, the kernel should attempt
recovery and proceed with execution, rather than halting the machine.

Specifically, in the alloc_vmap_area() function, use WARN_ON()
and fail the request instead of using BUG_ON() to halt the machine."

> ---
>  mm/vmalloc.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 74afa2208558..9f9dba3132c5 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1587,9 +1587,14 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
>  	int purged = 0;
>  	int ret;
>  
> -	BUG_ON(!size);
> -	BUG_ON(offset_in_page(size));
> -	BUG_ON(!is_power_of_2(align));
> +	if (WARN_ON(!size))
> +		return ERR_PTR(-EINVAL);
> +
> +	if (WARN_ON(offset_in_page(size)))
> +		return ERR_PTR(-EINVAL);
> +
> +	if (WARN_ON(!is_power_of_2(align)))
> +		return ERR_PTR(-EINVAL);
>  
>  	if (unlikely(!vmap_initialized))
>  		return ERR_PTR(-EBUSY);
> -- 
> 2.25.1

The code change itself looks fine to me.

Even if BUG*() -> WARN*() conversion may not be a high priority task,
I see no reason to reject such changes.

--
Thanks,
Hyeonggon