v9fs and cpu negative interaction

[ericvh]

In some common default configurations v9fs and cpu (and by extension hugelgupf/p9) have a negative interaction which breaks ls (gets -EINVAL). we think this has something to do with xattr and specifically 9P_FS_SECURITY but have yet to isolate it. This can be worked around by noxattr mount flag, but would be good to understand what is going on.

[ericvh]

Validation & remediation plan

Type: interoperability bug (v9fs × cpu/p9).

Still a problem?

1. Boot QEMU guest with current v9fs/linux Image; mount 9P from u-root/cpu / hugelgupf/p9 with default options (no noxattr).
2. Run ls / ls -la on the mount; capture dmesg with 9p.debug / P9_DEBUG_ERROR|VFS and tcpdump/9P traces for Txattrwalk / Tgetattr failures (-EINVAL).
3. Bisect matrix:
   • noxattr on/off
   • posixacl on/off
   • version=9p2000.L vs .u
   • cpu vs diod vs QEMU virtfs
4. Confirm whether failure is ACL xattr fetch in v9fs_get_acl() during inode init (vfs_inode_dotl.c) when the server rejects xattr.

Address plan

1. Root-cause: client should not treat missing/unsupported xattr as hard error on lookup/readdir paths; map -ENODATA/-EOPNOTSUPP/-EINVAL from servers that lack ACL xattrs into “no ACL” when posixacl was not explicitly requested.
2. Short term: document noxattr (and when to use it) for cpu/p9 mounts in v9fs/test README; make harness default noxattr for cpu backends if still required.
3. Medium term: feature negotiation / remember-EINVAL (see 9p sec sends lots of messages that usually are -einval #39) so default mounts work without flags.
4. Add a guest-direct regression: mount cpu export, ls recursively, assert exit 0 without noxattr once fixed.