Re: Orangefs ABI documentation

[Al Viro <viro@ZenIV.linux.org.uk>]

On Tue, Feb 09, 2016 at 10:16:23PM +0000, Al Viro wrote:
> 	* sort out the cancel semantics

OK, it's definitely bogus right now.  Look: read() grabs a slot and
issues read request.  Daemon picks it and starts processing, copying
the data into the corresponding part of shared memory.  read() gets
interrupted and tries to issue a cancel, which fails to even be seen
by the daemon, since wait_for_cancel_downcall() sees the pending signal
and rips the cancel request out of the list.  read() marks the slot
free and buggers off.  write() is called by another process, picks the
same slot and starts copying the userland data into the same part of
shared memory.  Where it's overwritten by daemon still processing the
read request - it hadn't seen any indications of things going wrong.

This is obviously wrong - killed read() should *NOT* end up with the
data it would've returned being silently mixed into the data being
written by write() in unrelated process on unrelated file.

And the version in orangefs-2.9.3.tar.gz (your Frankenstein module?) is
vulnerable to the same race.  2.8.1 isn't - it ignores signals on the
cancel, but that means waiting for cancel to be processed (or timed out)
on any interrupted read() before we return to userland.  We can return
to that behaviour, of course, but I suspect that offloading it to something
async (along with freeing the slot used by original operation) would be
better from QoI point of view.