On 2013年04月16日 18:38, Chen Gang wrote: > On 2013年04月16日 18:25, Chen Gang wrote: >> On 2013年04月12日 17:42, Chen Gang wrote: >>> On 2013年04月11日 12:10, Chen Gang wrote: >>>> On 2013年04月11日 05:19, Eric Paris wrote: >>>>> ----- Original Message ----- >>>>> >>>>>>> b. has an new issue for AUDIT_DIR: >>>>>>> after AUDIT_DIR succeed, it will set rule->tree. >>>>>>> next, the other case fail, then will call audit_free_rule. >>>>>>> but audit_free_rule will not free rule->tree. >>>>> Definitely a couple of leaks here... >>>>> >>>>> I'm seeing leaks on size 8, 64, and 128. >>>>> >>>>> Al, what do you think? Should I be calling audit_put_tree() in the error >>>>> case if entry->tree != NULL? The audit trees are some of the most >>>>> complex code in the kernel I think. >>>>> >>>>>
after the test, the original version really has memory leak. test: the related monitor command is: watch -d -n 1 "cat /proc/meminfo | awk '{print \$2}' \ | head -n 4 | xargs \ | awk '{print \"used \",\$1 - \$2 - \$3 - \$4}'" I run 15 processes of modified auditctl at the same time. result: for original version: can see the memory leak, it will be more clear after 1 - 2 hours. for new version (fix it): can not see the memory leak after ran 12 - 14 hours. I will use LTP (ltp-full-20130109) to test audit again under fedora 17 x86_64 for next-20130415, then send related patch. welcome any suggestions or completions. > > oh, also need buffering optarg of auditctl under fedora 17. > or "-F auid=-1" will be truncated to "-F auid". > it is ok if not looping again. but in our case, we need loop again. > > to see memory usage, I think: > in top, really used memory = 'used' - 'cached' > it is enough for us. > > welcome any suggestions or completions. > > thanks. > > >> >> I am just testing about it with: >> >> --- >> while(1) >> auditctl -a exit,always -w /etc -F auid=-1 >> --- >> >> under fedora 17, we need modify the auditctl source code: >> a. let -w /etc can pass auditctl checking. >> b. let loop infinitely in a process (if process quit, will free mem) >> c. need fix a bug for auditctl (under Fedora 17) >> audit_open may open 2 times. >> when loop infinitely, it will cause resource handle leak. >> >> I have checked (by insert printf in kernel/auditfilter.c): >> after modify the auditct, the work flow is just what we want to be. >> (will alloc watch, alloc tree, then failure occurs) >> >> >> I guess, we need 2-3 days to get a test result. >> >> >> welcome any suggestions and completions. >> >> thanks. >> >> >> >>> >>> it seems, your way is the only executable way (if not change code much). >>> what my original idea is incorrect. >>> >>> we need add related code at failure process area in audit_data_to_entry. >>> and another functions need not add these code (should not add). >>> 'watch' also need be processed, since audit_to_watch let ref count = 2. >>> (it just like the function audit_del_rule has done) >>> >>> please help check thanks. >>> >>> :-) >>> >>> >>> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c >>> index 81f63f9..f5327ce 100644 >>> --- a/kernel/auditfilter.c >>> +++ b/kernel/auditfilter.c >>> @@ -594,6 +594,10 @@ exit_nofree: >>> return entry; >>> >>> exit_free: >>> + if (entry->rule.watch) >>> + audit_put_watch(entry->rule.watch); /* matches initial get */ >>> + if (entry->rule.tree) >>> + audit_put_tree(entry->rule.tree); /* that's the temporary one */ >>> audit_free_rule(entry); >>> return ERR_PTR(err); >>> } >>> >>> >>> >>>> >>>> can we add it in audit_free_rule ? >>>> >>>> maybe like this: >>>> >>>> @@ -75,6 +75,8 @@ static inline void audit_free_rule(struct audit_entry *e) >>>> /* some rules don't have associated watches */ >>>> if (erule->watch) >>>> audit_put_watch(erule->watch); >>>> + if (erule->tree) >>>> + audit_put_tree(erule->tree); >>>> if (erule->fields) >>>> for (i = 0; i < erule->field_count; i++) { >>>> struct audit_field *f = &erule->fields[i]; >>>> >>>> >>>> thanks. >>>> >>>> :-) >>>> >>> >>> >> >> > > -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/