From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SPJmS-0007Ob-Nd for mharc-grub-devel@gnu.org; Tue, 01 May 2012 16:34:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:32858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPJmP-0007Np-PV for grub-devel@gnu.org; Tue, 01 May 2012 16:34:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPJmK-0003Ty-L8 for grub-devel@gnu.org; Tue, 01 May 2012 16:34:37 -0400 Received: from mail-qa0-f41.google.com ([209.85.216.41]:48392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPJmK-0003SQ-EH for grub-devel@gnu.org; Tue, 01 May 2012 16:34:32 -0400 Received: by qabg27 with SMTP id g27so2603351qab.0 for ; Tue, 01 May 2012 13:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=Hf+FiPrl3DZL6h0xLIowZRiMf0+3z9c5jXMaQlv7ET0=; b=w1K6l+Loqj2HpeiRrhHv5dLfFLvtkQAEE2A4hwTIEOl8JTI2yqCCvfiIC3yXZrtKE7 HlRPyZ4kuTC59q5dhkAMey2RZLazN6G7y6rub6gjecpssXb6ql1cCe//mOGbZ1ycMHIP Kiw8BmKT9ydgQRSYsve2vDOlTC5pRsSKql4hi1VV6aiPrpMOA+mHslwgukzuGWxoCnxz qO0RfytNCMeVQmsgn7QEkZFE3hvp7r0HS3QzgFqvtYbx74N4UDW3q2uuoxSdR8kROdgC r5z09256qbqAm+Bkanbe31/jlfAgwq/E9SCPTigOVO7hnDoySGK8oOdIS0OX7RquD12R wsBg== MIME-Version: 1.0 Received: by 10.224.87.67 with SMTP id v3mr14712463qal.32.1335904470776; Tue, 01 May 2012 13:34:30 -0700 (PDT) Received: by 10.229.222.197 with HTTP; Tue, 1 May 2012 13:34:30 -0700 (PDT) In-Reply-To: <4FA0448F.2040901@gmail.com> References: <4FA034B2.2030400@gmail.com> <4FA03FF2.30607@gmail.com> <4FA04234.2060002@gmail.com> <4FA0448F.2040901@gmail.com> Date: Wed, 2 May 2012 04:34:30 +0800 Message-ID: Subject: Re: Mysterious memory corruption bug From: Bean To: The development of GNU GRUB Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.216.41 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 20:34:39 -0000 On Wed, May 2, 2012 at 4:16 AM, Vladimir '=F6-coder/phcoder' Serbinenko wrote: > On 01.05.2012 22:09, Bean wrote: >> On Wed, May 2, 2012 at 4:06 AM, Vladimir '=F6-coder/phcoder' Serbinenko >> wrote: >>> On 01.05.2012 22:02, Bean wrote: >>>> Hi, >>>> >>>> Yeah, I have a patch that save the buffer for later use when there is >>>> no data, it can solve the unnecessary alloc/free loop. >>> No, what I mean: allocate a buffer once for every card and then do >>> send/recv with only this buffer and copy to/from it when necessary. Thi= s >>> way if the card DMAs the packet to the same buffer it won't corrupt >>> anything. >> Hi, >> >> It's not ok with fragmentation, since there could be multiple ethernet >> packet for an ip packet, we need to store the buffer for assembling. > We use the buffer I said only for actual calls. It's copied to > newly-allocated packet as soon as the call returns. Hi, Yeah, after more thought, it's doable. We can use a ring buffer for current active ip frames, and copy ethernet frame to it. This way we can get rid of the rsm dynamic queue. It can also get rid of tons of grub_netbuff_free scattered around in various layers. --=20 Best wishes Bean