If xattr=sa is enabled, retrieving legacy xattrs is not possible

[ssrathi]

Found an issue while storing a large xattr (more than 32k size) with xattr=sa option on ZFS mount.

• Enable xattr=sa option.
• Add a small xattr on a folder (for example, xattr security.NTACL).
• After that, update the same xattr to something with more than 32k size.
• Due to the 32k size limit (DXATTR_MAX_ENTRY_SIZE), zpl_xattr_set_sa fails with error -EFBIG.
• The caller (zpl_xattr_set) will detect the failure and will store the new xattr in a hidden directory (old method) by calling zpl_xattr_set_dir.
• However, after calling zpl_xattr_set_dir, the old xattr stored in SA is not removed.
• Now, use 'getfattr' to retrieve this xattr (security.NTACL).
• __zpl_xattr_get will call zpl_xattr_get_sa to get the xattr from SA, which will be successful.
• As a result, the new xattr stored in a hidden directory is ignored during retrieval.
• From user point of view, the set-xattr has succeeded without any error, but the get-xattr has returned the old values, causing a silent failure.

Possible fix:

• If storing as SA fails and an xattr is stored in a hidden directory, then the existing xattr stored as SA should be removed.

[ssrathi]

As seen below in the output of zdb, even after storing a large xattr (larger than 32k), the old SA is still present.

$ sudo zdb zpool-share-cdb5a564-0d23-4cf9-9a49-708f247b3093-8e93403c-8068-480a-8970-37c4a53a36e7/share1 14 -vvvvvv
Dataset zpool-share-cdb5a564-0d23-4cf9-9a49-708f247b3093-8e93403c-8068-480a-8970-37c4a53a36e7/share1 [ZPL], ID 727, cr_txg 28723, 91.0K, 16 objects, rootbp DVA[0]=<1:76400:200> DVA[1]=<2:2002c200:200> [L0 DMU objset] fletcher4 lz4 LE contiguous unique double size=800L/200P birth=40070L/40070P fill=16 cksum=a1587e85a:3f451d17bf6:ccb84f6c6235:1c6dfe0b0dd030

    Object  lvl   iblk   dblk  dsize  lsize   %full  type
        14    1    16K    512     1K    512  100.00  ZFS directory (K=inherit) (Z=inherit)
                                        192   bonus  System attributes
    dnode flags: USED_BYTES USERUSED_ACCOUNTED SPILL_BLKPTR
    dnode maxblkid: 0
    path    /ACL/testdir
    uid     1107620
    gid     1100513
    atime   Wed Dec 30 15:38:31 2015
    mtime   Wed Dec 30 15:38:31 2015
    ctime   Wed Dec 30 15:38:35 2015
    crtime  Wed Dec 30 15:38:31 2015
    gen 39958
    mode    40777
    size    2
    parent  8
    links   2
    pflags  40800000144
    xattr   15
    SA xattrs: 612 bytes, 3 entries

        security.selinux = unconfined_u:object_r:file_t:s0\000
        user.DOSATTRIB = 0x10\000\000\003\000\003\000\000\000\021\000\000\000\020\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\336\257\3700[C\321\001\000\000\000\000\000\000\000\000
        security.NTACL = \004\000\004\000\000\000\002\000\004\000\002\000\001\000\013\031\311/V{\234\201[\010\312\307\374\001\272z\376J\037\262\2002\014\3469\360\023\002\343f\300\333\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000posix_acl\000\212\375\3700[C\321\001M^I\311\233\276\270\3772\036k\271\270\005\021\027\251\203\213\346\005\377\206\344L\023h+\350=\277\265\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\001\000\004\204\264\000\000\000\320\000\000\000\000\000\000\000\354\000\000\000\001\005\000\000\000\000\000\005\025\000\000\000\227\353k@\215\223\007S\201\022\373]\304\035\000\000\001\005\000\000\000\000\000\005\025\000\000\000\227\353k@\215\223\007S\201\022\373]\001\002\000\000\002\000\240\000\006\000\000\000\000\022\030\000\002\000\000\000\001\002\000\000\000\000\000\005 \000\000\000!\002\000\000\000\020$\000\377\001\037\000\001\005\000\000\000\000\000\005\025\000\000\000\227\353k@\215\223\007S\201\022\373]\304\035\000\000\000\033\024\000\377\001\037\000\001\001\000\000\000\000\000\003\000\000\000\000\000\023\030\000\377\001\037\000\001\002\000\000\000\000\000\005 \000\000\000 \002\000\000\000\022\030\000\004\000\020\000\001\002\000\000\000\000\000\005 \000\000\000!\002\000\000\000\023\030\000\251\000\022\000\001\002\000\000\000\000\000\005 \000\000\000!\002\000\000
    microzap: 512 bytes, 0 entries

Indirect blocks:
               0 L0 EMBEDDED [L0 ZFS directory] et=0 lz4 size=200L/1fP birth=39958L

        segment [0000000000000000, 0000000000000200) size   512

[ssrathi]

Looks like the pull request #4153 fixes this exact issue.

[ssrathi]

Related to #3472.

[behlendorf]

Fixed by #4153