From patchwork Tue Dec 29 12:29:55 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 561553 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 1D9FB140C0B for ; Tue, 29 Dec 2015 23:30:23 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=llJZ/K5M; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753370AbbL2MaA (ORCPT ); Tue, 29 Dec 2015 07:30:00 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:38275 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752049AbbL2M36 (ORCPT ); Tue, 29 Dec 2015 07:29:58 -0500 Received: by mail-wm0-f48.google.com with SMTP id b14so11585338wmb.1; Tue, 29 Dec 2015 04:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=4YcotZud8llzr8a4SX8QUK75jkeIQnuPtw/FQSpr6yY=; b=llJZ/K5MR3DBJu4rVLVy6FXfsx9L0LAIl54Q++JTY0IVl+YGSKEW63xTTkEv5eWegp hmYp7tcIZncY8eP44T+hVtx/IC3+CUwi9ECVnnkkmbY2skd1CPgAfFzB/dMSMYWVRxcz QHaEEjQfkHliKtVLdmDer0JdES9UvmQskGktCJfekbeVRiZucdHeaWGPbJGp2hjj8KPn biAo5ltNMzDNehZf+HzJsS4aOiTKJ7ChdUgxuwA18MvpfTCPCxaO2wZAuF2SckFdoXaA bintdKctjnsARBUfsMWj61Gj/9Pn42P/WyGZ3AXUV447eYiKw0V+1cW//9jJ6kGpxocZ 3IcQ== X-Received: by 10.28.73.135 with SMTP id w129mr47502579wma.55.1451392197317; Tue, 29 Dec 2015 04:29:57 -0800 (PST) Received: from localhost.localdomain (f050162030.adsl.alicedsl.de. [78.50.162.30]) by smtp.gmail.com with ESMTPSA id w8sm17073062wjx.21.2015.12.29.04.29.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Dec 2015 04:29:56 -0800 (PST) From: Nicolai Stange To: "David S. Miller" Cc: Nicolai Stange , Eric Dumazet , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] net, socket, socket_wq: fix missing initialization of flags References: <87ege73bma.fsf@gmail.com> <1451323186.8255.5.camel@edumazet-glaptop2.roam.corp.google.com> Date: Tue, 29 Dec 2015 13:29:55 +0100 In-Reply-To: <1451323186.8255.5.camel@edumazet-glaptop2.roam.corp.google.com> (Eric Dumazet's message of "Mon, 28 Dec 2015 12:19:46 -0500") Message-ID: <87ziwtphdo.fsf_-_@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection") Commit ceb5d58b2170 ("net: fix sock_wake_async() rcu protection") from the current 4.4 release cycle introduced a new flags member in struct socket_wq and moved SOCKWQ_ASYNC_NOSPACE and SOCKWQ_ASYNC_WAITDATA from struct socket's flags member into that new place. Unfortunately, the new flags field is never initialized properly, at least not for the struct socket_wq instance created in sock_alloc_inode(). One particular issue I encountered because of this is that my GNU Emacs failed to draw anything on my desktop -- i.e. what I got is a transparent window, including the title bar. Bisection lead to the commit mentioned above and further investigation by means of strace told me that Emacs is indeed speaking to my Xorg through an O_ASYNC AF_UNIX socket. This is reproducible 100% of times and the fact that properly initializing the struct socket_wq ->flags fixes the issue leads me to the conclusion that somehow SOCKWQ_ASYNC_WAITDATA got set in the uninitialized ->flags, preventing my Emacs from receiving any SIGIO's due to data becoming available and it got stuck. Make sock_alloc_inode() set the newly created struct socket_wq's ->flags member to zero. Signed-off-by: Nicolai Stange Acked-by: Eric Dumazet Signed-off-by: Nicolai Stange --- Changes to V1 (only commit message changes): - Uhm, I misread sock_wake_async(). The meaning of the flags is actually inverted. My Ghostmacs wasn't waiting for free send space, but some received data becoming available. This makes indeed more sense and I replaced "SOCKWQ_ASYNC_NOSPACE" by "SOCKWQ_ASYNC_WAITDATA" in my speculative explanation above. - Furthermore I fixed some minor grammar issues. Sorry for any inconvenience this late-night induced brainfart might have caused at your side... net/socket.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/socket.c b/net/socket.c index 29822d6..d730ef9 100644 --- a/net/socket.c +++ b/net/socket.c @@ -257,6 +257,7 @@ static struct inode *sock_alloc_inode(struct super_block *sb) } init_waitqueue_head(&wq->wait); wq->fasync_list = NULL; + wq->flags = 0; RCU_INIT_POINTER(ei->socket.wq, wq); ei->socket.state = SS_UNCONNECTED;