From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: NeilBrown <neilb@suse.de>
Cc: mtk.manpages@gmail.com, Christoph Hellwig <hch@infradead.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
"linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Andreas Dilger <adilger@dilger.ca>
Subject: Re: For review: open_by_name_at(2) man page
Date: Wed, 19 Mar 2014 10:09:34 +0100 [thread overview]
Message-ID: <53295ECE.5020303@gmail.com> (raw)
In-Reply-To: <20140319092427.0812263c@notabene.brown>
Hi Neil,
On 03/18/2014 11:24 PM, NeilBrown wrote:
> On Tue, 18 Mar 2014 13:37:15 +0100 "Michael Kerrisk (man-pages)"
> <mtk.manpages@gmail.com> wrote:
>
>> On 03/18/2014 10:43 AM, Christoph Hellwig wrote:
>>> On Tue, Mar 18, 2014 at 09:00:07AM +1100, NeilBrown wrote:
>>>> ESTALE is also returned if the filesystem does not support file-handle ->
>>>> file mappings.
>>>> On filesystems which don't provide export_operations (/sys /proc ubifs
>>>> romfs cramfs nfs coda ... several others) name_to_handle_at will produce a
>>>> generic handle using the 32 bit inode and 32 bit i_generation.
>>>
>>> Do we? Seems like the code is erroring out early if there are no
>>> export_ops?
>>
>> It appears to me that Neil's statement isn't correct, at least for /proc
>> and /sys (see my other mail, to Neil). I'm unsure about whether it is true
>> for some of those other FSes thought.
>
>
> Indeed, I was wrong.
>
> I was looking at
>
> int exportfs_encode_inode_fh(struct inode *inode, struct fid *fid,
> int *max_len, struct inode *parent)
> {
> const struct export_operations *nop = inode->i_sb->s_export_op;
>
> if (nop && nop->encode_fh)
> return nop->encode_fh(inode, fid->raw, max_len, parent);
>
> return export_encode_fh(inode, fid, max_len, parent);
> }
>
>
> which uses a default if there is no 'nop'.
>
> However do_sys_name_to_handle() contains
>
> if (!path->dentry->d_sb->s_export_op ||
> !path->dentry->d_sb->s_export_op->fh_to_dentry)
> return -EOPNOTSUPP;
>
> long before export_encode_inode_fh() gets called. So the default isn't used.
Okay.
> I would have thought that exportfs_encode_inode_fh would never get called if
> there were no s_export_op pointer - certainly name_to_handle_at and nfsd
> would never call it in that case.
> However it seems that
>
> This routine will be used to generate a file handle in fdinfo output for
> inotify subsystem, where if no s_export_op present the general
> export_encode_fh should be used. Thus add a test if s_export_op present
> inside exportfs_encode_fh itself.
>
> according to
>
> commit ab49bdecc3ebb46ab661f5f05d5c5ea9606406c6
> Author: Cyrill Gorcunov <gorcunov@openvz.org>
> Date: Mon Dec 17 16:05:06 2012 -0800
>
>
> I guess that means that you can extract filehandles from /proc/self/fdinfo/$FD
> when $FD is an inotify fd which is watching the particular file..... I
> wouldn't have expected that, but maybe it is a good idea.
Yes, it does--I tested it, and it works! I was unaware of this feature,
though I'm not sure that I'll add anything to a man page just yet.
> So yes: if the filesystem doesn't support filehandles you get EOPNOTSUPP.
> So if you get ESTALE from open_by_handle_at(), then it really is a stale
> handle. Sorry for the confusion.
Yup, I've updated the page now.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2014-03-19 9:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-17 15:57 For review: open_by_name_at(2) man page Michael Kerrisk (man-pages)
2014-03-17 22:00 ` NeilBrown
2014-03-18 9:43 ` Christoph Hellwig
2014-03-18 12:37 ` Michael Kerrisk (man-pages)
[not found] ` <53283DFB.6040105-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-18 22:24 ` NeilBrown
2014-03-18 22:24 ` NeilBrown
2014-03-19 9:09 ` Michael Kerrisk (man-pages) [this message]
[not found] ` <20140318090007.3adee3d0-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2014-03-18 12:35 ` Michael Kerrisk (man-pages)
2014-03-18 12:35 ` Michael Kerrisk (man-pages)
2014-03-18 13:07 ` Christoph Hellwig
2014-03-18 13:30 ` Michael Kerrisk (man-pages)
2014-03-18 9:37 ` Christoph Hellwig
2014-03-18 12:41 ` Michael Kerrisk (man-pages)
2014-03-18 12:55 ` For review: open_by_name_at(2) man page [v2] Michael Kerrisk (man-pages)
[not found] ` <53284233.3050800-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-19 4:13 ` NeilBrown
2014-03-19 4:13 ` NeilBrown
[not found] ` <20140319151349.33a76023-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2014-03-19 9:09 ` Michael Kerrisk (man-pages)
2014-03-19 9:09 ` Michael Kerrisk (man-pages)
[not found] ` <53295ED0.7070304-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-19 14:14 ` For review: open_by_handle_at(2) man page [v3] Michael Kerrisk (man-pages)
2014-03-19 14:14 ` Michael Kerrisk (man-pages)
2014-03-19 6:42 ` For review: open_by_name_at(2) man page [v2] Mike Frysinger
2014-03-19 13:11 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53295ECE.5020303@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=adilger@dilger.ca \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.