linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: darrick.wong@oracle.com
Cc: dhowells@redhat.com, linux-xfs@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@kernel.org>
Subject: [RFC] xfs: fix reporting supported extra file attributes for statx()
Date: Tue, 31 Oct 2017 15:13:05 -0700	[thread overview]
Message-ID: <20171031221305.12908-1-mcgrof@kernel.org> (raw)

statx(2) notes that any attribute that is not indicated as supported by
stx_attributes_mask has no usable value. Commit 5f955f26f3d42d ("xfs: report
crtime and attribute flags to statx") added support for informing userspace
of extra file attributes but forgot to list these flags as supported
making reporting them rather useless for the pedantic userspace author.

$ git describe --contains 5f955f26f3d42d04aba65590a32eb70eedb7f37d
v4.11-rc6~5^2^2~2

Fixes: 5f955f26f3d42d ("xfs: report crtime and attribute flags to statx")
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---

Its unclear why David left these out or if it was just a mistake, I checked
the original patch thread [0] but it was not clear in the end. David?

Also, I posted a patch to add support to clearing these flags through
xfs_repair on symlinks [1] due to the pain this can cause as you have no option
but to use xfs_db to fix these otherwise. Since we *didn't* list these extra
file attributes as supported, it begs the question if instead we should only
set them *and* this mask if !S_ISLNK(inode->i_mode)).

If so, that also begs the question if we should add further sanity check
on the xfs setattr to ensure these are never set on symbolic links, despite the
fact that FS_IOC_FSSETXATTR ioctl won't be able to set them...

A long shot question in terms of semantics is if all the above is rather
generic for Linux, is if the VFS should even be checking for immutable or
append flags on unlink for symbolic links.

[0] https://patchwork.kernel.org/patch/9607879/
[1] https://lkml.kernel.org/r/20171031215156.12544-1-mcgrof@kernel.org

 fs/xfs/xfs_iops.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index 17081c77ef86..6b7d293a4aab 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -531,6 +531,10 @@ xfs_vn_getattr(
 	if (ip->i_d.di_flags & XFS_DIFLAG_NODUMP)
 		stat->attributes |= STATX_ATTR_NODUMP;
 
+	stat->attributes_mask |= (STATX_ATTR_IMMUTABLE |
+				  STATX_ATTR_APPEND |
+				  STATX_ATTR_NODUMP);
+
 	switch (inode->i_mode & S_IFMT) {
 	case S_IFBLK:
 	case S_IFCHR:
-- 
2.14.2

             reply	other threads:[~2017-10-31 22:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31 22:13 Luis R. Rodriguez [this message]
2017-10-31 22:27 ` [RFC] xfs: fix reporting supported extra file attributes for statx() Darrick J. Wong
2017-10-31 22:38   ` Luis R. Rodriguez
2017-10-31 22:47     ` Darrick J. Wong
2019-03-01 16:53 ` Darrick J. Wong

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=20171031221305.12908-1-mcgrof@kernel.org \
    --to=mcgrof@kernel.org \
    --cc=darrick.wong@oracle.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@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 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).