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@xxxxxxxxxxx>
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...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
