All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Mark Tinguely <tinguely@sgi.com>
Cc: bpm@sgi.com, xfs@oss.sgi.com
Subject: Re: [PATCH 6/6] xfs: increase number of ACL entries for V5 superblocks
Date: Wed, 5 Jun 2013 11:58:17 +1000	[thread overview]
Message-ID: <20130605015817.GJ29338@dastard> (raw)
In-Reply-To: <20130604032640.GE29466@dastard>

On Tue, Jun 04, 2013 at 01:26:40PM +1000, Dave Chinner wrote:
> On Mon, Jun 03, 2013 at 05:08:38PM -0500, Mark Tinguely wrote:
> > On 06/03/13 00:28, Dave Chinner wrote:
> > >From: Dave Chinner<dchinner@redhat.com>
> > >
> > >The limit of 25 ACL entries is arbitrary, but baked into the on-disk
> > >format.  For version 5 superblocks, increase it to the maximum nuber
> > >of ACLs that can fit into a single xattr.
> > >
> > >Signed-off-by: Dave Chinner<dchinner@redhat.com>
> > >Reviewed-by: Brian Foster<bfoster@redhat.com>
> > >---
....
> > >  /* On-disk XFS access control list structure */
> > >+struct xfs_acl_entry {
> > >+	__be32	ae_tag;
> > >+	__be32	ae_id;
> > >+	__be16	ae_perm;
> > >+	__be16	ae_pad;		/* fill the implicit hole in the structure */
> > >+};
> > >+
> > >  struct xfs_acl {
> > >-	__be32		acl_cnt;
> > >-	struct xfs_acl_entry {
> > >-		__be32	ae_tag;
> > >-		__be32	ae_id;
> > >-		__be16	ae_perm;
> > >-	} acl_entry[XFS_ACL_MAX_ENTRIES];
> > >+	__be32			acl_cnt;
> > >+	struct xfs_acl_entry	acl_entry[0];
> > >  };
> > >
> > >+/*
> > >+ * The number of ACL entries allowed is defined by the on-disk format.
> > >+ * For v4 superblocks, that is limited to 25 entries. For v5 superblocks, it is
> > >+ * limited only by the maximum size of the xattr that stores the information.
> > >+ */
> > >+#define XFS_ACL_MAX_ENTRIES(mp)	\
> > >+	(xfs_sb_version_hascrc(&mp->m_sb) \
> > >+	   ?  (XATTR_SIZE_MAX - sizeof(__be32)) / sizeof(struct xfs_acl_entry) \
> > >+	   : 25)
> > 
> > 
> > XFS_ACL_MAX_ENTRIES(mp)  == (65536 - 4) / 12 == 5461
> > 
> > >+
> > >+#define XFS_ACL_SIZE(mp) \
> > >+	(sizeof(struct xfs_acl) + \
> > >+		sizeof(struct xfs_acl_entry) * XFS_ACL_MAX_ENTRIES((mp)))
> > 
> > XFS_ACL_SIZE(mp) == (4 + 12) + 12 * ((64K - 4) / 12) == 65548
> > 
> > Did you want to add in the sizeof(struct xfs_acl) to the first term
> > or the sizeof(__be32)? I would think the acl_entry[0] is the start
> > of the array.
> 
> Ugh, I lost that in translation somewhere. Good catch.

Actually, I didn't lose anything - your calculation of sizeof(struct
xfs_acl) is wrong. I went back to the output from pahole to check
this:

struct xfs_acl {
        __be32                     acl_cnt;              /*     0     4 */
        struct xfs_acl_entry       acl_entry[0];         /*     4     0 */

        /* size: 4, cachelines: 1, members: 2 */
        /* last cacheline: 4 bytes */
};

sizeof(struct xfs_acl) = 4, not 16 as you calculated above. Therefore
code as posted is correct, if not immediately obvious.

The needed fix is to use sizeof(struct xfs_acl) in the
XFS_ACL_MAX_ENTRIES() calcluation rather than sizeof(__be32) so that
the two macros are clearly using the same structures for the
calculations...

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-06-05  1:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-03  5:28 [PATCH 0/6] xfs: fixes for 3.10-rc4 Dave Chinner
2013-06-03  5:28 ` [PATCH 1/6] xfs: rework dquot CRCs Dave Chinner
2013-06-03 18:18   ` Brian Foster
2013-06-04 21:46     ` Ben Myers
2013-06-04 22:07       ` Ben Myers
2013-06-03  5:28 ` [PATCH 2/6] xfs: fix log recovery transaction item reordering Dave Chinner
2013-06-03  5:28 ` [PATCH 3/6] xfs: inode unlinked list needs to recalculate the inode CRC Dave Chinner
2013-06-03 18:18   ` Brian Foster
2013-06-04  3:06     ` Dave Chinner
2013-06-03  5:28 ` [PATCH 4/6] xfs: fix remote attribute invalidation for a leaf Dave Chinner
2013-06-03 18:59   ` Brian Foster
2013-06-03 19:09   ` Mark Tinguely
2013-06-04  3:13     ` Dave Chinner
2013-06-04 22:28   ` Ben Myers
2013-06-03  5:28 ` [PATCH 5/6] xfs: disable noattr2/attr2 mount options for CRC enabled filesystems Dave Chinner
2013-06-03 19:02   ` Brian Foster
2013-06-03 21:38   ` Mark Tinguely
2013-06-05  1:49     ` Dave Chinner
2013-06-03  5:28 ` [PATCH 6/6] xfs: increase number of ACL entries for V5 superblocks Dave Chinner
2013-06-03 22:08   ` Mark Tinguely
2013-06-04  3:26     ` Dave Chinner
2013-06-05  1:58       ` Dave Chinner [this message]
2013-06-04 15:34   ` Ben Myers
2013-06-04 22:29     ` Dave Chinner
2013-06-04 22:32       ` Ben Myers

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=20130605015817.GJ29338@dastard \
    --to=david@fromorbit.com \
    --cc=bpm@sgi.com \
    --cc=tinguely@sgi.com \
    --cc=xfs@oss.sgi.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.