From: Andrew Morton <akpm@linux-foundation.org>
To: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: JosephChan@via.com.tw, linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix crash in viafb due to 4k stack overflow
Date: Sun, 9 Nov 2008 11:36:03 -0800 [thread overview]
Message-ID: <20081109113603.d45361ad.akpm@linux-foundation.org> (raw)
In-Reply-To: <20081109202537.33ead0a2@neptune.home>
On Sun, 9 Nov 2008 20:25:37 +0100 Bruno Pr__mont <bonbons@linux-vserver.org> wrote:
> The function viafb_cursor() uses 2 stack-variables of CURSOR_SIZE bits;
> CURSOR_SIZE is defined as (8 * 1024). Using up twice 1k on stack is too much
> for 4k-stack (though it works with 8k-stacks).
yup, we should fix that.
> Make those two variables kzalloc'ed to preserve stack space.
>
> Signed-off-by: Bruno Pr__mont <bonbons@linux-vserver.org>
>
> ---
> --- linux-2.6.28-rc3.orig/drviers/video/via/viafbdev.c 2008-11-09 19:22:15.000000000 +0100
^^ typo in pathname?
> +++ linux-2.6.28-rc3/drivers/video/via/viafbdev.c 2008-11-09 19:36:15.000000000 +0100
> @@ -1052,10 +1052,8 @@ static void viafb_imageblit(struct fb_in
>
> static int viafb_cursor(struct fb_info *info, struct fb_cursor *cursor)
> {
> - u8 data[CURSOR_SIZE / 8];
> - u32 data_bak[CURSOR_SIZE / 32];
> u32 temp, xx, yy, bg_col = 0, fg_col = 0;
> - int size, i, j = 0;
> + int i, j = 0;
> static int hw_cursor;
> struct viafb_par *p_viafb_par;
>
> @@ -1178,10 +1176,15 @@ static int viafb_cursor(struct fb_info *
> }
>
> if (cursor->set & FB_CUR_SETSHAPE) {
> - size =
> + u8 *data = kzalloc(CURSOR_SIZE / 8, GFP_KERNEL);
> + u32 *data_bak = kzalloc(CURSOR_SIZE / 32, GFP_KERNEL);
> + int size =
> ((viacursor.image.width + 7) >> 3) *
> viacursor.image.height;
>
> + if (data == NULL || data_bak == NULL)
> + goto out;
> +
> if (MAX_CURS == 32) {
> for (i = 0; i < (CURSOR_SIZE / 32); i++) {
> data_bak[i] = 0x0;
> @@ -1231,6 +1234,9 @@ static int viafb_cursor(struct fb_info *
> memcpy(((struct viafb_par *)(info->par))->fbmem_virt +
> ((struct viafb_par *)(info->par))->cursor_start,
> data_bak, CURSOR_SIZE);
> +out:
> + kfree(data);
> + kfree(data_bak);
> }
>
> if (viacursor.enable)
Is the ->fb_cursor handler allowed to perform GFP_KERNEL memory
allocations? It's never called from atomic contexts?
next prev parent reply other threads:[~2008-11-09 19:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-09 19:25 [PATCH] Fix crash in viafb due to 4k stack overflow Bruno Prémont
2008-11-09 19:36 ` Andrew Morton [this message]
2008-11-09 20:25 ` Arjan van de Ven
2008-11-09 20:38 ` Bruno Prémont
2008-11-09 20:55 ` Andrew Morton
2008-11-09 21:37 ` Bruno Prémont
2008-11-09 22:57 ` Trent Piepho
2008-11-09 22:59 ` Andrew Morton
2008-11-10 21:00 ` Bruno Prémont
2008-11-12 23:01 ` Andrew Morton
2008-11-13 0:58 ` JosephChan
-- strict thread matches above, loose matches on Subject: below --
2008-11-14 8:41 JosephChan
2008-11-14 9:01 ` Bruno Prémont
2008-11-14 10:20 ` JosephChan
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=20081109113603.d45361ad.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=JosephChan@via.com.tw \
--cc=bonbons@linux-vserver.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/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).