RFC: Fix (another) bug in rtas logging

David Gibson david at gibson.dropbear.id.au
Fri Jul 16 16:13:27 EST 2004


Have I missed anything here?  This bug certainly fixes the crash on
boot I've been getting on our p630.

The recent patch changing the rtas error logging had a bug.  It can
result in rtas_call() attempting to call kmalloc() too early (from
setup_arch() before the slab caches are initialized), leading to an
oops on boot.

I can see no reason that log_error() can't be called with the
rtas.lock still held, so this patch avoids race addresses by the
original race by simply moving the log_error() call under the lock.

Signed-off-by: David Gibson <dwg at au.ibm.com>

Index: working-2.6/arch/ppc64/kernel/rtas.c
===================================================================
--- working-2.6.orig/arch/ppc64/kernel/rtas.c
+++ working-2.6/arch/ppc64/kernel/rtas.c
@@ -114,7 +114,6 @@
 	int i, logit = 0;
 	unsigned long s;
 	struct rtas_args *rtas_args;
-	char * buff_copy = NULL;
 	int ret;

 	PPCDBG(PPCDBG_RTAS, "Entering rtas_call\n");
@@ -165,19 +164,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);
-		}
+		log_error(rtas_err_buf, ERR_TYPE_RTAS_LOG, 0);
 	}

 	/* Gotta do something different here, use global lock for now... */
 	spin_unlock_irqrestore(&rtas.lock, s);

-	if (buff_copy) {
-		log_error(buff_copy, ERR_TYPE_RTAS_LOG, 0);
-		kfree(buff_copy);
-	}
 	return ret;
 }



--
David Gibson			| For every complex problem there is a
david AT gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/





More information about the Linuxppc64-dev mailing list