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