From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:44097 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1947555AbcBRUtx (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 18 Feb 2016 15:49:53 -0500
Date: Thu, 18 Feb 2016 20:49:48 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mike Marshall <hubcap@omnibond.com>
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>
Subject: Re: Orangefs ABI documentation
Message-ID: <20160218204948.GV17997@ZenIV.linux.org.uk>
References: <CAOg9mSR0QZOy-JAesN32o51omxdOQyfUh-Zj8k7ZohKLaa3GxQ@mail.gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOg9mST9mPefWaWNqXieuQQeLdLDXOtS3atk_+JzJXX9G6b+gg@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Feb 18, 2016 at 03:22:33PM -0500, Mike Marshall wrote:
> I haven't edited up a list of how the debug output looked,
> but most importantly: the WARN_ON is hit... it appears that
> the client-core is sending over fsid:0:

OK, that's a bit of relief...  The next question, of course, is whether it's
a genuine reply or buggered attempt to copy it from userland and/or something
stomping on that memory.

It should've come from package_downcall_members(), right?  And there you
have this:
                if (*error_code == -PVFS_EEXIST)
                {
                    PVFS_hint hints;
                    PVFS_credential *credential;

                    fill_hints(&hints, vfs_request);

                    credential = lookup_credential(
                        vfs_request->in_upcall.uid,
                        vfs_request->in_upcall.gid);

                    /* compat */
                    refn1.handle =
                     pvfs2_khandle_to_ino(
                      &(vfs_request->in_upcall.req.create.parent_refn.khandle));
                    refn1.fs_id =
                      vfs_request->in_upcall.req.create.parent_refn.fs_id;
                    refn1.__pad1 =
                      vfs_request->in_upcall.req.create.parent_refn.__pad1;


//hubcap            vfs_request->out_downcall.resp.create.refn =
                    refn2 =
                      perform_lookup_on_create_error(

And AFAICS nothing in there sets resp.create.refn.  Is it actually set
earlier?