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