Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 28 Jun 2022 08:09:06 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Duoming Zhou <duoming@zju.edu.cn>
Cc:     linux-kernel@vger.kernel.org, rafael@kernel.org,
        johannes@sipsolutions.net
Subject: Re: [PATCH v7] devcoredump: change gfp_t parameter of kzalloc to
 GFP_KERNEL
Message-ID: <YrqbAgM6aR8OKpZj@kroah.com>
References: <20220628034458.17384-1-duoming@zju.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220628034458.17384-1-duoming@zju.edu.cn>
Precedence: bulk

On Tue, Jun 28, 2022 at 11:44:58AM +0800, Duoming Zhou wrote:
> The dev_coredumpv() and dev_coredumpm() could not be used in atomic
> context, because they call kvasprintf_const() and kstrdup() with
> GFP_KERNEL parameter. The process is shown below:
> 
> dev_coredumpv(.., gfp_t gfp)
>   dev_coredumpm(.., gfp_t gfp)
>     kzalloc(.., gfp);
>     dev_set_name
>       kobject_set_name_vargs
>         kvasprintf_const(GFP_KERNEL, ...); //may sleep
>           kstrdup(s, GFP_KERNEL); //may sleep
> 
> This patch changes the gfp_t parameter of kzalloc() in dev_coredumpm() to
> GFP_KERNEL in order to show they could not be used in atomic context.
> 
> What's more, this patch does not remove the gfp_t parameter in
> dev_coredumpv() and dev_coredumpm() in order that it will not influence
> other new users that are added in other trees.
> 
> Fixes: 833c95456a70 ("device coredump: add new device coredump class")
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> ---
> Changes in v7:
>   - change gfp_t parameter of kzalloc in dev_coredumpm() to GFP_KERNEL.
> 
>  drivers/base/devcoredump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c
> index f4d794d6bb8..cf60aacf8a8 100644
> --- a/drivers/base/devcoredump.c
> +++ b/drivers/base/devcoredump.c
> @@ -268,7 +268,7 @@ void dev_coredumpm(struct device *dev, struct module *owner,
>  	if (!try_module_get(owner))
>  		goto free;
>  
> -	devcd = kzalloc(sizeof(*devcd), gfp);
> +	devcd = kzalloc(sizeof(*devcd), GFP_KERNEL);

No, you can't just ignore the flag entirely, that doesn't help anyone
out who tries to set it and is totally confused as to why the field is
ignored.

You need to evolve the function over time to not need the parameter at
all, this just papers over the entire issue, which makes the api lie to
the caller, not something you ever want to do.

thanks,

greg k-h