Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759325AbbKSXtW (ORCPT ); Thu, 19 Nov 2015 18:49:22 -0500 Received: from tiger.mobileactivedefense.com ([217.174.251.109]:60502 "EHLO tiger.mobileactivedefense.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750768AbbKSXtU (ORCPT ); Thu, 19 Nov 2015 18:49:20 -0500 From: Rainer Weikusat To: Rainer Weikusat Cc: David Miller , 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: <878u5w5lcr.fsf@doppelsaurus.mobileactivedefense.com> (Rainer Weikusat's message of "Tue, 17 Nov 2015 22:09:40 +0000") References: <87a8qhspfm.fsf@doppelsaurus.mobileactivedefense.com> <876111wpza.fsf@doppelsaurus.mobileactivedefense.com> <87ziydvasn.fsf_-_@doppelsaurus.mobileactivedefense.com> <20151117.151421.249423864481324472.davem@davemloft.net> <87d1v85mtx.fsf@doppelsaurus.mobileactivedefense.com> <878u5w5lcr.fsf@doppelsaurus.mobileactivedefense.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Thu, 19 Nov 2015 23:48:45 +0000 Message-ID: <87h9kh7dpe.fsf@doppelsaurus.mobileactivedefense.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (tiger.mobileactivedefense.com [217.174.251.109]); Thu, 19 Nov 2015 23:48:57 +0000 (GMT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1401 Lines: 31 Rainer Weikusat writes: > Rainer Weikusat writes: > > [...] > >> 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 > > A third option: A fourth and even one that's reasonably simple to implement: In case other became ready during the checks, drop other lock, do a double-lock sk, other, set a flag variable indicating this and restart the procedure after the unix_state_lock_other[*], using the value of the flag to lock/ unlock sk as needed. Should other still be ready to receive data, execution can then continue with the 'queue it' code as the other lock was held all the time this time. Combined with a few unlikely annotations in place where they're IMHO appropriate, this is speed-wise comparable to the stock kernel. -- 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/