linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: dhowells@redhat.com, Al Viro <viro@zeniv.linux.org.uk>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	linux-afs@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 32/32] [RFC] fsinfo: Add a system call to allow querying of filesystem information [ver #8]
Date: Mon, 04 Jun 2018 20:03:55 +0100	[thread overview]
Message-ID: <472.1528139035@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAK8P3a0wecxxkjgmW3bv5v8_rJ6H5RZQ0QTvVhR2+cx7sBwxcA@mail.gmail.com>

Arnd Bergmann <arnd@arndb.de> wrote:

> > I've split the capabilities out into their own thing.  I've attached the
> > revised patch below.
>
> I'm still not completely clear on how variable-length structures are
> supposed to be handled by the fsinfo syscall. It seems like a possible
> source of bugs to return a structure from the kernel that has a different
> size in kernel and user space depending on the fsinfo_cap__nr value at
> compile time. How does one e.g. guarantee there is no out of bounds access
> when you run new user space on an older kernel that has a smaller structure?

There's a buffer size parameter:

	int ret = fsinfo(int dfd,
			 const char *filename,
			 const struct fsinfo_params *params,
			 void *buffer,
			 size_t buf_size);

For a fixed-size buffer request (as opposed to a string), the fsinfo syscall
allocates an internal buffer sized for the size of the buffer that the
internal kernel code is expecting, and *not* what the user asked for:

	/* Allocate an appropriately-sized buffer.  We will truncate the
	 * contents when we write the contents back to userspace.
	 */
	size = fsinfo_buffer_sizes[params.request];
	...
	if (buf_size > 0) {
		params.buf_size = size;
		params.buffer = kzalloc(size, GFP_KERNEL);
		if (!params.buffer)
			return -ENOMEM;
	}

so that the filesystems don't have to concern themselves with anything other
than the kernel's idea of the size.

The fsinfo() syscall truncates the reply buffer to the size the user requested
if the user requested a smaller amount.  Take the fsinfo_supports struct for
example:

	struct fsinfo_supports {
		__u64	supported_stx_attributes;
		__u32	supported_stx_mask;
		__u32	supported_ioc_flags;
	};

Now imagine that in future we want to add another field, say the mask of the
windows file attributes a filesystem supports.  We can extend the struct like
so:

	struct fsinfo_supports_v2 {
		__u64	supported_stx_attributes;
		__u32	supported_stx_mask;
		__u32	supported_ioc_flags;
		__u32	supported_win_file_atts;
		__u32	__reserved[1];
	};

Note that the start of the new struct *must* correspond in layout to the
original struct.  An application that doesn't know about v2 would just ask for
v1:

	struct fsinfo_supports foo;
	fsinfo(.... &foo, sizeof(foo));

and would only ever get those bits - though it would be told that there is
more data available.  An application that does know about v2 might do:

	struct fsinfo_supports_v2 foo2;
	fsinfo(.... &foo2, sizeof(foo2));

If all of v2 was available, all fields will be filled in and the return value
will == sizeof(foo2).  If not all fields are available, the return value will
== sizeof(foo).  If a v3 was added, the return value would == sizeof(v3), and
so on.

I can improve this such that if you asked for a fixed-length option and the
kernel doesn't have enough data to fill the user buffer provided, then it
clears the remainder of the buffer.  That way at least any unsupported fields
will be initialised to 0.


For the capabilities bitmask, it's not really any different conceptually.  If
you want to test capability bit 47, you need to ask for 6 bytes of data.  If
the kernel doesn't support that many bits, it won't necessarily give you that
many bytes.  If it has, say, 13 bytes-worth of caps available, it will only
give you the first 6 bytes-worth if that's all you ask for.  You presumably
weren't interested or didn't know about any more than that.


As for strings, they're completely variable length anyway, so I don't think
there's a problem there.

> In any case, it would be nice to have a trivial way to query which of
> the four timestamp types are supported at all, and returning
> them separately would be one way of doing that.

	fsinfo_cap_has_atime	= 45,	/* fs supports access time */
	fsinfo_cap_has_btime	= 46,	/* fs supports birth/creation time */
	fsinfo_cap_has_ctime	= 47,	/* fs supports change time */
	fsinfo_cap_has_mtime	= 48,	/* fs supports modification time */

David

  parent reply	other threads:[~2018-06-04 19:03 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-25  0:05 [PATCH 00/32] VFS: Introduce filesystem context [ver #8] David Howells
2018-05-25  0:05 ` [PATCH 01/32] VFS: Suppress MS_* flag defs within the kernel unless explicitly enabled " David Howells
2018-05-25  0:05 ` [PATCH 02/32] vfs: Provide documentation for new mount API " David Howells
2018-05-25  0:05 ` [PATCH 03/32] VFS: Introduce the basic header for the new mount API's filesystem context " David Howells
2018-05-31 23:11   ` Al Viro
2018-05-31 23:13   ` Al Viro
2018-05-25  0:05 ` [PATCH 04/32] VFS: Add LSM hooks for the new mount API " David Howells
2018-05-25  0:05 ` [PATCH 05/32] selinux: Implement the new mount API LSM hooks " David Howells
2018-05-25  0:06 ` [PATCH 06/32] smack: Implement filesystem context security " David Howells
2018-05-25  0:06 ` [PATCH 07/32] apparmor: Implement security hooks for the new mount API " David Howells
2018-05-25  0:06 ` [PATCH 08/32] tomoyo: " David Howells
2018-05-25  0:06 ` [PATCH 09/32] VFS: Require specification of size of mount data for internal mounts " David Howells
2018-05-25  0:06 ` [PATCH 10/32] VFS: Implement a filesystem superblock creation/configuration context " David Howells
2018-06-07 19:50   ` Miklos Szeredi
2018-07-03 18:33   ` Eric Biggers
2018-07-03 21:53   ` David Howells
2018-07-03 21:58     ` Al Viro
2018-07-03 22:06     ` David Howells
2018-05-25  0:06 ` [PATCH 11/32] VFS: Remove unused code after filesystem context changes " David Howells
2018-05-25  0:06 ` [PATCH 12/32] procfs: Move proc_fill_super() to fs/proc/root.c " David Howells
2018-05-25  0:06 ` [PATCH 13/32] proc: Add fs_context support to procfs " David Howells
2018-05-25  0:06 ` [PATCH 14/32] ipc: Convert mqueue fs to fs_context " David Howells
2018-05-25  0:07 ` [PATCH 15/32] cpuset: Use " David Howells
2018-05-25  0:07 ` [PATCH 16/32] kernfs, sysfs, cgroup, intel_rdt: Support " David Howells
2018-06-21 18:47   ` [16/32] " Andrei Vagin
2018-06-22 12:52   ` David Howells
2018-06-22 15:30     ` Andrei Vagin
2018-06-22 16:57       ` Andrei Vagin
2018-06-23 23:34       ` David Howells
2018-05-25  0:07 ` [PATCH 17/32] hugetlbfs: Convert to " David Howells
2018-05-25  0:07 ` [PATCH 18/32] VFS: Remove kern_mount_data() " David Howells
2018-05-25  0:07 ` [PATCH 19/32] VFS: Implement fsopen() to prepare for a mount " David Howells
2018-05-31 21:25   ` Al Viro
2018-05-25  0:07 ` [PATCH 20/32] vfs: Make close() unmount the attached mount if so flagged " David Howells
2018-05-31 19:19   ` Al Viro
2018-05-31 19:26     ` Al Viro
2018-06-01  1:52     ` Al Viro
2018-06-01  3:18       ` Al Viro
2018-06-01  5:16         ` Al Viro
2018-05-25  0:07 ` [PATCH 21/32] VFS: Implement fsmount() to effect a pre-configured mount " David Howells
2018-06-04 15:05   ` Arnd Bergmann
2018-06-04 15:24   ` David Howells
2018-05-25  0:07 ` [PATCH 22/32] vfs: Provide an fspick() system call " David Howells
2018-05-25  0:07 ` [PATCH 23/32] VFS: Implement logging through fs_context " David Howells
2018-05-25  1:48   ` Joe Perches
2018-05-25  0:07 ` [PATCH 24/32] vfs: Add some logging to the core users of the fs_context log " David Howells
2018-05-25  0:08 ` [PATCH 25/32] afs: Add fs_context support " David Howells
2018-05-25  0:08 ` [PATCH 26/32] afs: Use fs_context to pass parameters over automount " David Howells
2018-06-07  1:58   ` Goldwyn Rodrigues
2018-06-07 20:45   ` David Howells
2018-05-25  0:08 ` [PATCH 27/32] vfs: Use a 'struct fd_cookie *' type for light fd handling " David Howells
2018-05-25  0:08 ` [PATCH 28/32] vfs: Store the fd_cookie in nameidata, not the dfd int " David Howells
2018-05-25  0:08 ` [PATCH 29/32] vfs: Don't mix FMODE_* flags with O_* flags " David Howells
2018-05-25  0:08 ` [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) " David Howells
2018-06-01  6:26   ` Christoph Hellwig
2018-06-01  6:39     ` Al Viro
2018-06-01  8:27     ` David Howells
2018-06-02  3:09       ` Al Viro
2018-06-02  3:42         ` Al Viro
2018-06-02  4:04           ` Al Viro
2018-06-02 15:45           ` David Howells
2018-06-02 17:49             ` Al Viro
2018-06-03  0:55               ` [PATCH][RFC] open_tree(2) (was Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8]) Al Viro
2018-06-04 10:34                 ` Miklos Szeredi
2018-06-04 15:52                   ` Al Viro
2018-06-04 15:59                     ` Al Viro
2018-06-04 19:27                     ` Miklos Szeredi
2018-06-04 15:27                 ` David Howells
2018-06-04 17:16                 ` Matthew Wilcox
2018-06-04 17:35                   ` Al Viro
2018-06-04 19:38                     ` Miklos Szeredi
2018-06-01  8:02   ` [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8] Amir Goldstein
2018-06-01  8:42   ` David Howells
2018-05-25  0:08 ` [PATCH 31/32] [RFC] fs: Add a move_mount() system call " David Howells
2018-05-31 21:20   ` Al Viro
2018-05-25  0:08 ` [PATCH 32/32] [RFC] fsinfo: Add a system call to allow querying of filesystem information " David Howells
2018-06-04 13:10   ` Arnd Bergmann
2018-06-04 15:01   ` David Howells
2018-06-04 16:00     ` Arnd Bergmann
2018-06-04 19:03     ` David Howells [this message]
2018-06-04 20:45       ` Arnd Bergmann
2018-05-31 20:56 ` Test program for move_mount() David Howells
2018-05-31 20:57 ` fsinfo test program David Howells
2018-06-15  4:18 ` [PATCH 00/32] VFS: Introduce filesystem context [ver #8] Eric W. Biederman
2018-06-18 20:30 ` David Howells
2018-06-18 21:33   ` Eric W. Biederman
2018-06-18 23:33   ` Theodore Y. Ts'o

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=472.1528139035@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=arnd@arndb.de \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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).