From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:47056 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752055AbcBPCMf (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 15 Feb 2016 21:12:35 -0500
Date: Tue, 16 Feb 2016 02:12:28 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mike Marshall <hubcap@omnibond.com>
Cc: Martin Brandenburg <martin@omnibond.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [RFC] slot allocator - waitqueue use review needed (Re: Orangefs
 ABI documentation)
Message-ID: <20160216021228.GA17997@ZenIV.linux.org.uk>
References: <20160209231328.GK17997@ZenIV.linux.org.uk>
 <20160211004432.GM17997@ZenIV.linux.org.uk>
 <CAOg9mSR+=Xj3rtf_DQQjxhWs=HQHYu-3Mjdb3LeOvaYEwLXvYA@mail.gmail.com>
 <20160212042757.GP17997@ZenIV.linux.org.uk>
 <CAOg9mSTPQLarX0kpBgfhnpPZL=0Y7netSLhSkhHfAEor_w2mEg@mail.gmail.com>
 <CA+D=wkhJRVsety9WX9KLGbRUEk1hwSf4Q0oP23c1TtQjr_Oguw@mail.gmail.com>
 <CAOg9mSQ=pF=Pg60VoSUeywybDATi1M3TTRmjGNEmvyLCh0AAoQ@mail.gmail.com>
 <20160213174738.GR17997@ZenIV.linux.org.uk>
 <20160214025615.GU17997@ZenIV.linux.org.uk>
 <20160214034608.GV17997@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160214034608.GV17997@ZenIV.linux.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sun, Feb 14, 2016 at 03:46:08AM +0000, Al Viro wrote:
> FWIW, I think I have a kinda-sorta solution for bufmap slot allocation/waiting;
> if somebody has a better idea, I would love to drop the variant below.  And
> I would certainly appreciate review - I hate messing with waitqueue primitives
> and I know how easy it is to fuck those up ;-/

... and in the "easy to fuck up" department, this thing doesn't stop waiting
when it gets a signal *and* is vulnerable to an analogue of the problem
dealt with in commit 777c6c5f1f6e757ae49ecca2ed72d6b1f523c007
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Wed Feb 4 15:12:14 2009 -0800

    wait: prevent exclusive waiter starvation

Suppose we are waiting for a slot when everything's full.  Somebody releases
theirs, and we get woken up, just as we are hit with SIGKILL or time out.
We remove ourselves from the waitqueue and bugger off.  Too bad - everybody
else is going to get stuck until they time out.  If we got the slot, we would've
done wakeup when releasing it.  Since we hadn't, no such wakeup happens...

I wonder if wait_event_interruptible_exclusive_locked{,_irq}() is
vulnerable to the same problem; plain one is used in fuse, irq - in
gadgetfs and the latter looks somewhat fishy in that respect...

orangefs one fixed, folded and pushed, but I hadn't really looked into
fuse and gadgetfs enough to tell if they have similar problems...