On Mon, Dec 21, 2020 at 07:47:44PM +0800, zhangqiumi...@huwei.com wrote:
> From: zhangqiumiao <zhangqiumi...@huawei.com>
>
> Add a check for NULL in con_init in order to make sure kzalloc succeeds.
>
> Signed-off-by: zhangqiumiao <zhangqiumi...@huawei.com>
> ---
> drivers/tty/vt/vt.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index d04a162939a4..916f3370a136 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3486,11 +3486,15 @@ static int __init con_init(void)
>
> for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
> vc_cons[currcons].d = vc = kzalloc(sizeof(struct vc_data),
> GFP_NOWAIT);
> + if (!vc)
> + return -ENOMEM;
> INIT_WORK(&vc_cons[currcons].SAK_work, vc_SAK);
> tty_port_init(&vc->port);
> visual_init(vc, currcons, 1);
> /* Assuming vc->vc_{cols,rows,screenbuf_size} are sane here. */
> vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_NOWAIT);
> + if (!vc->vc_screenbuf)
> + return -ENOMEM;
Did you try to see what happens if you ever trigger this?
Did you trigger this in real-world situations?
Have you read the old email threads about where people tried to "fix"
this and the problems that ended up happening? If not, please do so...
Hint, I can not take this as you will NEVER hit this in a real system.
thanks,
greg k-h
