From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-lf0-f51.google.com ([209.85.215.51]:34397 "EHLO
	mail-lf0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753790AbcBRVuN (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 18 Feb 2016 16:50:13 -0500
Received: by mail-lf0-f51.google.com with SMTP id j78so41861763lfb.1
        for <linux-fsdevel@vger.kernel.org>; Thu, 18 Feb 2016 13:50:12 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <20160218205206.GW17997@ZenIV.linux.org.uk>
References: <alpine.BSO.2.20.1602171722490.29280@server1.sysblue.org>
	<20160217230900.GP17997@ZenIV.linux.org.uk>
	<20160217231524.GQ17997@ZenIV.linux.org.uk>
	<20160218000439.GR17997@ZenIV.linux.org.uk>
	<20160218111122.GS17997@ZenIV.linux.org.uk>
	<CAOg9mSS11uSvfBkNYPeNBw8xMebvHAM3vzh82BH=W273-7oNyg@mail.gmail.com>
	<alpine.BSO.2.20.1602181449280.29280@server1.sysblue.org>
	<CAOg9mSSRebK0WMQHVD3Ne7R0+sdzO+o-mJcxX626X6UzEFsPpg@mail.gmail.com>
	<CAOg9mST9mPefWaWNqXieuQQeLdLDXOtS3atk_+JzJXX9G6b+gg@mail.gmail.com>
	<CAOg9mSRWeNV_DbRw1Zn2XzwW+7ORWcYLj85P-3rvZ0YisLzT9g@mail.gmail.com>
	<20160218205206.GW17997@ZenIV.linux.org.uk>
Date: Thu, 18 Feb 2016 16:50:11 -0500
Message-ID: <CAOg9mSQQCATxLS0qoKrs-k3HktquBtNRQsCA6ePeDSyW-cT2bg@mail.gmail.com>
Subject: Re: Orangefs ABI documentation
From: Mike Marshall <hubcap@omnibond.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Martin Brandenburg <martin@omnibond.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Content-Type: text/plain; charset=UTF-8
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

As part of the attempt to go upstream, this "hubcap" guy you see
in the comments worked on a thing that changes 64bit userspace handles
back and forth into 128bit kernel handles... we did this because
one day, when we have orangefs3, we will be using 128bit uuid-derived
handles, and we believe it is our responsibility to not break the
upstream kernel module.

Anywho, I bet you are right Al, he messed up this part of it...
I'll look and see if that is really so, and get it fixed.

-Mike "hubcap"

On Thu, Feb 18, 2016 at 3:52 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Thu, Feb 18, 2016 at 03:38:26PM -0500, Mike Marshall wrote:
>> WARNING: CPU: 0 PID: 1216 at fs/orangefs/devorangefs-req.c:423
>> set_op_state_serviced: op:ffff880011078000: process:pvfs2-client-co state -> 4
>> service_operation: wait_for_matching_downcall returned 0 for ffff880011078000
>> service_operation orangefs_create returning: 0 for ffff880011078000
>> orangefs_create: BENCHS.LWP:
>> handle:00000000-0000-0000-0000-000000000000: fsid:0:
>> new_op:ffff880011078000: ret:0:
>
> Smells like retry hitting EEXIST and package_downcall_members() treatment of
> that case doesn't set create.refn at all - used to, but that code is commented
> out.