On 2019/4/10 下午3:01, Nikolay Borisov wrote: > > > On 10.04.19 г. 9:58 ч., Qu Wenruo wrote: >> >> >> On 2019/4/10 下午2:51, Nikolay Borisov wrote: >>> >>> >>> On 10.04.19 г. 9:34 ч., Qu Wenruo wrote: >>>> Hi, >>>> >>>> As we have memleak.py in bcc tools, and it provides better info >>>> including the calling stack, I'm wondering if we should replace current >>>> eb leakage check with bcc based one. >>>> >>>> Any idea on this? >>> >>> Why do you want to change it, given that the existing one is only >>> activate if btrfs is compiled with debug enabled and is "seamless"? >> >> Well, I don't want to change that part, but to enhance it by external tools. >> >> E.g, better call stack to mimic valgrind output. So when one developer >> caused some leakage, he or she can locate the problem easier. >> >> Personally speaking, the external tool may be just an good enhancement, >> but may not get much usage. > > How do you envision this bcc-based tool to work? Create a probe hooked > up to eb alloc function which records allocated eb's, a probe on eb free > function and finally have another probe at module unload to check that > all ebs are freed? hook to catch free_extent_buffer(), get_extent_buffer() (does the function just get removed?) and alloc_extent_buffer(), passing all the @bytenr and stack to user space. That's all needed to be done in kernel space. User space catch the bytenr and stack to match the refs increase and decrease. No hook is needed at modules unload. Each refs inc/dec will trigger a check. If one eb get refs == 0, then it's removed from the list/dict/whatever the structure is called in python, along with all its previous call stacks. If dec on an non-existing one, output the stack, this should be the same behavior of current kernel. If any eb still has refs >0, output all the allocation stack, this the enhanced behavior. It's users' response to ensure the tool is loaded/terminated at proper timing, e.g. loaded before mounting the fs of interest and terminated after the fs is unmounted. Thanks, Qu > >> >> Thanks, >> Qu >> >> What >>> are we going to gain by introducing yet another tool or replacing an >>> existing infrastructure with bcc (or whatever) based one? >>> >>>> >>>> Thanks, >>>> Qu >>>> >>
