From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93E3EC56201 for ; Wed, 25 Nov 2020 19:19:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 487B3206D9 for ; Wed, 25 Nov 2020 19:19:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726248AbgKYTTt (ORCPT ); Wed, 25 Nov 2020 14:19:49 -0500 Received: from sandeen.net ([63.231.237.45]:59480 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725989AbgKYTTt (ORCPT ); Wed, 25 Nov 2020 14:19:49 -0500 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 2C83D323C1C; Wed, 25 Nov 2020 13:19:42 -0600 (CST) To: linux-fsdevel@vger.kernel.org From: Eric Sandeen Cc: David Howells Subject: Clarification of statx->attributes_mask meaning? Message-ID: <33d38621-b65c-b825-b053-eda8870281d1@sandeen.net> Date: Wed, 25 Nov 2020 13:19:48 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org The way attributes_mask is used in various filesystems seems a bit inconsistent. Most filesystems set only the bits for features that are possible to enable on that filesystem, i.e. XFS: if (ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) stat->attributes |= STATX_ATTR_IMMUTABLE; if (ip->i_d.di_flags & XFS_DIFLAG_APPEND) stat->attributes |= STATX_ATTR_APPEND; 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); btrfs, cifs, erofs, ext4, f2fs, hfsplus, orangefs and ubifs are similar. But others seem to set the mask to everything it can definitively answer, i.e. "Encryption and compression are off, and we really mean it" even though it will never be set to one in ->attributes, i.e. on gfs2: if (gfsflags & GFS2_DIF_APPENDONLY) stat->attributes |= STATX_ATTR_APPEND; if (gfsflags & GFS2_DIF_IMMUTABLE) stat->attributes |= STATX_ATTR_IMMUTABLE; stat->attributes_mask |= (STATX_ATTR_APPEND | STATX_ATTR_COMPRESSED | STATX_ATTR_ENCRYPTED | STATX_ATTR_IMMUTABLE | STATX_ATTR_NODUMP); ext2 is similar (it adds STATX_ATTR_ENCRYPTED to the mask but will never set it in attributes) The commit 3209f68b3ca4 which added attributes_mask says: "Include a mask in struct stat to indicate which bits of stx_attributes the filesystem actually supports." The manpage says: "A mask indicating which bits in stx_attributes are supported by the VFS and the filesystem." -and- "Note that any attribute that is not indicated as supported by stx_attributes_mask has no usable value here." So is this intended to indicate which bits of statx->attributes are valid, whether they are 1 or 0, or which bits could possibly be set to 1 by the filesystem? If the former, then we should move attributes_mask into the VFS to set all flags known by the kernel, but David's original commit did not do that so I'm left wondering... Thanks, -Eric