From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH 2/2] exportfs: fix 32-bit nfsd handling of 64-bit inode numbers Date: Fri, 4 Oct 2013 18:15:23 -0400 Message-ID: <20131004221522.GD18051@fieldses.org> References: <20131002210736.GA20598@fieldses.org> <1380749295-20854-1-git-send-email-bfields@redhat.com> <1380749295-20854-2-git-send-email-bfields@redhat.com> <20131004221216.GC18051@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , Christoph Hellwig , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sandeen-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org To: "J. Bruce Fields" Return-path: Content-Disposition: inline In-Reply-To: <20131004221216.GC18051-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Oct 04, 2013 at 06:12:16PM -0400, bfields wrote: > On Wed, Oct 02, 2013 at 05:28:14PM -0400, J. Bruce Fields wrote: > > @@ -268,6 +268,16 @@ static int get_name(const struct path *path, char *name, struct dentry *child) > > if (!dir->i_fop) > > goto out; > > /* > > + * inode->i_ino is unsigned long, kstat->ino is u64, so the > > + * former would be insufficient on 32-bit hosts when the > > + * filesystem supports 64-bit inode numbers. So we need to > > + * actually call ->getattr, not just read i_ino: > > + */ > > + error = vfs_getattr_nosec(path, &stat); > > Doh, "path" here is for the parent.... The following works better! By the way, I'm testing this with: - create a bunch of nested subdirectories, use name_to_fhandle_at to get a handle for the bottom directory. - echo 2 >/proc/sys/vm/drop_caches - open_by_fhandle_at on the filehandle But this only actually exercises the reconnect path on the first run after boot. Is there something obvious I'm missing here? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html