From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:58253 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932215AbcA3RWr (ORCPT ); Sat, 30 Jan 2016 12:22:47 -0500 Date: Sat, 30 Jan 2016 17:22:44 +0000 From: Al Viro To: Mike Marshall Cc: Linus Torvalds , linux-fsdevel Subject: Re: Orangefs ABI documentation Message-ID: <20160130172244.GD17997@ZenIV.linux.org.uk> References: <20160123001202.GJ17997@ZenIV.linux.org.uk> <20160123012808.GK17997@ZenIV.linux.org.uk> <20160123191055.GN17997@ZenIV.linux.org.uk> <20160123214006.GO17997@ZenIV.linux.org.uk> <20160124001615.GT17997@ZenIV.linux.org.uk> <20160124040529.GX17997@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Jan 24, 2016 at 05:12:30PM -0500, Mike Marshall wrote: > But in my tests, if I kill the client-core bad things happen... > sometimes the client-core doesn't restart, and the kernel gets > sick (hangs or slows way down but no oops). When the client-core > does restart, the activity I had going on (dbench again) fizzles out, > and the filesystem is corrupted... > Anyhow, I don't think the "restart the client-core" code is up to snuff . > > I'll look closer at how the out-of-tree module works, maybe it really > does work and we've broken it with our massive changes to the > upstream version over the last few years. I see that the client (whose > job it is to restart the client-core) and the client-core implement > signal handling with signal(2), whose man page says to use > sigaction(2) instead... Could you try this and see if either WARN_ON() actually triggers? diff --git a/fs/orangefs/file.c b/fs/orangefs/file.c index c585063d..e2ab0d4 100644 --- a/fs/orangefs/file.c +++ b/fs/orangefs/file.c @@ -246,10 +246,7 @@ populate_shared_memory: iter, new_op->downcall.resp.io.amt_complete); if (ret < 0) { - /* - * put error codes in downcall so that handle_io_error() - * preserves it properly - */ + WARN_ON(!op_state_serviced(new_op)); new_op->downcall.status = ret; handle_io_error(); goto out; diff --git a/fs/orangefs/waitqueue.c b/fs/orangefs/waitqueue.c index cdbf57b..191d886 100644 --- a/fs/orangefs/waitqueue.c +++ b/fs/orangefs/waitqueue.c @@ -205,6 +205,7 @@ retry_servicing: /* op uses shared memory */ if (orangefs_get_bufmap_init() == 0) { + WARN_ON(1); /* * This operation uses the shared memory system AND * the system is not yet ready. This situation occurs