Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755730AbbLGEbK (ORCPT ); Sun, 6 Dec 2015 23:31:10 -0500 Received: from shards.monkeyblade.net ([149.20.54.216]:35192 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755611AbbLGEbJ (ORCPT ); Sun, 6 Dec 2015 23:31:09 -0500 Date: Sun, 06 Dec 2015 23:31:07 -0500 (EST) Message-Id: <20151206.233107.1531491369717555436.davem@davemloft.net> To: rweikusat@mobileactivedefense.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATH 02/02] af_unix: fix unix_dgram_recvmsg entry locking From: David Miller In-Reply-To: <8737vf7051.fsf@doppelsaurus.mobileactivedefense.com> References: <8737vf7051.fsf@doppelsaurus.mobileactivedefense.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sun, 06 Dec 2015 20:31:08 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1921 Lines: 35 From: Rainer Weikusat Date: Sun, 06 Dec 2015 21:11:38 +0000 > The current unix_dgram_recvsmg code acquires the u->readlock mutex in > order to protect access to the peek offset prior to calling > __skb_recv_datagram for actually receiving data. This implies that a > blocking reader will go to sleep with this mutex held if there's > presently no data to return to userspace. Two non-desirable side effects > of this are that a later non-blocking read call on the same socket will > block on the ->readlock mutex until the earlier blocking call releases it > (or the readers is interrupted) and that later blocking read calls > will wait longer than the effective socket read timeout says they > should: The timeout will only start 'ticking' once such a reader hits > the schedule_timeout in wait_for_more_packets (core.c) while the time it > already had to wait until it could acquire the mutex is unaccounted for. > > The patch avoids both by using the __skb_try_recv_datagram and > __skb_wait_for_more packets functions created by the first patch to > implement a unix_dgram_recvmsg read loop which releases the readlock > mutex prior to going to sleep and reacquires it as needed > afterwards. Non-blocking readers will thus immediately return with > -EAGAIN if there's no data available regardless of any concurrent > blocking readers and all blocking readers will end up sleeping via > schedule_timeout, thus honouring the configured socket receive timeout. > > Signed-Off-By: Rainer Weikusat Also applied to net-next, thanks. BTW, it's "Signed-off-by: ". Only the first word is capitalized. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/