From: Andrew Morton <akpm@linux-foundation.org>
To: Shaohua Li <shaohua.li@intel.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Chris Mason <chris.mason@oracle.com>,
Christoph Hellwig <hch@infradead.org>,
Arjan van de Ven <arjan@infradead.org>,
"Yan, Zheng" <zheng.z.yan@linux.intel.com>,
"Wu, Fengguang" <fengguang.wu@intel.com>,
linux-api <linux-api@vger.kernel.org>,
manpages <mtk.manpages@gmail.com>
Subject: Re: [PATCH v3 1/5] add metadata_incore ioctl in vfs
Date: Wed, 19 Jan 2011 12:41:58 -0800 [thread overview]
Message-ID: <20110119124158.b0348c44.akpm@linux-foundation.org> (raw)
In-Reply-To: <1295399718.1949.864.camel@sli10-conroe>
On Wed, 19 Jan 2011 09:15:18 +0800
Shaohua Li <shaohua.li@intel.com> wrote:
> Subject: add metadata_incore ioctl in vfs
>
> Add an ioctl to dump filesystem's metadata in memory in vfs. Userspace collects
> such info and uses it to do metadata readahead.
> Filesystem can hook to super_operations.metadata_incore to get metadata in
> specific approach. Next patch will give an example how to implement
> .metadata_incore in btrfs.
>
> ...
>
> /*
> + * Copy info about metadata in memory to userspace
> + * Returns:
> + * = 1, one metadata range copied to userspace
> + * = 0, no more metadata
> + * < 0, error
> + */
> +static int ioctl_metadata_incore(struct file *filp, void __user *argp)
> +{
> + struct super_block *sb = filp->f_path.dentry->d_inode->i_sb;
> + struct metadata_incore_args args;
> + loff_t offset;
> + ssize_t size;
> +
> + if (!sb->s_op->metadata_incore)
> + return -EINVAL;
> +
> + if (copy_from_user(&args, argp, sizeof(args)))
> + return -EFAULT;
> +
> + /* we check metadata info in page unit */
> + if (args.offset & ~PAGE_CACHE_MASK)
> + return -EINVAL;
> +
> + offset = args.offset;
> +
> + if (sb->s_op->metadata_incore(sb, &offset, &size) < 0)
> + return 0;
> +
> + args.address = offset;
> + args.size = size;
> + args.unused = 0;
> +
> + if (copy_to_user(argp, &args, sizeof(args)))
> + return -EFAULT;
> +
> + return 1;
> +}
So userspace opens any file on the fs and runs this ioctl against it?
That's a pretty awkward interface - we're doing an fs-wide operation
but the fs is identified by a single file which happens to live on that
fs. For example, this precludes a future extension whereby userspace
can query the incore metadata for a particular file. The statfs
syscall sucks in the same manner.
I don't know if this is worth addressing. Perhaps require that the
filp refers to the root of the fs?
Also, is this a privileged operation? If not, then that might be a
problem - could it be used by unprivileged users to work out which
files have been opened recently or something like that?
next prev parent reply other threads:[~2011-01-19 20:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-19 1:15 [PATCH v3 1/5] add metadata_incore ioctl in vfs Shaohua Li
2011-01-19 20:41 ` Andrew Morton [this message]
[not found] ` <20110119124158.b0348c44.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2011-01-20 2:30 ` Shaohua Li
2011-01-20 2:42 ` Andrew Morton
2011-01-20 2:48 ` Shaohua Li
2011-01-20 3:05 ` Andrew Morton
[not found] ` <20110119190548.e1f7f01f.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2011-01-20 3:21 ` Shaohua Li
2011-01-20 4:10 ` Andrew Morton
2011-01-20 4:41 ` Dave Chinner
2011-01-20 5:44 ` Shaohua Li
2011-01-20 6:06 ` Wu Fengguang
2011-01-24 4:29 ` Dave Chinner
[not found] ` <20110119201014.adf02a78.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2011-01-20 5:38 ` Shaohua Li
2011-01-20 5:55 ` Andrew Morton
[not found] ` <20110119215510.0882db92.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2011-01-20 6:12 ` Shaohua Li
2011-01-20 6:19 ` Wu Fengguang
2011-01-20 6:29 ` Andrew Morton
2011-01-20 6:37 ` Shaohua Li
2011-01-20 6:45 ` Wu Fengguang
2011-01-20 6:27 ` Andrew Morton
[not found] ` <20110119222740.fb1b5229.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2011-01-24 10:06 ` Boaz Harrosh
2011-01-20 5:46 ` Wu Fengguang
2011-01-20 5:55 ` Wu Fengguang
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=20110119124158.b0348c44.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=chris.mason@oracle.com \
--cc=fengguang.wu@intel.com \
--cc=hch@infradead.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=shaohua.li@intel.com \
--cc=zheng.z.yan@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).