Re: [PATCH 0/2] io_uring: add removexattr and listxattr support

Aditya Prakash Srivastava <[email protected]> writes:

> This series completes io_uring's xattr feature parity by adding support
> for the remaining four xattr operations:
> - IORING_OP_REMOVEXATTR
> - IORING_OP_FREMOVEXATTR
> - IORING_OP_LISTXATTR
> - IORING_OP_FLISTXATTR

It is much cheaper to open a fixed file and use the FD variant of these
operations in io_uring that it is with a syscall.  Could we just live
with IORING_OP_FLISTXATTR/IORING_OP_FREMOVEXATTR?

> Historically, applications looking to achieve zero-blocking metadata
> management had to fall back to synchronous threads to list or prune
> extended attributes. This is particularly problematic for highly secure
> layered filesystems, active monitoring engines, or container runtimes
> utilizing namespace isolation xattrs.

Please drop the LLM explanation.  Why is this a problem for
"highly-secure layered filesystems" in particular?  This enables xattr
operations in an asynchronous fashion. period.

> To support this cleanly and reuse existing optimal VFS-layer code paths:
> - Patch 1 makes the necessary listxattr/removexattr VFS-layer helpers
>   non-static and exposes them in fs/internal.h.
> - Patch 2 implements the io_uring operational support (opcodes, opdefs,
>   preparation, and issue handlers) and invokes these exposed helpers.
>
> This approach ensures zero code duplication, robust filename handling,
> and maintains design consistency across both subsystems.
>
> Testing
> =======
> A self-contained test program is provided below

Please turn it into a proper liburing testcase.
-- 
Gabriel Krisman Bertazi