From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH v2] tcp: perform DMA to userspace only if there is a task waiting for it Date: Fri, 27 Jul 2012 13:48:04 -0700 (PDT) Message-ID: <20120727.134804.412337393847863208.davem@davemloft.net> References: <20120727.133135.2017747630291360657.davem@davemloft.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: christopher.leech@intel.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, jbohac@suse.cz To: jkosina@suse.cz Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org From: Jiri Kosina Date: Fri, 27 Jul 2012 22:38:50 +0200 (CEST) > Back in 2006, commit 1a2449a87b ("[I/OAT]: TCP recv offload to I/OAT") > added support for receive offloading to IOAT dma engine if available. > > The code in tcp_rcv_established() tries to perform early DMA copy if > applicable. It however does so without checking whether the userspace > task is actually expecting the data in the buffer. > > This is not a problem under normal circumstances, but there is a corner > case where this doesn't work -- and that's when MSG_TRUNC flag to > recvmsg() is used. > > If the IOAT dma engine is not used, the code properly checks whether > there is a valid ucopy.task and the socket is owned by userspace, but > misses the check in the dmaengine case. > > This problem can be observed in real trivially -- for example 'tbench' is a > good reproducer, as it makes a heavy use of MSG_TRUNC. On systems utilizing > IOAT, you will soon find tbench waiting indefinitely in sk_wait_data(), as they > have been already early-copied in tcp_rcv_established() using dma engine. > > This patch introduces the same check we are performing in the simple > iovec copy case to the IOAT case as well. It fixes the indefinite > recvmsg(MSG_TRUNC) hangs. > > Signed-off-by: Jiri Kosina Applied.