Messages in this thread Patch in this message | | | Subject | [patch 4/4] Uml: fix __wrap_free comment. | From | blaisorblade_spam@yahoo ... | Date | Fri, 19 Nov 2004 02:13:42 +0100 |
| |
Reworded the comment about __wrap_free detection of the allocator used to allocate the pointer (it can free a pointer created by either the host malloc(), kmalloc() or vmalloc()).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> ---
linux-2.6.10-rc-paolo/arch/um/kernel/main.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-)
diff -puN arch/um/kernel/main.c~uml-wrap_free arch/um/kernel/main.c --- linux-2.6.10-rc/arch/um/kernel/main.c~uml-wrap_free 2004-11-16 02:19:08.289619800 +0100 +++ linux-2.6.10-rc-paolo/arch/um/kernel/main.c 2004-11-16 02:19:08.292619344 +0100 @@ -222,13 +222,16 @@ void __wrap_free(void *ptr) * physical memory - kmalloc/kfree * kernel virtual memory - vmalloc/vfree * anywhere else - malloc/free - * If kmalloc is not yet possible, then the kernel memory regions - * may not be set up yet, and the variables not initialized. So, - * free is called. + * If kmalloc is not yet possible, then either high_physmem and/or + * end_vm are still 0 (as at startup), in which case we call free, or + * we have set them, but anyway addr has not been allocated from those + * areas. So, in both cases __real_free is called. * * CAN_KMALLOC is checked because it would be bad to free a buffer * with kmalloc/vmalloc after they have been turned off during * shutdown. + * XXX: However, we sometimes shutdown CAN_KMALLOC temporarily, so + * there is a possibility for memory leaks. */ if((addr >= uml_physmem) && (addr < high_physmem)){ _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |