From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tiger.mobileactivedefense.com ([217.174.251.109]:60391 "EHLO tiger.mobileactivedefense.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752819AbbKQViX (ORCPT ); Tue, 17 Nov 2015 16:38:23 -0500 From: Rainer Weikusat To: David Miller Cc: rweikusat@mobileactivedefense.com, jbaron@akamai.com, dvyukov@google.com, syzkaller@googlegroups.com, mkubecek@suse.cz, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hannes@stressinduktion.org, dhowells@redhat.com, paul@paul-moore.com, salyzyn@android.com, sds@tycho.nsa.gov, ying.xue@windriver.com, netdev@vger.kernel.org, kcc@google.com, glider@google.com, andreyknvl@google.com, sasha.levin@oracle.com, jln@google.com, keescook@google.com, minipli@googlemail.com Subject: Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:) In-Reply-To: <20151117.151421.249423864481324472.davem@davemloft.net> (David Miller's message of "Tue, 17 Nov 2015 15:14:21 -0500 (EST)") References: <87a8qhspfm.fsf@doppelsaurus.mobileactivedefense.com> <876111wpza.fsf@doppelsaurus.mobileactivedefense.com> <87ziydvasn.fsf_-_@doppelsaurus.mobileactivedefense.com> <20151117.151421.249423864481324472.davem@davemloft.net> Date: Tue, 17 Nov 2015 21:37:46 +0000 Message-ID: <87d1v85mtx.fsf@doppelsaurus.mobileactivedefense.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-fsdevel-owner@vger.kernel.org List-ID: David Miller writes: > From: Rainer Weikusat > Date: Mon, 16 Nov 2015 22:28:40 +0000 > >> An AF_UNIX datagram socket being the client in an n:1 association with >> some server socket is only allowed to send messages to the server if the >> receive queue of this socket contains at most sk_max_ack_backlog >> datagrams. [...] >> Signed-off-by: Rainer Weikusat >> Fixes: ec0d215f9420 ("af_unix: fix 'poll for write'/connected DGRAM sockets") > > So because of a corner case of epoll handling and sender socket release, > every single datagram sendmsg has to do a double lock now? > > I do not dispute the correctness of your fix at this point, but that > added cost in the fast path is really too high. This leaves only the option of a somewhat incorrect solution and what is or isn't acceptable in this respect is somewhat difficult to decide. The basic options would be - return EAGAIN even if sending became possible (Jason's most recent suggestions) - retry sending a limited number of times, eg, once, before returning EAGAIN, on the grounds that this is nicer to the application and that redoing all the stuff up to the _lock in dgram_sendmsg can possibly/ likely be avoided Which one do you prefer?