Hi, I've been trying to understand kernel_sendpage but I've not been able to figure it out completely and hopefully someone else knows better so please help me out on this. I'm using kernel_sendpage for a TCP connection and it works well when there are lesser number of kernel threads trying to send data using it. Now the page I hand over to kernel_sendpage is reused again for reading data from the socket and then processing it and then again resending the processed data in the same page again. It's at maximum 2KB data and never lesser than 120 bytes. As I see it in the code, the page isn't copied in the skb frags array it's just assigned and get_page is called to increment the page reference count. (I don't free it anyway until the thread is stopped and it never is unless it gets a signal). Now I don't know wether kernel_sendpage will wait for the page to be sent or it won't. I've tried with MSG_DONTWAIT and passing 0 for flags but after every now and then the problem occurs at client which I'm describing below with the best explanation I could think of... When too many kernel threads are trying to send data using kernel_sendpage, with NO MSG_DONTWAIT flag, then also it seems that this call succeeds? However since I'm reusing the page the data can get overridden by the next sock_recvmsg and when the network stack is ready to send my page it gets garbage data at client? The same issue I observed with MSG_DONTWAIT set even in that case the client sometimes get garbage data. So my query is, To use kernel_sendpage what I need to do in order to be sure that network stack indeed has sent my page and that I can reuse it for sock_recvmsg again. Thanks a lot for reading! Regards, Pranay Kr. Srivastava pranay.shrivastava@hcl.com Software Engineer ERS,HCL Technologies A-5, Sector 24, Noida 201301, U.P. (India) ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------