All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH V2] xfs: allow SECURE namespace xattrs to use reserved block pool
Date: Tue, 23 Jul 2024 09:05:16 +1000	[thread overview]
Message-ID: <Zp7lrCatH3Ry4PpH@dread.disaster.area> (raw)
In-Reply-To: <7c666cfc-0478-42d0-b179-575ace474db0@redhat.com>

On Mon, Jul 22, 2024 at 02:25:33PM -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 selinux / SECURE attributes are not so very different,
> so allow them to use the reserved space as well.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> V2: Remove local variable, add comment.
> 
> diff --git a/fs/xfs/xfs_xattr.c b/fs/xfs/xfs_xattr.c
> index ab3d22f662f2..09f004af7672 100644
> --- a/fs/xfs/xfs_xattr.c
> +++ b/fs/xfs/xfs_xattr.c
> @@ -110,7 +110,16 @@ xfs_attr_change(
>  	args->whichfork = XFS_ATTR_FORK;
>  	xfs_attr_sethash(args);
>  
> -	return xfs_attr_set(args, op, args->attr_filter & XFS_ATTR_ROOT);
> +	/*
> +	 * Allow xattrs for ACLs (ROOT namespace) and SELinux contexts

It's not just SELinux - it's security xattrs set by LSMs in general
that use the SECURE namespace. These come through:

xfs_generic_create()
  xfs_inode_init_security()
    security_inode_init_security()
      <LSM>
        xfs_initxattrs()
          xfs_attr_change(XFS_ATTR_SECURE)

> +	 * (SECURE namespace) to use the reserved block pool for these
> +	 * security-related operations. xattrs typically reside in the inode,
> +	 * so in many cases the reserved pool won't actually get consumed,
> +	 * but this will help the worst-case transaction reservations to
> +	 * succeed.
> +	 */

It doesn't explain why we need this - it's got the what and the
expected behaviour, but no why. :)

> +	return xfs_attr_set(args, op,
> +		    args->attr_filter & (XFS_ATTR_ROOT | XFS_ATTR_SECURE));
>  }

Perhaps it would be better to say something like:

	/*
	 * Some xattrs must be resistent to allocation failure at
	 * 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.
	 */

-Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2024-07-22 23:05 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 [this message]
2024-07-23 14:59   ` [PATCH V3] " Eric Sandeen
2024-07-23 16:52     ` Darrick J. Wong
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=Zp7lrCatH3Ry4PpH@dread.disaster.area \
    --to=david@fromorbit.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.