From: "J. R. Okajima" <hooanon05g@gmail.com>
To: Mark Fasheh <mfasheh@suse.de>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Amir Goldstein <amir73il@gmail.com>,
linux-unionfs@vger.kernel.org, Jeff Mahoney <jeffm@suse.com>,
linux-nfs@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] vfs: map unique ino/dev pairs for user space
Date: Thu, 02 Aug 2018 09:24:27 +0900 [thread overview]
Message-ID: <30133.1533169467@jrobl> (raw)
In-Reply-To: <20180731211045.5671-1-mfasheh@suse.de>
Mark Fasheh:
> The following patches fix these inconsistencies by introducing a VFS helper
> function which calls the underlying filesystem ->getattr to get our real
> inode number / device pair. The returned values can then be used at those
> places in the kernel where we are incorrectly reporting our ino/dev pair.
> We then update fs/proc/ and fs/locks.c to use this helper when writing to
> /proc/PID/maps and /proc/locks respectively.
I definitly agree that ino/dev pair should be a unique identity on the
system. But I don't know why you are tryng to solve the problem in
generic VFS layer instead of the problematic FS. Isn't it an
unnecessary overhead for many FS?
How about creating a new f_op member ->get_ino_dev(), ->show_identity()
or something, and implement the new f_op in the problematic FS only?
I hope it will be a lighter way to get the pair than generic getattr
way.
J. R. Okajima
prev parent reply other threads:[~2018-08-02 2:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-31 21:10 [RFC PATCH 0/4] vfs: map unique ino/dev pairs for user space Mark Fasheh
2018-07-31 21:10 ` [PATCH 1/4] vfs: introduce function to map unique ino/dev pairs Mark Fasheh
2018-07-31 23:21 ` Mark Fasheh
2018-07-31 23:21 ` Mark Fasheh
2018-08-01 5:41 ` Amir Goldstein
2018-08-01 15:59 ` Mark Fasheh
2018-07-31 21:10 ` [PATCH 2/4] nfs: check for NULL vfsmount in nfs_getattr Mark Fasheh
2018-07-31 22:16 ` Al Viro
2018-07-31 22:51 ` Mark Fasheh
2018-08-02 0:43 ` Al Viro
2018-08-03 2:04 ` Mark Fasheh
2018-07-31 21:10 ` [PATCH 3/4] proc: use vfs helper to get ino/dev pairs for maps file Mark Fasheh
2018-07-31 21:10 ` [PATCH 4/4] locks: map correct ino/dev pairs when exporting to userspace Mark Fasheh
2018-08-01 5:37 ` Amir Goldstein
2018-08-01 17:45 ` Mark Fasheh
2018-08-01 11:03 ` Jeff Layton
2018-08-01 20:38 ` Mark Fasheh
2018-08-02 0:24 ` J. R. Okajima [this message]
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=30133.1533169467@jrobl \
--to=hooanon05g@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=jeffm@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=mfasheh@suse.de \
--cc=viro@ZenIV.linux.org.uk \
/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.