From patchwork Mon Sep 1 01:28:16 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willem de Bruijn X-Patchwork-Id: 384606 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 53D831401AD for ; Mon, 1 Sep 2014 11:28:24 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751966AbaIAB2V (ORCPT ); Sun, 31 Aug 2014 21:28:21 -0400 Received: from mail-oi0-f73.google.com ([209.85.218.73]:59848 "EHLO mail-oi0-f73.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751787AbaIAB2T (ORCPT ); Sun, 31 Aug 2014 21:28:19 -0400 Received: by mail-oi0-f73.google.com with SMTP id u20so890229oif.2 for ; Sun, 31 Aug 2014 18:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=MFyd8GUgad5KqOmJsKoQlNcr27qlKp5cGeSapgDqKtg=; b=P3+io68dX5WbO2guQ+P9kNoXEkWMM+y2vIm1jwpb3SahbJHI/DJ+jucp9qgYQpS1DE MMh9Jla1G1xsTsmFSXnGosx283Uompdyx7PAtDxGx8YaGSHBOGpb1iyj2cXUF9lXm+hU gw2+KQhfhU0gMm0pfpfKNY1M300sZiNb8TWyCVcjHIQw72uHa9Ak6/lOnu1ULRzfHPTg GFxobnbuDk3gyNMlJ4S/hrj1c+s1hMKHhNnVjzEWLLgjcvzPhN4rHUwLaGx6ljd4ul7q yKrvYHQWEyVUroyCwfNGoLO6xHC5G2KQr5lc9830PU2iYkEF0l5KpgpFPVC+MB4Z+OGs ym9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=MFyd8GUgad5KqOmJsKoQlNcr27qlKp5cGeSapgDqKtg=; b=L0aBQPidFRpSkRDxLZHrOvtXAHJutMsJaVn/PoWR/xsqg1qJcwtcydMndJRx+HkFUH 9cMgn1NBKpehPizoYUpFdqXgDNCQRxFyIlbeBGDHtVgiCbdNOum+sMoxtLCCZDzkPTb1 pStdqanwIGkZxSCfVZxyy6nnLWNN0Vj9Oiyz7pZLJjoyWrMB2zj3rkasFUdJQOQQg2Ge e27J/bqWHFf8g2lEj5WkVRzLwiwXhPNubXa5o+ISTvmj9hLdo0zbc57Z9VhYRYb0zhm2 nMEFilCtcAXx8i4oOARW7zK2BKA9zqbT+ncJZ6koUR0xDY0tHO/MhHYbeqK59JpEb/GQ ErRA== X-Gm-Message-State: ALoCoQkwrakxt1eUcs7QMDBn33C12xDzTrCrVU0IuIdlPVH4/iRqzApMwuM8cg0rG5aKKir01upY X-Received: by 10.50.92.104 with SMTP id cl8mr10543928igb.1.1409534898843; Sun, 31 Aug 2014 18:28:18 -0700 (PDT) Received: from corp2gmr1-1.hot.corp.google.com (corp2gmr1-1.hot.corp.google.com [172.24.189.92]) by gmr-mx.google.com with ESMTPS id e55si334841yhb.3.2014.08.31.18.28.18 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 31 Aug 2014 18:28:18 -0700 (PDT) Received: from gopher.nyc.corp.google.com (gopher.nyc.corp.google.com [172.26.106.37]) by corp2gmr1-1.hot.corp.google.com (Postfix) with ESMTP id 976EE31C1B4; Sun, 31 Aug 2014 18:28:18 -0700 (PDT) Received: by gopher.nyc.corp.google.com (Postfix, from userid 29878) id 5FFC4C08CD; Sun, 31 Aug 2014 21:28:18 -0400 (EDT) From: Willem de Bruijn To: netdev@vger.kernel.org Cc: davem@davemloft.net, Willem de Bruijn Subject: [PATCH net-next] sock: consistent errqueue errors and signals Date: Sun, 31 Aug 2014 21:28:16 -0400 Message-Id: <1409534896-372-1-git-send-email-willemb@google.com> X-Mailer: git-send-email 2.1.0.rc2.206.gedb03e5 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org When a socket error is pending, send()/recv() must abort their normal operation and return the error. An error means having non-zero sk->sk_err or having non-empty sk->sk_error_queue. Currently, the behavior for the second is inconsistent depending on whether an error has previously been dequeued. In all cases, recv()/send() test sk->sk_err. This is not modified on enqueue onto the error queue, so may be 0. It is modified on dequeue, however, to match the queued skb's errno. I observed the following when two errors were queued: ret = poll(pollfd, 1, -1); assert(ret == 1); assert(pollfd.revents == POLLERR); ret = recv(fd, buf, size, MSG_NONBLOCK); assert(ret == -1 && errno == EAGAIN); /* <-- A */ ret = recv(fd, buf, size, MSG_ERRQUEUE); assert(ret > 0); ret = recv(fd, buf, size, MSG_NONBLOCK); assert(ret == -1 && errno == ENOMSG); /* <-- B */ ret = recv(fd, buf, size, MSG_ERRQUEUE); assert(ret > 0); The recv call in B returns the error code embedded in SKB_EXT_ERR(skb), in this case ENOMSG, because I am working with timestamps. The recv call in A should have returned the same. Implement this behavior. This may surprise existing applications. Also make the wake-up signal when data is ready on the error queue consistent between enqueue and dequeue: use sk_error_report in both cases. Signed-off-by: Willem de Bruijn --- This approach leaves one issue: The states of sk->sk_err and sk->sk_error_queue are related, but only loosely. Error queue enqueue, dequeue and other code may overwrite sk->sk_err unconditionally. For one, sock_error will reset sk->sk_err to 0 even if sk->sk_error_queue is not empty. If socket calls should abort on all errors, then should be change to test sk_error_queue.qlen. But, doing so requires taking a lock in a busy data path. --- net/core/skbuff.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 163b673..f7a280b 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3485,8 +3485,11 @@ int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb) skb_dst_force(skb); skb_queue_tail(&sk->sk_error_queue, skb); + sk->sk_err = SKB_EXT_ERR(skb)->ee.ee_errno; + if (!sock_flag(sk, SOCK_DEAD)) - sk->sk_data_ready(sk); + sk->sk_error_report(sk); + return 0; } EXPORT_SYMBOL(sock_queue_err_skb);