From: Sam Ravnborg <sam@ravnborg.org>
To: Nicolas Pitre <nico@fluxnic.net>, Greg KH <gregkh@linuxfoundation.org>
Cc: gregkh@linuxfoundation.org, Adam Borowski <kilobyte@angband.pl>,
Chen Wandun <chenwandun@huawei.com>,
jslaby@suse.com, daniel.vetter@ffwll.ch,
b.zolnierkie@samsung.com, lukas@wunner.de, ghalat@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vt: don't hardcode the mem allocation upper bound
Date: Fri, 17 Apr 2020 16:49:15 +0200 [thread overview]
Message-ID: <20200417144915.GA25595@ravnborg.org> (raw)
In-Reply-To: <nycvar.YSQ.7.76.2003281702410.2671@knanqh.ubzr>
Hi Greg.
I assume you will take this patch.
Not really drm-misc material.
Sam
On Sat, Mar 28, 2020 at 05:32:42PM -0400, Nicolas Pitre wrote:
> The code in vc_do_resize() bounds the memory allocation size to avoid
> exceeding MAX_ORDER down the kzalloc() call chain and generating a
> runtime warning triggerable from user space. However, not only is it
> unwise to use a literal value here, but MAX_ORDER may also be
> configurable based on CONFIG_FORCE_MAX_ZONEORDER.
> Let's use KMALLOC_MAX_SIZE instead.
>
> Note that prior commit bb1107f7c605 ("mm, slab: make sure that
> KMALLOC_MAX_SIZE will fit into MAX_ORDER") the KMALLOC_MAX_SIZE value
> could not be relied upon.
>
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> Cc: <stable@vger.kernel.org> # v4.10+
>
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 15d2769805..37c5f21490 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -1193,7 +1193,7 @@ static int vc_do_resize(struct tty_struct *tty, struct vc_data *vc,
> if (new_cols == vc->vc_cols && new_rows == vc->vc_rows)
> return 0;
>
> - if (new_screen_size > (4 << 20))
> + if (new_screen_size > KMALLOC_MAX_SIZE)
> return -EINVAL;
> newscreen = kzalloc(new_screen_size, GFP_USER);
> if (!newscreen)
next prev parent reply other threads:[~2020-04-17 14:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-28 21:32 [PATCH] vt: don't hardcode the mem allocation upper bound Nicolas Pitre
2020-04-17 14:49 ` Sam Ravnborg [this message]
2020-04-23 13:44 ` Greg KH
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=20200417144915.GA25595@ravnborg.org \
--to=sam@ravnborg.org \
--cc=b.zolnierkie@samsung.com \
--cc=chenwandun@huawei.com \
--cc=daniel.vetter@ffwll.ch \
--cc=ghalat@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=kilobyte@angband.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=nico@fluxnic.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).