Re: fsconfig04: Check FSCONFIG_SET_PATH

On Tue, Aug 04, 2026 at 04:17:51AM +0000, [email protected] wrote:
> 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.
If fsconfig parameter is correct, return EINVAL should be an kernel bug.
Current logic is correct.
I guess AI mix wtih some old code with new API. But how to fix AI's rule is a
question.
> 
> > +	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