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?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
