Messages in this thread Patch in this message | | | Date | Wed, 28 Jul 2010 17:40:52 +0100 | Subject | [2.6.35-rc6 patch] increase kmemleak robustness at boot | From | Daniel J Blueman <> |
| |
Hi Catalin,
I've consistently been experiencing kmemleak exhaust it's 400-entry early-boot buffer and disabling itself; there have been reports of this also, and I'm finding this on x86-64 with various debug options enabled.
If we issue a warning and allow the buffer to wrap, we don't need to hit the kill-switch. While we lose track of some early potential leaks, it's better than no functionality.
Let me know if it's acceptable, and many thanks for such an excellent tool, Daniel
---
Allow the early-boot buffer to wrap, rather than disabling kmemleak and losing the functionality.
diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 2c0d032..93bf8a3 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -786,13 +786,6 @@ static void __init log_early(int op_type, const void *ptr, size_t size, unsigned long flags; struct early_log *log;
- if (crt_early_log >= ARRAY_SIZE(early_log)) { - pr_warning("Early log buffer exceeded, " - "please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE\n"); - kmemleak_disable(); - return; - } - /* * There is no need for locking since the kernel is still in UP mode * at this stage. Disabling the IRQs is enough. @@ -805,7 +798,13 @@ static void __init log_early(int op_type, const void *ptr, size_t size, log->min_count = min_count; if (op_type == KMEMLEAK_ALLOC) log->trace_len = __save_stack_trace(log->trace); + crt_early_log++; + if (crt_early_log >= ARRAY_SIZE(early_log)) { + pr_warning("Early log buffer exhausted - wrapping\n"); + crt_early_log = 0; + } + local_irq_restore(flags); }
-- Daniel J Blueman
| |