From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:38527 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755142AbcBIVHA (ORCPT ); Tue, 9 Feb 2016 16:07:00 -0500 Date: Tue, 9 Feb 2016 21:06:57 +0000 From: Al Viro To: Mike Marshall Cc: Linus Torvalds , linux-fsdevel , Stephen Rothwell Subject: Re: Orangefs ABI documentation Message-ID: <20160209210657.GH17997@ZenIV.linux.org.uk> References: <20160130182731.GF17997@ZenIV.linux.org.uk> <20160206194210.GX17997@ZenIV.linux.org.uk> <20160207013835.GY17997@ZenIV.linux.org.uk> <20160207035331.GZ17997@ZenIV.linux.org.uk> <20160208233535.GC17997@ZenIV.linux.org.uk> <20160209033203.GE17997@ZenIV.linux.org.uk> <20160209174049.GG17997@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160209174049.GG17997@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Feb 09, 2016 at 05:40:49PM +0000, Al Viro wrote: > Could you try, on top of those fixes, comment the entire > if (op->downcall.type == ORANGEFS_VFS_OP_FILE_IO) { > long n = wait_for_completion_interruptible_timeout(&op->done, > op_timeout_secs * HZ); > if (unlikely(n < 0)) { > gossip_debug(GOSSIP_DEV_DEBUG, > "%s: signal on I/O wait, aborting\n", > __func__); > } else if (unlikely(n == 0)) { > gossip_debug(GOSSIP_DEV_DEBUG, > "%s: timed out.\n", > __func__); > } > } > in orangefs_devreq_write_iter() out and see if the corruption happens? Another thing: what's the protocol rules regarding the cancels? The current code looks very odd - if we get a hit by a signal after the daemon has picked e.g. read request but before it had replied, we will call orangefs_cancel_op_in_progress(), which will call service_operation() with ORANGEFS_OP_CANCELLATION which will. And that'll insert the cancel request into list and practically immediately notice that we have a pending signal, remove the cancel request from the list and bugger off. With daemon almost certainly *not* getting to see it at all. I've asked that before if anybody has explained that, I've missed that reply. How the fuck is that supposed to work? Forget the kernel-side implementation details, what should the daemon see in such situation? I would expect something like "you can't reuse a slot until operation has been either completed or purged or a cancel had been sent and ACKed by the daemon". Is that what is intended? If so, the handling of cancels might be better off asynchronous - let the slot freeing be done after the cancel had been ACKed and _not_ in the context of original syscall... There are some traces of AIO support in that thing; could this be a victim of trimming async parts for submission into the mainline?