From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 581B5C43381 for ; Tue, 26 Feb 2019 23:59:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2B76F21848 for ; Tue, 26 Feb 2019 23:59:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728912AbfBZX7S (ORCPT ); Tue, 26 Feb 2019 18:59:18 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:41080 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726801AbfBZX7S (ORCPT ); Tue, 26 Feb 2019 18:59:18 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1gymcy-0007ka-Km; Tue, 26 Feb 2019 23:59:12 +0000 Date: Tue, 26 Feb 2019 23:59:12 +0000 From: Al Viro To: Jason Baron Cc: Rainer Weikusat , netdev@vger.kernel.org Subject: Re: [RFC] nasty corner case in unix_dgram_sendmsg() Message-ID: <20190226235912.GL2217@ZenIV.linux.org.uk> References: <20190225035121.GH2217@ZenIV.linux.org.uk> <20190226062817.GA17962@ZenIV.linux.org.uk> <20190226063804.GI2217@ZenIV.linux.org.uk> <878sy2k1m3.fsf@doppelsaurus.mobileactivedefense.com> <20190226190316.GJ2217@ZenIV.linux.org.uk> <552b3d67-2f43-5831-e4ea-666827de54fe@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552b3d67-2f43-5831-e4ea-666827de54fe@akamai.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Feb 26, 2019 at 03:35:39PM -0500, Jason Baron wrote: > > I understand what the unix_dgram_peer_wake_me() is doing; I understand > > what unix_dgram_poll() is using it for. What I do not understand is > > what's the point of doing that in unix_dgram_sendmsg()... > > > > Hi, > > So the unix_dgram_peer_wake_me() in unix_dgram_sendmsg() is there for > epoll in edge-triggered mode. In that case, we want to ensure that if > -EAGAIN is returned a subsequent epoll_wait() is not stuck indefinitely. > Probably could use a comment... *owwww* Let me see if I've got it straight - you want the forwarding rearmed, so that it would match the behaviour of ep_poll_callback() (i.e. removing only when POLLFREE is passed)? Looks like an odd way to do it, if that's what's happening... While we are at it, why disarm a forwarder upon noticing that peer is dead? Wouldn't it be simpler to move that wake_up_interruptible_all(&u->peer_wait); in unix_release_sock() to just before unix_state_unlock(sk); a line prior? Then anyone seeing SOCK_DEAD on (locked) peer would be guaranteed that all forwarders are gone... Another fun question about the same dgram sendmsg: if (unix_peer(sk) == other) { unix_peer(sk) = NULL; unix_dgram_peer_wake_disconnect_wakeup(sk, other); unix_state_unlock(sk); unix_dgram_disconnected(sk, other); ... and we are holding any locks at the last line. What happens if we have thread A doing decide which address to talk to connect(fd, that address) send request over fd (with send(2) or write(2)) read reply from fd (recv(2) or read(2)) in a loop, with thread B doing explicit sendto(2) over the same socket? Suppose B happens to send to the last server thread A was talking to and finds it just closed (e.g. because the last request from A had been "shut down", which server has honoured). B gets ECONNREFUSED, as it ought to, but it can also ends up disrupting the next exchange of A. Shouldn't we rather extract the skbs from that queue *before* dropping sk->lock? E.g. move them to a temporary queue, and flush that queue after we'd unlocked sk...