All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2 01/18] vfs: add miscattr ops
Date: Wed, 24 Mar 2021 05:02:11 +0000	[thread overview]
Message-ID: <YFrH098Tbbezg2hI@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <20210322144916.137245-2-mszeredi@redhat.com>

On Mon, Mar 22, 2021 at 03:48:59PM +0100, Miklos Szeredi wrote:

minor nit: copy_fsxattr_{to,from}_user() might be better.

> +int fsxattr_copy_to_user(const struct miscattr *ma, struct fsxattr __user *ufa)
> +{
> +	struct fsxattr fa = {
> +		.fsx_xflags	= ma->fsx_xflags,
> +		.fsx_extsize	= ma->fsx_extsize,
> +		.fsx_nextents	= ma->fsx_nextents,
> +		.fsx_projid	= ma->fsx_projid,
> +		.fsx_cowextsize	= ma->fsx_cowextsize,
> +	};

That wants a comment along the lines of "guaranteed to be gap-free",
since otherwise you'd need memset() to avoid an infoleak.

> +static int ioctl_getflags(struct file *file, void __user *argp)
> +{
> +	struct miscattr ma = { .flags_valid = true }; /* hint only */
> +	unsigned int flags;
> +	int err;
> +
> +	err = vfs_miscattr_get(file_dentry(file), &ma);

Umm...  Just to clarify - do we plan to have that ever called via
ovl_real_ioctl()?  IOW, is file_dentry() anything other than a way
to spell ->f_path.dentry here?

> +struct miscattr {
> +	u32	flags;		/* flags (FS_IOC_GETFLAGS/FS_IOC_SETFLAGS) */
> +	/* struct fsxattr: */
> +	u32	fsx_xflags;	/* xflags field value (get/set) */
> +	u32	fsx_extsize;	/* extsize field value (get/set)*/
> +	u32	fsx_nextents;	/* nextents field value (get)	*/
> +	u32	fsx_projid;	/* project identifier (get/set) */
> +	u32	fsx_cowextsize;	/* CoW extsize field value (get/set)*/
> +	/* selectors: */
> +	bool	flags_valid:1;
> +	bool	xattr_valid:1;
> +};

OK as long as it stays kernel-only, but if we ever expose that to userland, we'd
better remember to turn the last two into an u32 with explicit bitmasks.

  parent reply	other threads:[~2021-03-24  5:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22 14:48 [PATCH v2 00/18] new kAPI for FS_IOC_[GS]ETFLAGS/FS_IOC_FS[GS]ETXATTR Miklos Szeredi
2021-03-22 14:48 ` [PATCH v2 01/18] vfs: add miscattr ops Miklos Szeredi
2021-03-22 22:33   ` Darrick J. Wong
2021-03-23  5:21     ` Amir Goldstein
2021-03-23 11:22     ` David Sterba
2021-03-24  8:06     ` Christian Brauner
2021-03-24  5:02   ` Al Viro [this message]
2021-03-24  8:45     ` Miklos Szeredi
2021-03-24 12:26       ` Al Viro
2021-03-24 13:45         ` Miklos Szeredi
2021-03-24  8:21   ` Christian Brauner
2021-03-22 14:49 ` [PATCH v2 02/18] ecryptfs: stack " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 03/18] ovl: " Miklos Szeredi
2021-03-24  5:09   ` Al Viro
2021-03-24  5:18     ` Al Viro
2021-03-22 14:49 ` [PATCH v2 04/18] btrfs: convert to miscattr Miklos Szeredi
2021-03-23 11:41   ` David Sterba
2021-03-22 14:49 ` [PATCH v2 05/18] ext2: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 06/18] ext4: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 07/18] f2fs: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 08/18] gfs2: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 09/18] orangefs: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 10/18] xfs: " Miklos Szeredi
2021-03-22 22:51   ` Darrick J. Wong
2021-03-22 14:49 ` [PATCH v2 11/18] efivars: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 12/18] hfsplus: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 13/18] jfs: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 14/18] nilfs2: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 15/18] ocfs2: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 16/18] reiserfs: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 17/18] ubifs: " Miklos Szeredi
2021-03-22 14:49 ` [PATCH v2 18/18] vfs: remove unused ioctl helpers Miklos Szeredi
2021-03-22 22:51   ` Darrick J. Wong

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=YFrH098Tbbezg2hI@zeniv-ca.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mszeredi@redhat.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 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.