-----Original Message----- From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi-owner@xxxxxxxxxxxxxxx] On Behalf Of Nick Piggin Sent: Sunday, January 04, 2009 11:15 PM To: Len Brown Cc: Christoph Hellwig; Alexey Starikovskiy; Pekka Enberg; Linux Memory Management List; linux-acpi@xxxxxxxxxxxxxxx Subject: Re: [patch][rfc] acpi: do not use kmem caches > > I think they are here to stay. We are running > > an interpreter in kernel-space with arbitrary input, > > so I think the ability to easily isolate run-time memory leaks > > on a non-debug system is important. > I don't really see the connection. Or why being an interpreter is so > special. Filesystems, network stack, etc run in kernel with arbitrary > input. If kmem caches are part of a security strategy, then it's > broken... You'd surely have to detect bad input before the interpreter > turns it into a memory leak (or recover afterward, in which case it > isn't a leak). I think that the purposes of these was to act as a debugging aid, for example, if there were BIOS-supplied AML that was triggering a leak. The point being here that a network card driver has a much more well-defined set of what can happen than a fully pluggable interpreter for third party code. [Of course, this is just my interpretation from following the discussion; I'm not otherwise involved.] - S -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
