lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Race condition in tpcip.c causing memory corruption


From: Ted Smith
Subject: [lwip-users] Race condition in tpcip.c causing memory corruption
Date: Wed, 27 Feb 2013 16:56:33 +0000

I’m using lwip on a microblaze platform using FreeRTOS  as the OS.      I ran into memory corruption problems when inbound and outbound traffic over a tcp socket was occurring.  I traced the problem to the function tcpip_apimsg()  where a context switch occurs between the sys_mbox_post() and sys_arch_sem_wait().   In this scenario  a thread doing an outbound socket write results in a msg for do_write getting posted to the mbox.  This causes a context switch to the tcpip_thread() which fetches the msg from the mailbox and begins processing. This thread gets context switched out before getting to the TCPIP_APIMSG_ACK().  Execution is passed to a thread that is passing packets into lwip.  This thread gets into tcpip_apimsg() and posts to the mbox.  No context switch occurs (because tcpip_thread() is not currently waiting in the fetch call) so this receive thread makes it to the sys_arch_sem_wait(&apimsg->msg.conn->op_completed, 0) call and blocks.   Now a context switch occurs back to the outbound thread which finally makes it to the same sys_arch_sem_wait() call and blocks.  Now context is switched to the tcpip_thread which finish the do_write() execution and calls TCPIP_APIMSG_ACK().   This should have unblocked the outbound thread however the first one to block on that sem was the inbound thread (which still has it’s message posted in the mbox) so the inbound thread receives the signal.  Now the tcpip_thread() grabs the inbound msg (which container was on the inbound thread’s stack which has been popped) and starts processing the message.  That container can now be corrupted since the stack has been popped.  Bad things happen after this…..

 

I’m wondering if I’m somehow using the interfaces wrong to cause this to happen.    I fixed this by protecting the tcpip_apimsg()  call with a semaphore to stop reentrancy.  

 

I’m I doing something wrong or is this a real bug?

 

Thanks,

 

Ted

 

 


http://www.biofiredx.com/images/signature/signaturebar.jpg

Ted Smith
Senior Firmware Engineer
BioFire Diagnostics, Inc.
390 Wakara Way | Salt Lake City, Utah 84108
Office: 801-736-6354 x809  
Email: address@hidden

http://www.biofiredx.com/images/signature/BioFireDXEmailLogo.gif
www.BioFireDX.com

 


-------------------------------------------------------
CONFIDENTIALITY NOTICE: This email and any attachments are confidential information of the sender and are for the exclusive use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of this email or any attachment is prohibited. If you have received this email in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation.   ­­  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]