All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Boris Burkov <boris@bur.io>
Cc: linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org,
	kernel-team@fb.com
Subject: Re: [PATCH v6 2/3] btrfs: initial fsverity support
Date: Wed, 15 Sep 2021 13:45:23 -0700	[thread overview]
Message-ID: <YUJbYyVZr543cfg0@sol.localdomain> (raw)
In-Reply-To: <YUDrNR+72WMno10q@zen>

On Tue, Sep 14, 2021 at 11:34:29AM -0700, Boris Burkov wrote:
> > Okay, so it is used.  (Due to the macro, it didn't show up when grepping.)
> > 
> > Doesn't it defeat the purpose of a ro_compat inode flag if the whole filesystem
> > is marked with a ro_compat feature flag, though?  I thought that the point of
> > the ro_compat inode flag is to allow old kernels to mount the filesystem
> > read-write, with only verity files being forced to read-only.  That would be
> > more flexible than ext4's implementation of fs-verity which forces the whole
> > filesystem to read-only.  But it seems you're forcing the whole filesystem to
> > read-only anyway?
> > 
> > - Eric
> 
> I was thinking of it in terms of "RO compat is the goal" and having new
> inode flags totally broke that and was treated as a corruption of the
> inode regardless of the fs being ro/rw. I think a check on a live fs
> would just flip the fs ro, which was the goal anyway, but a check that
> happened during mount would fail the mount, even for a read-only fs. 
> 
> Making it fully per file would be pretty cool! The only thing
> really missing as far as I can tell is a way to mark a file read only
> with the same semantics fsverity uses from within btrfs.

I don't understand.  Why are you bothering with the ro_compat inode flag at all
if it doesn't actually work?

- Eric

  reply	other threads:[~2021-09-15 20:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30 20:01 [PATCH v6 0/3] btrfs: support fsverity Boris Burkov
2021-06-30 20:01 ` [PATCH v6 1/3] btrfs: add ro compat flags to inodes Boris Burkov
2021-06-30 20:01 ` [PATCH v6 2/3] btrfs: initial fsverity support Boris Burkov
2021-07-11 14:52   ` Eric Biggers
2021-07-28 14:29     ` David Sterba
2021-09-14 18:25     ` Boris Burkov
2021-07-28 15:05   ` David Sterba
2021-09-14 17:32   ` Eric Biggers
2021-09-14 17:49     ` Boris Burkov
2021-09-14 17:56       ` Eric Biggers
2021-09-14 18:34         ` Boris Burkov
2021-09-15 20:45           ` Eric Biggers [this message]
2021-09-15 21:01             ` Boris Burkov
2021-09-15 21:12               ` Eric Biggers
2021-09-15 23:14                 ` Boris Burkov
2021-09-14 18:03       ` David Sterba
2021-06-30 20:01 ` [PATCH v6 3/3] btrfs: verity metadata orphan items Boris Burkov
2021-07-28 15:24 ` [PATCH v6 0/3] btrfs: support fsverity David Sterba

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=YUJbYyVZr543cfg0@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=boris@bur.io \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    /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.