From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Colin Walters <walters@verbum.org>
Cc: Jan Kara <jack@suse.cz>,
linux-nvdimm@lists.01.org, Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
linux-xfs@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE
Date: Mon, 31 Jul 2017 11:23:52 -0700 [thread overview]
Message-ID: <20170731182352.GE4477@magnolia> (raw)
In-Reply-To: <1501522933.602272.1058529880.6C4A2D98@webmail.messagingengine.com>
On Mon, Jul 31, 2017 at 01:42:13PM -0400, Colin Walters wrote:
>
>
> On Mon, Jul 31, 2017, at 12:32 PM, Colin Walters wrote:
> > On Mon, Jul 31, 2017, at 12:29 PM, Dan Williams wrote:
> > >
> > > How is S_CONTENTS_IMMUTABLE different than S_IMMUTABLE?
> >
> > We still want the ability to make hardlinks.
>
> Also of course, symmetrically, to unlink. If we used S_IMMUTABLE for /etc/sudoers,
> it'd still be racy since one would have to transiently remove the flag in order
> to replace it with a new version.
>
> Related to this topic is the fact that S_IMMUTABLE is itself mutable; I
> think once S_IMMUTABLE_CONTENTS is set, it would not be able to made
> mutable again.
>
> Also I just remembered that since then memfd_create() and more notably
> fcntl(F_ADD_SEALS) landed - in fact it already has flags for what we want
> here AFAICS. Your S_IOMAP_IMMUTABLE is fcntl(F_ADD_SEALS, F_SEAL_SHRINK | F_SEAL_GROW)
I don't think F_SEAL_{SHRINK,GROW} prevents reflinking or CoW of file data,
which are two things that cannot happen under S_IOMAP_IMMUTABLE that
aren't size changes. From the implementation it looks like shrink and
grow are only supposed to disallow changes to i_size, not i_blocks (or
the file block map).
Then again, I suppose F_SEAL_* only work on shmem, so maybe it simply
isn't defined for any other filesystem...? e.g. it doesn't prohibit
reflink, but the only fs implementing seals doesn't support reflink.
<shrug>
Seals cannot be removed, which is too strict for the S_IOMAP_IMMUTABLE
user cases being presented.
> and mine just adds in F_SEAL_WRITE. I think there was some discussion
> of the seals for persistent files when memfd_create() landed, but I can't
> find it offhand.
--D
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Colin Walters <walters@verbum.org>
Cc: Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.cz>,
linux-nvdimm@lists.01.org, Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
Jeff Moyer <jmoyer@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE
Date: Mon, 31 Jul 2017 11:23:52 -0700 [thread overview]
Message-ID: <20170731182352.GE4477@magnolia> (raw)
In-Reply-To: <1501522933.602272.1058529880.6C4A2D98@webmail.messagingengine.com>
On Mon, Jul 31, 2017 at 01:42:13PM -0400, Colin Walters wrote:
>
>
> On Mon, Jul 31, 2017, at 12:32 PM, Colin Walters wrote:
> > On Mon, Jul 31, 2017, at 12:29 PM, Dan Williams wrote:
> > >
> > > How is S_CONTENTS_IMMUTABLE different than S_IMMUTABLE?
> >
> > We still want the ability to make hardlinks.
>
> Also of course, symmetrically, to unlink. If we used S_IMMUTABLE for /etc/sudoers,
> it'd still be racy since one would have to transiently remove the flag in order
> to replace it with a new version.
>
> Related to this topic is the fact that S_IMMUTABLE is itself mutable; I
> think once S_IMMUTABLE_CONTENTS is set, it would not be able to made
> mutable again.
>
> Also I just remembered that since then memfd_create() and more notably
> fcntl(F_ADD_SEALS) landed - in fact it already has flags for what we want
> here AFAICS. Your S_IOMAP_IMMUTABLE is fcntl(F_ADD_SEALS, F_SEAL_SHRINK | F_SEAL_GROW)
I don't think F_SEAL_{SHRINK,GROW} prevents reflinking or CoW of file data,
which are two things that cannot happen under S_IOMAP_IMMUTABLE that
aren't size changes. From the implementation it looks like shrink and
grow are only supposed to disallow changes to i_size, not i_blocks (or
the file block map).
Then again, I suppose F_SEAL_* only work on shmem, so maybe it simply
isn't defined for any other filesystem...? e.g. it doesn't prohibit
reflink, but the only fs implementing seals doesn't support reflink.
<shrug>
Seals cannot be removed, which is too strict for the S_IOMAP_IMMUTABLE
user cases being presented.
> and mine just adds in F_SEAL_WRITE. I think there was some discussion
> of the seals for persistent files when memfd_create() landed, but I can't
> find it offhand.
--D
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-07-31 18:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-29 19:43 [PATCH 0/3] fs, xfs: block map immutable files for dax, dma-to-storage, and swap Dan Williams
2017-07-29 19:43 ` Dan Williams
2017-07-29 19:43 ` [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE Dan Williams
2017-07-29 19:43 ` Dan Williams
2017-07-31 16:02 ` Colin Walters
2017-07-31 16:02 ` Colin Walters
2017-07-31 16:29 ` Dan Williams
2017-07-31 16:29 ` Dan Williams
2017-07-31 16:32 ` Colin Walters
2017-07-31 16:32 ` Colin Walters
2017-07-31 17:42 ` Colin Walters
2017-07-31 17:42 ` Colin Walters
2017-07-31 18:23 ` Darrick J. Wong [this message]
2017-07-31 18:23 ` Darrick J. Wong
2017-08-01 2:15 ` Colin Walters
2017-08-01 2:15 ` Colin Walters
2017-08-01 2:42 ` Dave Chinner
2017-08-01 2:42 ` Dave Chinner
2017-08-05 9:45 ` Christoph Hellwig
2017-08-05 9:45 ` Christoph Hellwig
2017-07-31 16:46 ` Darrick J. Wong
2017-07-31 16:46 ` Darrick J. Wong
2017-07-31 17:32 ` Dan Williams
2017-07-31 17:32 ` Dan Williams
2017-07-29 19:43 ` [PATCH 2/3] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP Dan Williams
2017-07-29 19:43 ` Dan Williams
2017-07-29 19:43 ` Dan Williams
2017-07-31 17:09 ` Darrick J. Wong
2017-07-31 17:09 ` Darrick J. Wong
2017-07-31 18:25 ` Dan Williams
2017-07-31 18:25 ` Dan Williams
2017-08-01 0:30 ` Dave Chinner
2017-08-01 0:30 ` Dave Chinner
2017-07-29 19:43 ` [PATCH 3/3] xfs: persist S_IOMAP_IMMUTABLE in di_flags2 Dan Williams
2017-07-29 19:43 ` Dan Williams
2017-07-31 17:15 ` Darrick J. Wong
2017-07-31 17:15 ` Darrick J. Wong
2017-08-01 0:42 ` Dave Chinner
2017-08-01 0:42 ` Dave Chinner
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=20170731182352.GE4477@magnolia \
--to=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-xfs@vger.kernel.org \
--cc=luto@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=walters@verbum.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.