Subject: Re: [PATCH 4/4] statx: AFS: Return enhanced file attributes
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_3723228C-3378-4B5B-B615-210FCA1019BB"; protocol="application/pgp-signature"; micalg=pgp-sha256
From: Andreas Dilger <adilger@dilger.ca>
In-Reply-To: <147938972442.13574.1819690786475800772.stgit@warthog.procyon.org.uk>
Date: Thu, 17 Nov 2016 20:34:14 -0700
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Message-Id: <72C23B81-F59F-458E-B9B1-87A84CF9D6D4@dilger.ca>
References: <147938969703.13574.10295364502230379833.stgit@warthog.procyon.org.uk> <147938972442.13574.1819690786475800772.stgit@warthog.procyon.org.uk>
To: David Howells <dhowells@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 5197
Lines: 154


--Apple-Mail=_3723228C-3378-4B5B-B615-210FCA1019BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 17, 2016, at 6:35 AM, David Howells <dhowells@redhat.com> wrote:
>=20
> Return enhanced file attributes from the AFS filesystem.  This =
includes the
> following:
>=20
> (1) The data version number as st_version, setting STATX_VERSION.
>=20
> (2) STATX_ATTR_AUTOMOUNT will be set on automount directories by =
virtue of
>     S_AUTOMOUNT being set on the inode.  These are referrals to other
>     volumes or other cells.
>=20
> (3) STATX_ATTR_UNLISTED_DENTS on a directory that does cell lookup for
>     non-existent names and mounts them (typically mounted on /afs with =
-o
>     autocell).  The resulting directories are marked =
STATX_ATTR_FABRICATED
>     as they do not actually exist in the mounted AFS directory.
>=20
> (4) Files, directories and symlinks accessed over AFS are marked
>     STATX_ATTR_REMOTE.
>=20
> STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not
> support them.

Rather than clearing specific flags, wouldn't it be better to explicitly
set the flags that are actually being returned?  Otherwise, this would
have the problem that Dave pointed out on the 0/4 patch, that there may
be flags still set from userspace that do not mean anything to AFS.

Cheers, Andreas

>=20
> Example output:
>=20
> 	[root@andromeda ~]# ./samples/statx/test-statx /afs
> 	statx(/afs) =3D 0
> 	results=3D7ef
> 	  Size: 2048            Blocks: 0          IO Block: 4096    =
directory
> 	Device: 00:25           Inode: 1           Links: 2
> 	Access: (0777/drwxrwxrwx)  Uid:     0   Gid:     0
> 	Access: 2006-05-07 00:21:15.000000000+0100
> 	Modify: 2006-05-07 00:21:15.000000000+0100
> 	Change: 2006-05-07 00:21:15.000000000+0100
> 	IO-blocksize: blksize=3D4096
>=20
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>=20
> fs/afs/inode.c |   21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>=20
> diff --git a/fs/afs/inode.c b/fs/afs/inode.c
> index 86cc7264c21c..b08c405a7e1b 100644
> --- a/fs/afs/inode.c
> +++ b/fs/afs/inode.c
> @@ -72,9 +72,9 @@ static int afs_inode_map_status(struct afs_vnode =
*vnode, struct key *key)
> 	inode->i_uid		=3D vnode->status.owner;
> 	inode->i_gid		=3D GLOBAL_ROOT_GID;
> 	inode->i_size		=3D vnode->status.size;
> -	inode->i_ctime.tv_sec	=3D vnode->status.mtime_server;
> -	inode->i_ctime.tv_nsec	=3D 0;
> -	inode->i_atime		=3D inode->i_mtime =3D inode->i_ctime;
> +	inode->i_mtime.tv_sec	=3D vnode->status.mtime_server;
> +	inode->i_mtime.tv_nsec	=3D 0;
> +	inode->i_atime		=3D inode->i_ctime =3D inode->i_mtime;
> 	inode->i_blocks		=3D 0;
> 	inode->i_generation	=3D vnode->fid.unique;
> 	inode->i_version	=3D vnode->status.data_version;
> @@ -375,8 +375,7 @@ int afs_validate(struct afs_vnode *vnode, struct =
key *key)
> /*
>  * read the attributes of an inode
>  */
> -int afs_getattr(struct vfsmount *mnt, struct dentry *dentry,
> -		      struct kstat *stat)
> +int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct =
kstat *stat)
> {
> 	struct inode *inode;
>=20
> @@ -385,6 +384,18 @@ int afs_getattr(struct vfsmount *mnt, struct =
dentry *dentry,
> 	_enter("{ ino=3D%lu v=3D%u }", inode->i_ino, =
inode->i_generation);
>=20
> 	generic_fillattr(inode, stat);
> +
> +	stat->result_mask &=3D ~(STATX_ATIME | STATX_CTIME | =
STATX_BLOCKS);
> +	stat->result_mask |=3D STATX_VERSION;
> +	stat->version =3D inode->i_version;
> +
> +	if (test_bit(AFS_VNODE_AUTOCELL, &AFS_FS_I(inode)->flags))
> +		stat->attributes |=3D STATX_ATTR_UNLISTED_DENTS;
> +
> +	if (test_bit(AFS_VNODE_PSEUDODIR, &AFS_FS_I(inode)->flags))
> +		stat->attributes |=3D STATX_ATTR_FABRICATED;
> +	else
> +		stat->attributes |=3D STATX_ATTR_REMOTE;
> 	return 0;
> }
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe =
linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas


--Apple-Mail=_3723228C-3378-4B5B-B615-210FCA1019BB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIVAwUBWC52tnKl2rkXzB/gAQhumRAAgEYqcsUsKI3QHqUJCdHWeM4TOf2McWj3
78yXTcpQppETwhqp8/ikz+0f6YRtpt+nTLA3Oa8MuHERlpp6QIBOweTks0epTc7p
QmrTPwcicnhmalF/Uhq6+4n2mkixX6xBZjUhr1aPYiru0q1lMeLZRa0mTvg4zFKB
BTQ3JTQavt73nH0fi48M3fwZqPfyVzbP8SQ1ADrxv2Ea3aR1L7AFMo7GH8d4TR6m
988/X3HqP8UBXb0BmOxR5u0MxNCeD9vqxsvjwUWAaaS0oseJUEyolelSSgX1VYtp
4c8Q/gDtQIOAQYdHUD974dlP45tsWsBOA28hjM9tixtiWBy4fS6RCr27BNqDjNxO
C04ibUlKeHW60IOpraTLVFUj/1a/4YZwxOCEFs92rHuPGX85HhlvNQpKHmDzqSlw
vVKQWRM3c6/MgoB1xArCDgv8uzi/Z0+Q+n07CLwM1lxyn2i0H21gZT9bX4dy2Gh3
GijC+6NpTEnUghr0zvK4XhYBrZ7VDiYDwhXk1Sp6JeNPDvUAyESM0FxqAzY8+8iQ
4Rm/XzU5O9tFNAS78FWvPvJChdmF7Jft4fWKZF2hfnO3XoZcNyE8U2sZS79AKPWV
NOZBMm45hLvbxt+WaiPUzCeQaBmKANc/zfivNd4yMb+l5Rae/WZWyRuBvTWoD6x3
lgoYz5TNjxs=
=l0Ow
-----END PGP SIGNATURE-----

--Apple-Mail=_3723228C-3378-4B5B-B615-210FCA1019BB--