From: Richard Weinberger <richard.weinberger@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Richard Weinberger <richard@nod.at>,
linux-mtd@lists.infradead.org, kernel@pengutronix.de,
Jan Kara <jack@suse.com>
Subject: Re: [PATCH 3/7] ubifs: Add support for FS_IOC_FS[SG]ETXATTR ioctls
Date: Sun, 19 Jan 2020 20:55:59 +0100 [thread overview]
Message-ID: <CAFLxGvxbcMF1S=Ghmi2rH4-ecEPRtVPAS7LrRq5eX=Q6S4PMHg@mail.gmail.com> (raw)
In-Reply-To: <20191106091537.32480-4-s.hauer@pengutronix.de>
On Wed, Nov 6, 2019 at 10:16 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> The FS_IOC_FS[SG]ETXATTR ioctls are an alternative to FS_IOC_[GS]ETFLAGS
> with additional features. This patch adds support for these ioctls.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> fs/ubifs/ioctl.c | 103 ++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 98 insertions(+), 5 deletions(-)
>
> diff --git a/fs/ubifs/ioctl.c b/fs/ubifs/ioctl.c
> index 8230dba5fd74..533df56beab4 100644
> --- a/fs/ubifs/ioctl.c
> +++ b/fs/ubifs/ioctl.c
> @@ -95,9 +95,46 @@ static int ubifs2ioctl(int ubifs_flags)
> return ioctl_flags;
> }
>
> -static int setflags(struct file *file, int flags)
> +/* Transfer xflags flags to internal */
> +static inline unsigned long ubifs_xflags_to_iflags(__u32 xflags)
Why inline? gcc should be smart enough to inline the function automatically
if needed.
> {
> - int oldflags, err, release;
> + unsigned long iflags = 0;
> +
> + if (xflags & FS_XFLAG_SYNC)
> + iflags |= UBIFS_APPEND_FL;
Shouldn't this be UBIFS_SYNC_FL?
> + if (xflags & FS_XFLAG_IMMUTABLE)
> + iflags |= UBIFS_IMMUTABLE_FL;
> + if (xflags & FS_XFLAG_APPEND)
> + iflags |= UBIFS_APPEND_FL;
> +
> + return iflags;
> +}
> +
> +/* Transfer internal flags to xflags */
> +static inline __u32 ubifs_iflags_to_xflags(unsigned long flags)
Same.
> +{
> + __u32 xflags = 0;
> +
> + if (flags & UBIFS_APPEND_FL)
> + xflags |= FS_XFLAG_SYNC;
> + if (flags & UBIFS_IMMUTABLE_FL)
> + xflags |= FS_XFLAG_IMMUTABLE;
> + if (flags & UBIFS_APPEND_FL)
> + xflags |= FS_XFLAG_APPEND;
> +
> + return xflags;
> +}
> +
> +static void ubifs_fill_fsxattr(struct inode *inode, struct fsxattr *fa)
> +{
> + struct ubifs_inode *ui = ubifs_inode(inode);
> +
> + simple_fill_fsxattr(fa, ubifs_iflags_to_xflags(ui->flags));
> +}
> +
> +static int setflags(struct file *file, int flags, struct fsxattr *fa)
> +{
> + int ubi_flags, oldflags, err, release;
> struct inode *inode = file_inode(file);
> struct ubifs_inode *ui = ubifs_inode(inode);
> struct ubifs_info *c = inode->i_sb->s_fs_info;
> @@ -110,6 +147,11 @@ static int setflags(struct file *file, int flags)
> if (!inode_owner_or_capable(inode))
> return -EACCES;
>
> + if (fa)
> + ubi_flags = ubifs_xflags_to_iflags(fa->fsx_xflags);
> + else
> + ubi_flags = ioctl2ubifs(flags);
> +
So having both flags and fa set is not allowed?
Can we please have an ubifs_assert() to catch this.
--
Thanks,
//richard
next prev parent reply other threads:[~2020-01-19 19:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 9:15 [PATCH v3 0/7] Add quota support to UBIFS Sascha Hauer
2019-11-06 9:15 ` [PATCH 1/7] quota: Allow to pass mount path to quotactl Sascha Hauer
2019-11-06 10:05 ` Jan Kara
2019-11-06 10:15 ` Sascha Hauer
2019-11-06 9:15 ` [PATCH 2/7] ubifs: move checks and preparation into setflags() Sascha Hauer
2020-01-19 19:56 ` Richard Weinberger
2019-11-06 9:15 ` [PATCH 3/7] ubifs: Add support for FS_IOC_FS[SG]ETXATTR ioctls Sascha Hauer
2020-01-19 19:55 ` Richard Weinberger [this message]
2019-11-06 9:15 ` [PATCH 4/7] ubifs: do not ubifs_inode() on potentially NULL pointer Sascha Hauer
2020-01-19 19:58 ` Richard Weinberger
2019-11-06 9:15 ` [PATCH 5/7] ubifs: Add support for project id Sascha Hauer
2020-01-19 20:09 ` Richard Weinberger
2020-01-24 8:05 ` Sascha Hauer
2019-11-06 9:15 ` [PATCH 6/7] ubifs: export get_znode Sascha Hauer
2019-11-06 9:15 ` [PATCH 7/7] ubifs: Add quota support Sascha Hauer
2019-11-06 10:14 ` Jan Kara
2019-11-11 8:57 ` Sascha Hauer
2019-11-11 16:34 ` Jan Kara
2019-11-12 8:59 ` Sascha Hauer
2019-11-12 9:31 ` Jan Kara
2019-11-08 14:47 ` kbuild test robot
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='CAFLxGvxbcMF1S=Ghmi2rH4-ecEPRtVPAS7LrRq5eX=Q6S4PMHg@mail.gmail.com' \
--to=richard.weinberger@gmail.com \
--cc=jack@suse.com \
--cc=kernel@pengutronix.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=s.hauer@pengutronix.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 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).