From: Eric Biggers <ebiggers@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Satya Tangirala <satyat@google.com>,
linux-fsdevel@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 1/4] fs: introduce SB_INLINECRYPT
Date: Wed, 17 Jun 2020 20:19:35 -0700 [thread overview]
Message-ID: <20200618031935.GE1138@sol.localdomain> (raw)
In-Reply-To: <20200618011912.GA2040@dread.disaster.area>
On Thu, Jun 18, 2020 at 11:19:12AM +1000, Dave Chinner wrote:
> On Wed, Jun 17, 2020 at 07:57:29AM +0000, Satya Tangirala wrote:
> > Introduce SB_INLINECRYPT, which is set by filesystems that wish to use
> > blk-crypto for file content en/decryption. This flag maps to the
> > '-o inlinecrypt' mount option which multiple filesystems will implement,
> > and code in fs/crypto/ needs to be able to check for this mount option
> > in a filesystem-independent way.
> >
> > Signed-off-by: Satya Tangirala <satyat@google.com>
> > ---
> > fs/proc_namespace.c | 1 +
> > include/linux/fs.h | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/fs/proc_namespace.c b/fs/proc_namespace.c
> > index 3059a9394c2d..e0ff1f6ac8f1 100644
> > --- a/fs/proc_namespace.c
> > +++ b/fs/proc_namespace.c
> > @@ -49,6 +49,7 @@ static int show_sb_opts(struct seq_file *m, struct super_block *sb)
> > { SB_DIRSYNC, ",dirsync" },
> > { SB_MANDLOCK, ",mand" },
> > { SB_LAZYTIME, ",lazytime" },
> > + { SB_INLINECRYPT, ",inlinecrypt" },
> > { 0, NULL }
> > };
> > const struct proc_fs_opts *fs_infop;
>
> NACK.
>
> SB_* flgs are for functionality enabled on the superblock, not for
> indicating mount options that have been set by the user.
That's an interesting claim, given that most SB_* flags are for mount options.
E.g.:
ro => SB_RDONLY
nosuid => SB_NOSUID
nodev => SB_NODEV
noexec => SB_NOEXEC
sync => SB_SYNCHRONOUS
mand => SB_MANDLOCK
noatime => SB_NOATIME
nodiratime => SB_NODIRATIME
lazytime => SB_LAZYTIME
>
> If the mount options are directly parsed by the filesystem option
> parser (as is done later in this patchset), then the mount option
> setting should be emitted by the filesystem's ->show_options
> function, not a generic function.
>
> The option string must match what the filesystem defines, not
> require separate per-filesystem and VFS definitions of the same
> option that people could potentially get wrong (*cough* i_version vs
> iversion *cough*)....
Are you objecting to the use of a SB_* flag, or just to showing the flag in
show_sb_opts() instead of in the individual filesystems? Note that the SB_*
flag was requested by Christoph
(https://lkml.kernel.org/r/20191031183217.GF23601@infradead.org/,
https://lkml.kernel.org/r/20191031212103.GA6244@infradead.org/). We originally
used a function fscrypt_operations::inline_crypt_enabled() instead.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
Satya Tangirala <satyat@google.com>
Subject: Re: [f2fs-dev] [PATCH 1/4] fs: introduce SB_INLINECRYPT
Date: Wed, 17 Jun 2020 20:19:35 -0700 [thread overview]
Message-ID: <20200618031935.GE1138@sol.localdomain> (raw)
In-Reply-To: <20200618011912.GA2040@dread.disaster.area>
On Thu, Jun 18, 2020 at 11:19:12AM +1000, Dave Chinner wrote:
> On Wed, Jun 17, 2020 at 07:57:29AM +0000, Satya Tangirala wrote:
> > Introduce SB_INLINECRYPT, which is set by filesystems that wish to use
> > blk-crypto for file content en/decryption. This flag maps to the
> > '-o inlinecrypt' mount option which multiple filesystems will implement,
> > and code in fs/crypto/ needs to be able to check for this mount option
> > in a filesystem-independent way.
> >
> > Signed-off-by: Satya Tangirala <satyat@google.com>
> > ---
> > fs/proc_namespace.c | 1 +
> > include/linux/fs.h | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/fs/proc_namespace.c b/fs/proc_namespace.c
> > index 3059a9394c2d..e0ff1f6ac8f1 100644
> > --- a/fs/proc_namespace.c
> > +++ b/fs/proc_namespace.c
> > @@ -49,6 +49,7 @@ static int show_sb_opts(struct seq_file *m, struct super_block *sb)
> > { SB_DIRSYNC, ",dirsync" },
> > { SB_MANDLOCK, ",mand" },
> > { SB_LAZYTIME, ",lazytime" },
> > + { SB_INLINECRYPT, ",inlinecrypt" },
> > { 0, NULL }
> > };
> > const struct proc_fs_opts *fs_infop;
>
> NACK.
>
> SB_* flgs are for functionality enabled on the superblock, not for
> indicating mount options that have been set by the user.
That's an interesting claim, given that most SB_* flags are for mount options.
E.g.:
ro => SB_RDONLY
nosuid => SB_NOSUID
nodev => SB_NODEV
noexec => SB_NOEXEC
sync => SB_SYNCHRONOUS
mand => SB_MANDLOCK
noatime => SB_NOATIME
nodiratime => SB_NODIRATIME
lazytime => SB_LAZYTIME
>
> If the mount options are directly parsed by the filesystem option
> parser (as is done later in this patchset), then the mount option
> setting should be emitted by the filesystem's ->show_options
> function, not a generic function.
>
> The option string must match what the filesystem defines, not
> require separate per-filesystem and VFS definitions of the same
> option that people could potentially get wrong (*cough* i_version vs
> iversion *cough*)....
Are you objecting to the use of a SB_* flag, or just to showing the flag in
show_sb_opts() instead of in the individual filesystems? Note that the SB_*
flag was requested by Christoph
(https://lkml.kernel.org/r/20191031183217.GF23601@infradead.org/,
https://lkml.kernel.org/r/20191031212103.GA6244@infradead.org/). We originally
used a function fscrypt_operations::inline_crypt_enabled() instead.
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2020-06-18 3:19 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-17 7:57 [PATCH 0/4] Inline Encryption Support for fscrypt Satya Tangirala
2020-06-17 7:57 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-06-17 7:57 ` [PATCH 1/4] fs: introduce SB_INLINECRYPT Satya Tangirala
2020-06-17 7:57 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-06-17 17:46 ` Jaegeuk Kim
2020-06-17 17:46 ` [f2fs-dev] " Jaegeuk Kim
2020-06-18 1:19 ` Dave Chinner
2020-06-18 1:19 ` [f2fs-dev] " Dave Chinner
2020-06-18 3:19 ` Eric Biggers [this message]
2020-06-18 3:19 ` Eric Biggers
2020-06-23 0:46 ` Dave Chinner
2020-06-23 0:46 ` [f2fs-dev] " Dave Chinner
2020-06-23 1:50 ` Eric Biggers
2020-06-23 1:50 ` Eric Biggers
2020-06-24 0:55 ` Dave Chinner
2020-06-24 0:55 ` Dave Chinner
2020-06-17 7:57 ` [PATCH 2/4] fscrypt: add inline encryption support Satya Tangirala
2020-06-17 7:57 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-06-17 17:59 ` Jaegeuk Kim
2020-06-17 17:59 ` [f2fs-dev] " Jaegeuk Kim
2020-06-18 17:48 ` Eric Biggers
2020-06-18 17:48 ` [f2fs-dev] " Eric Biggers
2020-06-17 7:57 ` [PATCH 3/4] f2fs: " Satya Tangirala
2020-06-17 7:57 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-06-17 17:56 ` Jaegeuk Kim
2020-06-17 17:56 ` [f2fs-dev] " Jaegeuk Kim
2020-06-18 10:06 ` Chao Yu
2020-06-18 10:06 ` [f2fs-dev] " Chao Yu
2020-06-18 18:13 ` Eric Biggers
2020-06-18 18:13 ` [f2fs-dev] " Eric Biggers
2020-06-18 19:28 ` Jaegeuk Kim
2020-06-18 19:28 ` [f2fs-dev] " Jaegeuk Kim
2020-06-18 19:35 ` Eric Biggers
2020-06-18 19:35 ` [f2fs-dev] " Eric Biggers
2020-06-19 2:43 ` Chao Yu
2020-06-19 2:43 ` [f2fs-dev] " Chao Yu
2020-06-19 2:39 ` Chao Yu
2020-06-19 2:39 ` [f2fs-dev] " Chao Yu
2020-06-19 4:20 ` Eric Biggers
2020-06-19 4:20 ` [f2fs-dev] " Eric Biggers
2020-06-19 6:37 ` Chao Yu
2020-06-19 6:37 ` [f2fs-dev] " Chao Yu
2020-06-18 22:50 ` Eric Biggers
2020-06-18 22:50 ` [f2fs-dev] " Eric Biggers
2020-06-17 7:57 ` [PATCH 4/4] ext4: " Satya Tangirala
2020-06-17 7:57 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-06-18 17:27 ` [PATCH 0/4] Inline Encryption Support for fscrypt Eric Biggers
2020-06-18 17:27 ` [f2fs-dev] " Eric Biggers
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=20200618031935.GE1138@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=david@fromorbit.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=satyat@google.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.