From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@redhat.com>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH V3] xfs: allow SECURE namespace xattrs to use reserved block pool
Date: Tue, 23 Jul 2024 09:52:00 -0700 [thread overview]
Message-ID: <20240723165200.GR612460@frogsfrogsfrogs> (raw)
In-Reply-To: <7ecf75c9-4727-4cde-ba5a-0736ea4128e9@redhat.com>
On Tue, Jul 23, 2024 at 09:59:41AM -0500, Eric Sandeen wrote:
> We got a report from the podman folks that selinux relabels that happen
> as part of their process were returning ENOSPC when the filesystem is
> completely full. This is because xattr changes reserve about 15 blocks
> for the worst case, but the common case is for selinux contexts to be
> the sole, in-inode xattr and consume no blocks.
>
> We already allow reserved space consumption for XFS_ATTR_ROOT for things
> such as ACLs, and SECURE namespace attributes are not so very different,
> so allow them to use the reserved space as well.
>
> Code-comment-by: Dave Chinner <dchinner@redhat.com>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
>
> V2: Remove local variable, add comment.
> V3: Add Dave's preferred comment
>
> diff --git a/fs/xfs/xfs_xattr.c b/fs/xfs/xfs_xattr.c
> index ab3d22f662f2..85e7be094943 100644
> --- a/fs/xfs/xfs_xattr.c
> +++ b/fs/xfs/xfs_xattr.c
> @@ -110,7 +110,26 @@ xfs_attr_change(
> args->whichfork = XFS_ATTR_FORK;
> xfs_attr_sethash(args);
>
> - return xfs_attr_set(args, op, args->attr_filter & XFS_ATTR_ROOT);
> + /*
> + * Some xattrs must be resistent to allocation failure at
Nit: resistant
> + * ENOSPC. e.g. creating an inode with ACLs or security
> + * attributes requires the allocation of the xattr holding
> + * that information to succeed. Hence we allow xattrs in the
> + * VFS TRUSTED, SYSTEM, POSIX_ACL and SECURITY (LSM xattr)
> + * namespaces to dip into the reserve block pool to allow
> + * manipulation of these xattrs when at ENOSPC. These VFS
> + * xattr namespaces translate to the XFS_ATTR_ROOT and
> + * XFS_ATTR_SECURE on-disk namespaces.
> + *
> + * For most of these cases, these special xattrs will fit in
> + * the inode itself and so consume no extra space or only
> + * require temporary extra space while an overwrite is being
> + * made. Hence the use of the reserved pool is largely to
> + * avoid the worst case reservation from preventing the
> + * xattr from being created at ENOSPC.
> + */
> + return xfs_attr_set(args, op,
> + args->attr_filter & (XFS_ATTR_ROOT | XFS_ATTR_SECURE));
With that fixed,
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> }
>
>
>
>
>
next prev parent reply other threads:[~2024-07-23 16:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-19 22:48 [PATCH] xfs: allow SECURE namespace xattrs to use reserved pool Eric Sandeen
2024-07-22 14:41 ` Christoph Hellwig
2024-07-22 15:05 ` Eric Sandeen
2024-07-22 15:11 ` Christoph Hellwig
2024-07-22 16:43 ` [External] : " mark.tinguely
2024-07-22 22:45 ` Dave Chinner
2024-07-22 19:25 ` [PATCH V2] xfs: allow SECURE namespace xattrs to use reserved block pool Eric Sandeen
2024-07-22 23:05 ` Dave Chinner
2024-07-23 14:59 ` [PATCH V3] " Eric Sandeen
2024-07-23 16:52 ` Darrick J. Wong [this message]
2024-07-23 16:56 ` Christoph Hellwig
2024-07-23 17:26 ` [PATCH V4] " Eric Sandeen
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=20240723165200.GR612460@frogsfrogsfrogs \
--to=djwong@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