Re: RFC: enhanced memory protection support

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]

On 30.04.2012 21:55, Bean wrote:
> On Tue, May 1, 2012 at 1:24 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>> On 30.04.2012 17:26, Bean wrote:
>>> Hi,
>>>
>>> While testing network function in efi mode, I've found several memory
>>> leak related to fragmentation, but there is still some memory problem
>>> that's very tricky to locate. For example, you can run testspeed on a
>>> large file several times in a row and it could show the memory error.
>>> Since network condition are very difficult to reproduce, I have to
>>> look at the source of this issue, memory allocation. Currently it has
>>> mm_debug option that could print out file and line number of each
>>> memory call, but it's quite useless since we can't find the relevant
>>> informaton with full screen of prints.
>>> Here are some of my ideas for enhanced memory protection support:
>>>
>>> 1, when we allocate memory, we append some information at the end of
>>> the buffer, which include filename, lineno of caller, and tag to
>>> indicate what is used for and some padding to detect memory overwrite
>>> problem.
>>>
>>> 2. add a command to print the current memory list with extended
>>> information, this can be used to find memory leaks.
>>>
>>> 3. it's also a good idea to run the memory check in automated test to
>>> locate potential issue.
>> This is pretty easy to do leveraging some of the code I did for POSIX
>> support. But:
>> - Due to additional time and space required it should be done only when
>> mm-debug is enabled.
>> - The additional data has to be stored before rather than after the
>> range since we store all the info before.
>> - Integrating with automated tests isn't that easy since some memory is
>> intentionally never freed i.a. disk cache or otherwise in use (i.a.
>> terminal). We need exceptions for those.
>> I have half-working patch, just needs few fixes.
> Hi,
>
> Some thoughts about this:
>
> We can assign a sequence id for each allocated memory, then we can
> search memory allocated from point A to B. This can be used to skip
> memory allocated during initialization stage.
>
> We can use special tag for memory that would stick around, for
> example, the *prefix: *cache, *fs, *term, etc, then we can skip them
> in auto tests.
That's overengineering since at the end we need just one information: do
we track this memory or don't we? So we just need grub_*alloc_notrack
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]