rtas_call uses kmalloc before the memory subsystem is up
Linas Vepstas
linas at austin.ibm.com
Wed Aug 18 05:52:48 EST 2004
Hi,
Yes, Jake Moilanen reported this a month ago; a patch for this went
out on 13 July; it was followed by a discussion with the email subject
"RFC: Fix (another) bug in rtas logging".
Is there a reason that patch was never sent upstream?
(This is why I think having a bug tracker would be nice ...
so we could see what the status of this stuff really is).
(I just got back from vacation and have a backlog of 550 unread emails
so far ...)
--linas
On Mon, Aug 16, 2004 at 03:18:19PM +1000, Paul Mackerras was heard to remark:
> Anton Blanchard writes:
>
> > rtas_call is doing a kmalloc before the memory subsystem is up, but only
> > when we hit an error.
>
> This is a quick-n-dirty hack to fix the problem. It's not completely
> obvious what the proper solution looks like, unfortunately.
>
> Paul.
>
> diff -urN linux-2.5/arch/ppc64/kernel/rtas.c test25/arch/ppc64/kernel/rtas.c
> --- linux-2.5/arch/ppc64/kernel/rtas.c 2004-08-03 08:07:43.000000000 +1000
> +++ test25/arch/ppc64/kernel/rtas.c 2004-08-16 14:47:22.147162600 +1000
> @@ -165,9 +165,12 @@
>
> /* Log the error in the unlikely case that there was one. */
> if (unlikely(logit)) {
> - buff_copy = kmalloc(RTAS_ERROR_LOG_MAX, GFP_ATOMIC);
> - if (buff_copy) {
> - memcpy(buff_copy, rtas_err_buf, RTAS_ERROR_LOG_MAX);
> + buff_copy = rtas_err_buf;
> + if (mem_init_done) {
> + buff_copy = kmalloc(RTAS_ERROR_LOG_MAX, GFP_ATOMIC);
> + if (buff_copy)
> + memcpy(buff_copy, rtas_err_buf,
> + RTAS_ERROR_LOG_MAX);
> }
> }
>
> @@ -176,7 +179,8 @@
>
> if (buff_copy) {
> log_error(buff_copy, ERR_TYPE_RTAS_LOG, 0);
> - kfree(buff_copy);
> + if (mem_init_done)
> + kfree(buff_copy);
> }
> return ret;
> }
>
** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc64-dev
mailing list