From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8VOA-000524-Kh for qemu-devel@nongnu.org; Tue, 27 Sep 2011 06:59:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8VO6-0002eR-I6 for qemu-devel@nongnu.org; Tue, 27 Sep 2011 06:59:50 -0400 Received: from thoth.sbs.de ([192.35.17.2]:33858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8VO6-0002e4-7u for qemu-devel@nongnu.org; Tue, 27 Sep 2011 06:59:46 -0400 Message-ID: <4E81AC88.40905@siemens.com> Date: Tue, 27 Sep 2011 12:59:20 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20110927112038.42b5b3f8@BR8GGW75.de.ibm.com> <4E81ABCF.5020101@adacore.com> In-Reply-To: <4E81ABCF.5020101@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] slirp: Fix packet expiration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fabien Chouteau Cc: Thomas Huth , "qemu-devel@nongnu.org" On 2011-09-27 12:56, Fabien Chouteau wrote: > On 27/09/2011 11:20, Thomas Huth wrote: >> >> The two new variables "arp_requested" and "expiration_date" in the mbuf >> structure have been added after the variable-sized "m_dat_" array. The >> variables have to be added before the m_dat_ array instead. >> Without this patch, the expiration_date gets clobbered by code that >> accesses the m_dat_ array. >> I experienced this problem with the code in slirp/tftp.c: The >> tftp_send_data() function created a new packet with the m_get() >> function (which fills-in a default expiration_date value). Then the >> TFTP code cleared the data section of the packet, which accidentially >> also cleared the expiration_date. This zeroed expiration_date then >> finally causes the packet to be discarded during if_start(), so that >> TFTP packets were not transmitted anymore. >> > > Thanks for the patch Thomas. > > I think we can add a comment to avoid this kind of mistake in the > future. > > /* This is a "flexible array member". It should always remain > * the last member of the structure. > */ Good point, folded something like that in. Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux