xfs_repair issue with ACLs on v5 XFS when beyond v4 limits

[Michael L. Semon]

Hi!  I've been running around in circles trying to work with too many 
ACLs, even losing my ability to count for a while.  Along the way, 
xfs_repair from git xfsprogs (last commit around May 27) is showing 
the following symptoms:

On v5-superblock XFS...

1) When the ACL count is just above the limit from v4-superblock XFS--
96 is a good test figure--`xfs_repair -n` and `xfs_repair` will both 
end in a segmentation fault.

2) When the ACL count is in a higher range--as low as 250, IIRC--
xfs_repair will complain about "Too many ACL entries" and proceed to 
remove them.  Below is a full session:

root at oldsvrhw:~# mkfs.xfs -f -m crc=1 $SCRATCH_DEV
meta-data=/dev/sdb5              isize=512    agcount=4, agsize=786432 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0
data     =                       bsize=4096   blocks=3145728, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

root at oldsvrhw:~# mount $SCRATCH_DEV $SCRATCH_MNT

root at oldsvrhw:~# mkdir $SCRATCH_MNT/acl-dir

root at oldsvrhw:~# for a in `seq 1000 1325`; do setfacl -d -m u:$a:r-- $SCRATCH_MNT/acl-dir; done

root at oldsvrhw:~# sync

root at oldsvrhw:~# umount $SCRATCH_MNT

root at oldsvrhw:~# xfs_repair -n $SCRATCH_DEV
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
Too many ACL entries, count 330
entry contains illegal value in attribute named SGI_ACL_FILE or SGI_ACL_DEFAULT
remote attribute value check failed for entry 0, inode 67
problem with attribute contents in inode 67
would clear attr fork
bad nblocks 2 for inode 67, would reset to 0
bad anextents 1 for inode 67, would reset to 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

root at oldsvrhw:~# xfs_repair $SCRATCH_DEV
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
Too many ACL entries, count 330
entry contains illegal value in attribute named SGI_ACL_FILE or SGI_ACL_DEFAULT
remote attribute value check failed for entry 0, inode 67
problem with attribute contents in inode 67
clearing inode 67 attributes
correcting nblocks for inode 67, was 2 - counted 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
bad attribute format 1 in inode 67, resetting value
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

root at oldsvrhw:~# mount $SCRATCH_DEV $SCRATCH_MNT

root at oldsvrhw:~# getfacl $SCRATCH_MNT/acl-dir
getfacl: Removing leading '/' from absolute path names
# file: mnt/xfstests-scratch/acl-dir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

3) When the ACL count is at the max for v5-superblock XFS--at least 
with both regular and default ACL slots filled--xfs_repair will 
complain of corrupt remote attributes.  AFAIK, xfs_repair doesn't 
bother with the "Too many ACL entries" line.  Those ACLs will be 
cleansed, too.

I can't tell if this is due to one missed check or three different 
tiny issues.

ACLs seem to be OK when doing normal filesystem operations and using 
setfacl and getfacl.  No kernel stack traces have been seen on this 
path of testing.

Sorry I missed this one in all of my limits testing.  This was 
discovered when I saw a bug in my ACL population script and hit 
Ctrl-c so I could stop and edit the script.  Donations of brown paper 
bags are welcome...the plastic bags I'm using make it hard to breathe 
and don't hide my face very well...

Test PC was a Pentium III, 733 MHz, 512 MB of RAM, running kernel 
3.15.0-rc8 + xfs-oss/for-next, on Slackware 14.1.

Thanks!

Michael