increase kmemleak robustness at boot
in [Kernel]
|
Prev: [PATCH 03/10] sh: dma: check return value of create_proc_read_entry()
Next: [PATCH 04/10] x86: mce: fix error handling
From: Pekka Enberg on 28 Jul 2010 12:50 Daniel J Blueman wrote: > 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, Is it just potential leaks that we lose or can this cause false positives? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel J Blueman on 28 Jul 2010 14:40 On 28 July 2010 17:49, Pekka Enberg <penberg(a)cs.helsinki.fi> wrote: > Daniel J Blueman wrote: >> >> 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, > > Is it just potential leaks that we lose or can this cause false positives? I don't get any false positives having had the buffer wrap a number of times at early-boot; not to say this can't cause any. It seems that some kernel debug options are doing heavy early-boot allocations, so getting any false-positives would likely be a triple edge case. Thanks, Daniel -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Catalin Marinas on 29 Jul 2010 07:40 On 28 July 2010 17:49, Pekka Enberg <penberg(a)cs.helsinki.fi> wrote: > Daniel J Blueman wrote: >> >> 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, > > Is it just potential leaks that we lose or can this cause false positives? I wouldn't go this route, it's a great source of false positives. Given that it's not always easy to investigate a memory leak, adding more false positives would just make people turn the tool off. There are several things in place like crc checking and maybe that's why Daniel doesn't get false positives but that's not always the case. I would rather change the static early alloc buffer with something like bootmem allocation (the recursiveness should be bound, kmemleak tracks bootmem allocations as well). But I'm on holiday until middle of August and not able to do any tests in this area. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel J Blueman on 29 Jul 2010 08:50 On 29 July 2010 12:34, Catalin Marinas <catalin.marinas(a)gmail.com> wrote: > On 28 July 2010 17:49, Pekka Enberg <penberg(a)cs.helsinki.fi> wrote: >> Daniel J Blueman wrote: >>> >>> 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, >> >> Is it just potential leaks that we lose or can this cause false positives? > > I wouldn't go this route, it's a great source of false positives. > Given that it's not always easy to investigate a memory leak, adding > more false positives would just make people turn the tool off. There > are several things in place like crc checking and maybe that's why > Daniel doesn't get false positives but that's not always the case. > > I would rather change the static early alloc buffer with something > like bootmem allocation (the recursiveness should be bound, kmemleak > tracks bootmem allocations as well). But I'm on holiday until middle > of August and not able to do any tests in this area. Indeed, moving to dynamic early allocation is all the more better. For now, I'll increase the early allocation to 15200 elements, as the 400-entry buffer wraps 38. Thanks again, Daniel -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 29 Jul 2010 11:20
Daniel J Blueman wrote: >> I would rather change the static early alloc buffer with something >> like bootmem allocation (the recursiveness should be bound, kmemleak >> tracks bootmem allocations as well). But I'm on holiday until middle >> of August and not able to do any tests in this area. > > Indeed, moving to dynamic early allocation is all the more better. For > now, I'll increase the early allocation to 15200 elements, as the > 400-entry buffer wraps 38. If it's just kmemleak_init() we're talking about, slab caches are up at that point so you can just use kmalloc(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |