[LTP] syscalls/statx13: Add basic test for STATX_WRITE_ATOMIC on regular file

linuxtestproject.agent@gmail.com linuxtestproject.agent@gmail.com
Thu Sep 17 13:15:33 CEST 2026


Hi Gaurav,

On Thu Sep 17 16:23:04 2026 +0530, Gaurav Pathak <gaurav.pathak@suse.com> wrote:
> syscalls/statx13: Add basic test for STATX_WRITE_ATOMIC on regular file

> Fixes: #1224

Fixes: must reference a valid commit SHA in local git history. If
referencing a GitHub issue, use Closes: #1224 instead.

> diff --git a/testcases/kernel/syscalls/statx/.gitignore b/testcases/kernel/syscalls/statx/.gitignore
> index f6a423eed..e601a46a3 100644
> --- a/testcases/kernel/syscalls/statx/.gitignore
> +++ b/testcases/kernel/syscalls/statx/.gitignore
> @@ -10,3 +10,4 @@
>  /statx10
>  /statx11
>  /statx12
> +/statx13

The new test must also be added to runtest/syscalls.

> -AC_CHECK_MEMBERS([struct statx.stx_mnt_id, struct statx.stx_dio_mem_align],,,[
> +AC_CHECK_MEMBERS([struct statx.stx_mnt_id, struct statx.stx_dio_mem_align, struct statx.stx_atomic_write_unit_max_opt],,,[
>  #define _GNU_SOURCE
>  #include <sys/stat.h>
>  ])

Compile-time checks in configure.ac may only enable fallback API
definitions in include/lapi/. Fallback definitions for STATX_WRITE_ATOMIC,
STATX_ATTR_WRITE_ATOMIC, and the atomic write struct statx fields belong
in include/lapi/stat.h so the test builds on distributions with older libc
headers.

> + * The test performs the following validations:
> + * - Creates a test file using O_DIRECT (a prerequisite for atomic writes).
> + * - Calls statx() with the STATX_WRITE_ATOMIC mask to retrieve the limits.
> + * - Verifies that stx_atomic_write_unit_min, stx_atomic_write_unit_max, and
> + *    stx_atomic_write_unit_max_opt are logically consistent (e.g., max_opt is
> + *    within the min and max bounds).
> + * - Ensures all reported atomic write unit sizes are valid powers of two.

Add a blank line before the bulleted list. Reference the syscall as
:manpage:`statx(2)` and align the continuation indentation on line 15.
Also update the doc comment regarding supported filesystems since ext4 is
tested as well.

> +#define _GNU_SOURCE
> +#include <sys/param.h>
> +#include "tst_test.h"
> +
> +#define MNTPOINT "mnt_point"
> +#define TESTFILE MNTPOINT"/testfile"

Drop unused <sys/param.h> and include "lapi/stat.h". Add a space between
concatenated string literals: MNTPOINT "/testfile".

> +static void verify_statx(void)
> +{
> +	struct statx buff;

Tested syscall struct arguments must not be allocated on the stack.
Declare a static pointer and allocate it via .bufs in struct tst_test.

> +#ifdef HAVE_STRUCT_STATX_STX_ATOMIC_WRITE_UNIT_MAX_OPT
> +	if (buff.stx_atomic_write_unit_max_opt == 0) {
> +		tst_res(TINFO, "stx_atomic_write_unit_max_opt is 0 (no optimized max reported)");
> +	} else {
[...]
> +#else
> +	tst_res(TCONF, "stx_atomic_write_unit_max_opt is not defined in struct statx");
> +#endif

Compile-time feature guards must not be placed inside function bodies.
Provide fallback definitions in include/lapi/stat.h instead.

> +static void setup(void)
> +{
> +	char *data_buff = SAFE_MEMALIGN(ALIGNMENT, WRITE_SIZE);
> +
> +	if (strcmp(tst_device->fs_type, "xfs") && strcmp(tst_device->fs_type, "ext4"))
> +		tst_brk(TCONF, "This test only supports ext4 and xfs");
> +
> +	umask(0);
> +	memset(data_buff, '@', WRITE_SIZE);
> +
> +	file_fd =  SAFE_OPEN(TESTFILE, O_RDWR | O_CREAT | O_DIRECT, MODE);
> +	SAFE_WRITE(SAFE_WRITE_ALL, file_fd, data_buff, WRITE_SIZE);
> +}

data_buff is never freed, leaking memory. Free it after SAFE_WRITE(), and
perform the allocation after the filesystem check to avoid leaking on
tst_brk().

> +static void cleanup(void)
> +{
> +	if (file_fd > -1)
> +		SAFE_CLOSE(file_fd);
> +}

Use if (file_fd != -1) to check file descriptor validity. Also, file_fd is
kept open across test iterations but verify_statx() only accesses TESTFILE
by path; close file_fd in setup() after writing if fd-based statx is not
tested.

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer


More information about the ltp mailing list