On 10.04.19 г. 10:11 ч., Qu Wenruo wrote:
>
>
> 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.
Such tool might indeed be useful, however it's going to be just a 3rd
party tool. As such it's up to you whether you want to develop it and
use or not and share it on github. However, the in-kernel infrastructure
should stay untouched (although it's rather crude). Subsequently we
might think about removing it.
>
> 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
>>>>>
>>>
>
