From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f54.google.com ([209.85.215.54]:32914 "EHLO mail-lf0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753996AbcAVRkE (ORCPT ); Fri, 22 Jan 2016 12:40:04 -0500 Received: by mail-lf0-f54.google.com with SMTP id m198so51669433lfm.0 for ; Fri, 22 Jan 2016 09:40:03 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20160122170838.GZ17997@ZenIV.linux.org.uk> References: <20160122071147.GY17997@ZenIV.linux.org.uk> <20160122170838.GZ17997@ZenIV.linux.org.uk> Date: Fri, 22 Jan 2016 12:40:02 -0500 Message-ID: Subject: Re: Orangefs ABI documentation From: Mike Marshall To: Al Viro Cc: Linus Torvalds , linux-fsdevel Content-Type: text/plain; charset=UTF-8 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: I think I see what you are saying... it seems like we have always just freed them and to heck with whatever was waiting on them. Maybe in all the places I detect something bad, set the return code and goto out, perhaps I should also jamb the bad return code into op->downcall.status and goto wakeup intead of out? Our infant fuzzer isn't really up to making test errors show up there, I'd probably have to put some test weirdo stuff in the userspace part that does the writev to make some test failures... -Mike On Fri, Jan 22, 2016 at 12:08 PM, Al Viro wrote: > On Fri, Jan 22, 2016 at 11:59:40AM -0500, Mike Marshall wrote: >> Hi Al... >> >> I moved a tiny bit of your work around so it would compile, but I booted a >> kernel from it, and ran some tests, it seems to work OK... doing this >> work from home makes me remember writing cobol programs on a >> silent 700... my co-workers are helping me look at >> wait_for_cancellation_downcall... we recently made some >> improvements there based on some problems we were >> having in production with our out-of-tree Frankenstein >> module... I'm glad you are also looking there. > > BTW, what should happen to requests that got a buggered response in > orangefs_devreq_write_iter()? As it is, you just free them and to hell > with whatever might've been waiting on them; that's easy to fix, but > what about the submitter? Should we let it time out/simulate an error > properly returned by daemon/something else?