From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Andrey Albershteyn <aalbersh@redhat.com>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 03/11] xfs: add attribute type for fs-verity
Date: Wed, 14 Dec 2022 12:03:56 +1100 [thread overview]
Message-ID: <20221214010356.GC3600936@dread.disaster.area> (raw)
In-Reply-To: <733b882c-30fc-eea0-db01-55d25f272d92@redhat.com>
On Tue, Dec 13, 2022 at 11:43:42AM -0600, Eric Sandeen wrote:
> On 12/13/22 11:29 AM, Andrey Albershteyn wrote:
> > The Merkle tree pages and descriptor are stored in the extended
> > attributes of the inode. Add new attribute type for fs-verity
> > metadata. Skip fs-verity attributes for getfattr as it can not parse
> > binary page names.
> >
> > Signed-off-by: Andrey Albershteyn <aalbersh@redhat.com>
>
>
> > DECLARE_EVENT_CLASS(xfs_attr_list_class,
> > diff --git a/fs/xfs/xfs_xattr.c b/fs/xfs/xfs_xattr.c
> > index 5b57f6348d630..acbfa29d04af0 100644
> > --- a/fs/xfs/xfs_xattr.c
> > +++ b/fs/xfs/xfs_xattr.c
> > @@ -237,6 +237,9 @@ xfs_xattr_put_listent(
> > if (flags & XFS_ATTR_PARENT)
> > return;
> >
> > + if (flags & XFS_ATTR_VERITY)
> > + return;
> > +
>
> Just a nitpick, but now that there are already 2 cases like this, I wonder
> if it would be wise to #define something like an XFS_ATTR_VISIBLE_MASK
> (or maybe XFS_ATTR_INTERNAL_MASK) and use that to decide, rather than
> testing each one individually?
Seems like a good idea to me.
There's also a couple of other spots that a comment about internal
vs externally visible xattr namespaces might be appropriate. e.g
xfs_attr_filter() in the ioctl code should never have internal xattr
namespaces added to it, and similarly a comment at the top of
fs/xfs/xfs_xattr.c that the interfaces implemented in the file are
only for exposing externally visible xattr namespaces to users.
That way it becomes more obvious that we handle internal vs external
xattr namespaces very differently.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2022-12-14 1:04 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 17:29 [RFC PATCH 00/11] fs-verity support for XFS Andrey Albershteyn
2022-12-13 17:29 ` [RFC PATCH 01/11] xfs: enable large folios in xfs_setup_inode() Andrey Albershteyn
2022-12-14 0:53 ` Dave Chinner
2022-12-13 17:29 ` [RFC PATCH 02/11] pagemap: add mapping_clear_large_folios() wrapper Andrey Albershteyn
2022-12-13 17:55 ` Matthew Wilcox
2022-12-13 19:33 ` Eric Biggers
2022-12-13 21:10 ` Dave Chinner
2022-12-14 6:52 ` Eric Biggers
2022-12-14 8:12 ` Dave Chinner
2022-12-13 21:08 ` Dave Chinner
2023-01-09 16:34 ` Andrey Albershteyn
2022-12-13 17:29 ` [RFC PATCH 03/11] xfs: add attribute type for fs-verity Andrey Albershteyn
2022-12-13 17:43 ` Eric Sandeen
2022-12-14 1:03 ` Dave Chinner [this message]
2023-01-09 16:37 ` Andrey Albershteyn
2022-12-13 17:29 ` [RFC PATCH 04/11] xfs: add fs-verity ro-compat flag Andrey Albershteyn
2022-12-14 1:06 ` Dave Chinner
2022-12-13 17:29 ` [RFC PATCH 05/11] xfs: add inode on-disk VERITY flag Andrey Albershteyn
2022-12-14 1:29 ` Dave Chinner
2023-01-09 16:51 ` Andrey Albershteyn
2022-12-13 17:29 ` [RFC PATCH 06/11] xfs: initialize fs-verity on file open and cleanup on inode destruction Andrey Albershteyn
2022-12-14 1:35 ` Dave Chinner
2022-12-14 5:25 ` Eric Biggers
2022-12-14 8:18 ` Dave Chinner
2022-12-13 17:29 ` [RFC PATCH 07/11] xfs: disable direct read path for fs-verity sealed files Andrey Albershteyn
2022-12-14 2:07 ` Dave Chinner
2022-12-14 5:44 ` Eric Biggers
2022-12-23 16:18 ` Christoph Hellwig
2023-01-09 17:23 ` Andrey Albershteyn
2022-12-13 17:29 ` [RFC PATCH 08/11] xfs: don't enable large folios on fs-verity sealed inode Andrey Albershteyn
2022-12-14 2:07 ` Dave Chinner
2022-12-13 17:29 ` [RFC PATCH 09/11] iomap: fs-verity verification on page read Andrey Albershteyn
2022-12-13 19:02 ` Eric Biggers
2023-01-09 16:58 ` Andrey Albershteyn
2022-12-14 5:43 ` Dave Chinner
2022-12-13 17:29 ` [RFC PATCH 10/11] xfs: add fs-verity support Andrey Albershteyn
2022-12-13 19:08 ` Eric Biggers
2022-12-13 19:22 ` Darrick J. Wong
2022-12-13 20:13 ` Eric Biggers
2022-12-13 20:33 ` Dave Chinner
2022-12-13 20:39 ` Eric Biggers
2022-12-13 21:40 ` Dave Chinner
2022-12-14 7:58 ` Dave Chinner
2022-12-13 17:29 ` [RFC PATCH 11/11] xfs: add fs-verity ioctls Andrey Albershteyn
2022-12-13 20:50 ` [RFC PATCH 00/11] fs-verity support for XFS Eric Biggers
2022-12-13 22:11 ` Dave Chinner
2022-12-14 6:31 ` Eric Biggers
2022-12-14 23:06 ` Dave Chinner
2022-12-15 6:47 ` Eric Biggers
2022-12-15 20:57 ` Dave Chinner
2022-12-16 5:04 ` 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=20221214010356.GC3600936@dread.disaster.area \
--to=david@fromorbit.com \
--cc=aalbersh@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox