From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-lb0-f177.google.com ([209.85.217.177]:36314 "EHLO
	mail-lb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754614AbcAWTYx (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Sat, 23 Jan 2016 14:24:53 -0500
Received: by mail-lb0-f177.google.com with SMTP id oh2so56598665lbb.3
        for <linux-fsdevel@vger.kernel.org>; Sat, 23 Jan 2016 11:24:52 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <20160123191055.GN17997@ZenIV.linux.org.uk>
References: <20160122174338.GA17997@ZenIV.linux.org.uk>
	<CAOg9mSSL2vtehQd6r-bmxK+zdDdwudJSXMmX2HBscm3cW_sp9A@mail.gmail.com>
	<20160122183720.GB17997@ZenIV.linux.org.uk>
	<CAOg9mSTCkr5_or_VSOHnNSsVqd5S=ENuGYBsJkgitqgworN9Eg@mail.gmail.com>
	<CAOg9mSRoEFvFkdJmEmFOO_ErT7X3Q51=X=HP5Li6g-dVFANOOg@mail.gmail.com>
	<20160122200442.GF17997@ZenIV.linux.org.uk>
	<CAOg9mSTPbx0231RoERbbdeyR+nDCD4wGHHFKAzxmowai8GtNgg@mail.gmail.com>
	<20160123001202.GJ17997@ZenIV.linux.org.uk>
	<20160123012808.GK17997@ZenIV.linux.org.uk>
	<CAOg9mST8rpzSs4FGB=7yiGJ2PZBqw2s=H1ozQBiWjDF232ZnhQ@mail.gmail.com>
	<20160123191055.GN17997@ZenIV.linux.org.uk>
Date: Sat, 23 Jan 2016 14:24:51 -0500
Message-ID: <CAOg9mSR667SdVvR323MOaqEs0DVGKcxr8e0tyx=Bu_=ENops0g@mail.gmail.com>
Subject: Re: Orangefs ABI documentation
From: Mike Marshall <hubcap@omnibond.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

OK, I'll get them momentarily...

I merged your other patches, and there was a merge
conflict I had to work around... you're working from
an orangefs tree that lacks one commit I had made
last week... my linux-next tree has all your patches
through yesterday in it now...

I am setting up "the gnarly test" (at home from a VM,
though) that should cause a bunch of cancellations,
I want to see if I can get
wait_for_cancellation_downcall to ever
flow past that "if (signal_pending(current)) {"
block... if it does, that demonstrate where
the comments conflict with the code, right?

-Mike

On Sat, Jan 23, 2016 at 2:10 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Jan 22, 2016 at 09:54:48PM -0500, Mike Marshall wrote:
>> Well... that all seems awesome, and compiled the first
>> time and all my quick tests on my dinky vm make
>> it seem fine... It is Becky that recently spent a
>> bunch of time fighting the cancellation dragons,
>> I'll see if I can't get her to weigh in on
>> wait_for_cancellation_downcall tomorrow.
>>
>> We have some gnarly tests we were running on
>> real hardware that helped reproduce the problems
>> she was seeing in production with Clemson's
>> Palmetto Cluster, I'll run them, but maybe not
>> until Monday with the ice storm...
>
> OK, several more pushed.  The most interesting part is probably switch
> to real completions - you'd been open-coding them for no good reason
> (and as always with reinventing locking primitives, asking for trouble).
>
> New bits just as untested as the earlier ones, of course...