From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SPAMJ-0005lt-3L for mharc-grub-devel@gnu.org; Tue, 01 May 2012 06:31:03 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPAMG-0005la-RQ for grub-devel@gnu.org; Tue, 01 May 2012 06:31:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPAME-0004Zu-Rb for grub-devel@gnu.org; Tue, 01 May 2012 06:31:00 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:40519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPAME-0004Yv-Ie for grub-devel@gnu.org; Tue, 01 May 2012 06:30:58 -0400 Received: by wibhj13 with SMTP id hj13so2664169wib.12 for ; Tue, 01 May 2012 03:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=U0cSdrueNHB3jWUvQEwjEmlRWkEO8mPy16lvVDyewsY=; b=eoioPv0zcHjTtXFnD7b/th/qPt2DtUZLYisalvJJoBohzDekxexQ3KoTTmZFTET0d9 JRZ5W6kun7k5xQtz4aptV5sCPdKHGp09awMOAOYODJh3eR/2CS8CieBFfv8dGg5SFIMm Ilfnangnaya9crI7sGhOdYdP+wkHsKT7kNq18F5SLZX3AJia8IBihtAkPyJ4ZedCNpH1 6QI6wrA0EmstzXuW5VB1e4f7efZQCZBfMUaO7by6uhhwHCRm8J6VazAVKGFje627rFsp 20xqF7yZWQOYeVsRZL0+e+3WoMdhtI/AmDZy/oNGnkoFjoLXjySnBiTjjQI+r0lPji9C O1IA== Received: by 10.180.107.104 with SMTP id hb8mr4150314wib.8.1335868256608; Tue, 01 May 2012 03:30:56 -0700 (PDT) Received: from debian.x201.phnet (95-232.197-178.cust.bluewin.ch. [178.197.232.95]) by mx.google.com with ESMTPS id ex2sm56118428wib.8.2012.05.01.03.30.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 May 2012 03:30:55 -0700 (PDT) Message-ID: <4F9FBB5D.5070908@gmail.com> Date: Tue, 01 May 2012 12:30:53 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: RFC: enhanced memory protection support References: <4F9ECACF.6050803@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0CF00106BCD3C88CB0980DFE" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.171 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 10:31:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0CF00106BCD3C88CB0980DFE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30.04.2012 21:55, Bean wrote: > On Tue, May 1, 2012 at 1:24 AM, Vladimir '=CF=86-coder/phcoder' Serbine= nko > 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 whe= n >> 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 i= s >> 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 > --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig0CF00106BCD3C88CB0980DFE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk+fu10ACgkQNak7dOguQgmqBwD/RLfhu7/Y/N5SCJWrXEeZUANR FlH03QWDfpLPvqdPjckA/2VBt7if6HWz7YMHVWWT+nnNbsDo95VHdcnrxFtutaTh =CCxF -----END PGP SIGNATURE----- --------------enig0CF00106BCD3C88CB0980DFE--