Re: [LTP] fsconfig04: Check FSCONFIG_SET_PATH

Hi Wei,

On Aug 4, 2026, Wei Gao wrote:
> fsconfig04: Check FSCONFIG_SET_PATH

> +	TEST(fsconfig(fd, FSCONFIG_SET_PATH, "journal_path", dev2, 0));
> +	if (TST_RET == -1) {
> +		if (TST_ERR == EOPNOTSUPP)
> +			tst_brk(TCONF, "fsconfig(FSCONFIG_SET_PATH) not supported");
> +		else
> +			tst_brk(TFAIL | TTERRNO, "fsconfig(FSCONFIG_SET_PATH) failed");
> +	}

Could this test be gated with .min_kver = "7.2"?

Before Linux 7.2, ext4 declared journal_path as a string parameter, so
FSCONFIG_SET_PATH is rejected with EINVAL rather than EOPNOTSUPP. Since
fsopen_supported_by_kernel() only gates fsopen at Linux 5.2, those kernels
reach the else branch and report TFAIL instead of TCONF.

> +	SAFE_SSCANF(dev2, "/dev/%s", loop_name);
> +
> +	snprintf(path, sizeof(path), "/sys/block/%s/dev", loop_name);
> +	SAFE_FILE_SCANF(path, "%u:%u", &major, &minor);

Could the device number be obtained from stat(dev2).st_rdev instead?

tst_find_free_loopdev() also supports /dev/loop/N and /dev/block/loopN.
Those paths produce loop/N or block/loopN here, causing the test to read a
nonexistent sysfs path and terminate with TBROK.

> +	SAFE_MKFS(dev0, tst_device->fs_type, mkfs_opts_set_journal_dev1, NULL);
> +}
> +
> +static void run(void)
> +{
> +	...
> +	TEST(fsconfig(fd, FSCONFIG_SET_PATH, "journal_path", dev2, 0));

Could each iteration reset dev0 to dev1 or alternate the source and target
journal devices?

The first iteration persists dev2 in dev0's superblock. Every subsequent
-i iteration requests dev2 again, so it no longer exercises a dynamic
journal-device change.

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp