[Qemu-devel] [PATCH] slirp: Fix packet expiration

[Qemu-devel] [PATCH] slirp: Fix packet expiration

[Thomas Huth]

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.

Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
-------
 slirp/mbuf.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/slirp/mbuf.h b/slirp/mbuf.h
index 55170e5..37b9dbb 100644
--- a/slirp/mbuf.h
+++ b/slirp/mbuf.h
@@ -82,12 +82,12 @@ struct m_hdr {
 struct mbuf {
 	struct	m_hdr m_hdr;
 	Slirp *slirp;
+	bool	arp_requested;
+	uint64_t expiration_date;
 	union M_dat {
 		char	m_dat_[1]; /* ANSI don't like 0 sized arrays */
 		char	*m_ext_;
 	} M_dat;
-    bool     arp_requested;
-    uint64_t expiration_date;
 };
 
 #define m_next		m_hdr.mh_next

Re: [Qemu-devel] [PATCH] slirp: Fix packet expiration

[Jan Kiszka]

On 2011-09-27 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.
> 
> Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
> -------
>  slirp/mbuf.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/slirp/mbuf.h b/slirp/mbuf.h
> index 55170e5..37b9dbb 100644
> --- a/slirp/mbuf.h
> +++ b/slirp/mbuf.h
> @@ -82,12 +82,12 @@ struct m_hdr {
>  struct mbuf {
>  	struct	m_hdr m_hdr;
>  	Slirp *slirp;
> +	bool	arp_requested;
> +	uint64_t expiration_date;
>  	union M_dat {
>  		char	m_dat_[1]; /* ANSI don't like 0 sized arrays */
>  		char	*m_ext_;
>  	} M_dat;
> -    bool     arp_requested;
> -    uint64_t expiration_date;
>  };
>  
>  #define m_next		m_hdr.mh_next

Thanks, applied.

What generates "-------" as separator? Confuses git am here. You may
want to use standard "---" in the future.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH] slirp: Fix packet expiration

[Fabien Chouteau]

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.
 */

> Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
> -------
>  slirp/mbuf.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/slirp/mbuf.h b/slirp/mbuf.h
> index 55170e5..37b9dbb 100644
> --- a/slirp/mbuf.h
> +++ b/slirp/mbuf.h
> @@ -82,12 +82,12 @@ struct m_hdr {
>  struct mbuf {
>  	struct	m_hdr m_hdr;
>  	Slirp *slirp;
> +	bool	arp_requested;
> +	uint64_t expiration_date;
>  	union M_dat {
>  		char	m_dat_[1]; /* ANSI don't like 0 sized arrays */
>  		char	*m_ext_;
>  	} M_dat;
> -    bool     arp_requested;
> -    uint64_t expiration_date;
>  };
>  
>  #define m_next		m_hdr.mh_next
> 


-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH] slirp: Fix packet expiration

[Jan Kiszka]

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