On Fri, Mar 31, 2017 at 1:00 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Thu 30-03-17 23:49:52, Joel Fernandes wrote: >> Hi Michal, >> >> On Wed, Mar 29, 2017 at 3:43 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: >> > On Wed 29-03-17 09:23:32, Vaneet Narang wrote: >> >> Hi, >> >> >> >> >> Hmm, how can you track _all_ vmalloc allocations done on behalf of the >> >> >> module? It is quite some time since I've checked kernel/module.c but >> >> >> from my vague understading your check is basically only about statically >> >> >> vmalloced areas by module loader. Is that correct? If yes then is this >> >> >> actually useful? Were there any bugs in the loader code recently? What >> >> >> led you to prepare this patch? All this should be part of the changelog! >> >> >> >> First of all there is no issue in kernel/module.c. This patch add functionality >> >> to detect scenario where some kernel module does some memory allocation but gets >> >> unloaded without doing vfree. For example >> >> static int kernel_init(void) >> >> { >> >> char * ptr = vmalloc(400 * 1024); >> >> return 0; >> >> } >> > >> > How can you track that allocation back to the module? Does this patch >> > actually works at all? Also why would be vmalloc more important than >> > kmalloc allocations? >> >> Doesn't the patch use caller's (in this case, the module is the >> caller) text address for tracking this? vma->vm->caller should track >> the caller doing the allocation? > > Not really. First of all it will be vmalloc() to be tracked in the above > the example because vmalloc is not inlined. And secondly even if the vmalloc is not inlined, but __built_in_address(0) will return the *return address* of vmalloc: >From https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Return-Address.html : "The level argument is number of frames to scan up the call stack. A value of 0 yields the return address of the current function" > caller of the vmalloc was tracked then it would be hopelessly > insufficient because you would get coverage of the _direct_ module usage > of vmalloc rather than anything that the module triggered and that is > outside of the module. Which means any library function etc... Yes true, but I think the check is for direct allocations, done by the module, not indirect ones... it may not be a catch-all issues type of deal but is still IMO a good check since we already have va->vm->caller available. Thanks, Joel -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>