From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f45.google.com ([209.85.215.45]:35376 "EHLO mail-lf0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933207AbcBIWZO (ORCPT ); Tue, 9 Feb 2016 17:25:14 -0500 Received: by mail-lf0-f45.google.com with SMTP id l143so861402lfe.2 for ; Tue, 09 Feb 2016 14:25:13 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <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> <20160209210657.GH17997@ZenIV.linux.org.uk> Date: Tue, 9 Feb 2016 17:25:12 -0500 Message-ID: Subject: Re: Orangefs ABI documentation From: Mike Marshall To: Al Viro Cc: Linus Torvalds , linux-fsdevel , Stephen Rothwell Content-Type: text/plain; charset=UTF-8 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > what should the daemon see in such situation? I'll work to see if I can get an opinion on that from some of the others... As to the traces of AIO... I'm not sure how that ever worked. The out of tree kernel module never had the address_space_operations direct_IO call-out, I think AIO, the way it works in modern kernels, requires that? I fooled with it a couple of years ago when I had Christoph to mentor me, but implementing it and getting it to work right were hard and didn't seem as important as other stuff. How the stuff that was in there was supposed to work seems kind of lost-to-history. Perhaps the stuff that was there was designed to work with that libaio userspace library, but not the io_setup, io_destroy, io_submit etc. stuff that is in modern kernels? -Mike On Tue, Feb 9, 2016 at 4:06 PM, Al Viro wrote: > 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?