All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH V5 05/10] syscalls/fsconfig: New tests
Date: Mon, 2 Mar 2020 13:51:47 +0530	[thread overview]
Message-ID: <20200302082147.zucnweqqdaaaaxyi@vireshk-i7> (raw)
In-Reply-To: <20200228160149.GA5312@dell5510>

On 28-02-20, 17:01, Petr Vorel wrote:
> > +	TEST(fsmfd = fsmount(fd, 0, 0));
> > +	if (fsmfd == -1) {
> > +		tst_res(TBROK | TERRNO, "fsmount() failed");
> > +		goto out;
> BTW This needs to be now tst_res(TFAIL) (this patchset now does not compile).

For a minute I thought I failed with my testing :(

And then I looked at the recent changes and looks like compilation
broke due to the changes you have pushed recently. Right ?

> > +	TEST(fsconfig(fd, FSCONFIG_SET_FD, "sync", NULL, 0));
> > +	if (TST_RET == -1) {
> > +		if (TST_ERR == EOPNOTSUPP) {
> > +			tst_res(TCONF, "fsconfig(): FSCONFIG_SET_FD not supported");
> > +		} else {
> > +			tst_res(TFAIL | TERRNO, "fsconfig() failed");
> > +			goto out;
> > +		}
> > +	}
> 
> I get TCONF for all fsconfig01 results, while I'm using 5.5.5-1-default:

s/all/most/

I know, same here.


> tst_test.c:1290: INFO: Testing on ext2
> tst_mkfs.c:89: INFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
> mke2fs 1.45.5 (07-Jan-2020)
> tst_test.c:1227: INFO: Timeout per run is 0h 05m 00s
> fsconfig01.c:43: CONF: fsconfig(): FSCONFIG_SET_PATH not supported
> fsconfig01.c:53: CONF: fsconfig(): FSCONFIG_SET_PATH_EMPTY not supported
> fsconfig01.c:63: CONF: fsconfig(): FSCONFIG_SET_FD not supported
> fsconfig01.c:92: PASS: fsconfig() passed
> tst_test.c:1290: INFO: Testing on ext3
> tst_mkfs.c:89: INFO: Formatting /dev/loop0 with ext3 opts='' extra opts=''
> mke2fs 1.45.5 (07-Jan-2020)
> tst_test.c:1227: INFO: Timeout per run is 0h 05m 00s
> fsconfig01.c:43: CONF: fsconfig(): FSCONFIG_SET_PATH not supported
> fsconfig01.c:53: CONF: fsconfig(): FSCONFIG_SET_PATH_EMPTY not supported
> fsconfig01.c:63: CONF: fsconfig(): FSCONFIG_SET_FD not supported
> fsconfig01.c:92: PASS: fsconfig() passed
> tst_test.c:1290: INFO: Testing on ext4
> tst_mkfs.c:89: INFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
> mke2fs 1.45.5 (07-Jan-2020)
> tst_test.c:1227: INFO: Timeout per run is 0h 05m 00s
> fsconfig01.c:43: CONF: fsconfig(): FSCONFIG_SET_PATH not supported
> fsconfig01.c:53: CONF: fsconfig(): FSCONFIG_SET_PATH_EMPTY not supported
> fsconfig01.c:63: CONF: fsconfig(): FSCONFIG_SET_FD not supported
> fsconfig01.c:92: PASS: fsconfig() passed
> tst_test.c:1290: INFO: Testing on xfs
> tst_mkfs.c:89: INFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
> tst_test.c:1227: INFO: Timeout per run is 0h 05m 00s
> fsconfig01.c:92: PASS: fsconfig() passed

You didn't get them for xfs :)

> tst_test.c:1290: INFO: Testing on btrfs
> tst_mkfs.c:89: INFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
> tst_test.c:1227: INFO: Timeout per run is 0h 05m 00s
> fsconfig01.c:43: CONF: fsconfig(): FSCONFIG_SET_PATH not supported
> fsconfig01.c:53: CONF: fsconfig(): FSCONFIG_SET_PATH_EMPTY not supported
> fsconfig01.c:63: CONF: fsconfig(): FSCONFIG_SET_FD not supported
> fsconfig01.c:92: PASS: fsconfig() passed
> tst_test.c:1290: INFO: Testing on vfat
> tst_mkfs.c:89: INFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
> tst_test.c:1227: INFO: Timeout per run is 0h 05m 00s
> fsconfig01.c:43: CONF: fsconfig(): FSCONFIG_SET_PATH not supported
> fsconfig01.c:53: CONF: fsconfig(): FSCONFIG_SET_PATH_EMPTY not supported
> fsconfig01.c:63: CONF: fsconfig(): FSCONFIG_SET_FD not supported
> fsconfig01.c:92: PASS: fsconfig() passed
> 
> Not yet merged man page [1] (I reposted David Howells commit) there is
> explanation for EOPNOTSUPP: The command given by cmd was not valid.
> 
> First, I suspected "sync" option is wrong. But looking at kernel sources it's
> really not implemented:
> 
> fs/fsopen.c
> 	if (fc->ops == &legacy_fs_context_ops) {
> 		switch (cmd) {
> 		case FSCONFIG_SET_BINARY:
> 		case FSCONFIG_SET_PATH:
> 		case FSCONFIG_SET_PATH_EMPTY:
> 		case FSCONFIG_SET_FD:
> 			ret = -EOPNOTSUPP;
> 			goto out_f;
> 		}
> 	}
> 
> fs/fs_context.c
> 	/* TODO: Make all filesystems support this unconditionally */
> 	init_fs_context = fc->fs_type->init_fs_context;
> 	if (!init_fs_context)
> 		init_fs_context = legacy_init_fs_context;
> ...
> /*
>  * Initialise a legacy context for a filesystem that doesn't support
>  * fs_context.
>  */
> static int legacy_init_fs_context(struct fs_context *fc)
> {
> 	fc->fs_private = kzalloc(sizeof(struct legacy_fs_context), GFP_KERNEL);
> 	if (!fc->fs_private)
> 		return -ENOMEM;
> 	fc->ops = &legacy_fs_context_ops;
> 	return 0;
> }

Right, I have seen that all earlier and so I knew that the failures
here are just fine.

> Code coming from v5.1-rc1 f3a09c92018a91ad0981146a4ac59414f814d801 introduce
> fs_context methods [2]. Other patchsets here [3] shows there is some support for
> fs_context in VFS. So I wonder how to achieve not end up with legacy context.
> 
> > +++ b/testcases/kernel/syscalls/fsconfig/fsconfig02.c
> > +  {"set-path-key", &fd, FSCONFIG_SET_PATH, NULL, "/dev/sda1", &aux_fdcwd, EINVAL},
> ...
> > +  {"set-path-aux", &fd, FSCONFIG_SET_PATH, "sync", "/dev/sda1", &aux_minus1, EINVAL},
> /dev/sda1 is valid on some hosts, but invalid on others. Shouldn't we use
> /dev/foo instead?

Should be fine I think.

> ...
> > +	temp_fd = open("testfile", O_RDWR | O_CREAT, 01444);
> > +	if (temp_fd == -1)
> > +		tst_res(TBROK, "Can't obtain temp_fd, open() failed");
> Here needs to be now tst_brk(TBROK).
> Again I'll change it before merge.

Thanks.

-- 
viresh

  reply	other threads:[~2020-03-02  8:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27  5:14 [LTP] [PATCH V5 00/10] Add new LTP tests related to fsmount family of syscalls Viresh Kumar
2020-02-27  5:14 ` [LTP] [PATCH V5 01/10] tst_device: Add tst_is_mounted() helper Viresh Kumar
2020-03-06 12:45   ` Cyril Hrubis
2020-03-07 12:42     ` Li Wang
2020-03-11  7:31       ` Viresh Kumar
2020-03-11 10:20         ` Cyril Hrubis
2020-03-11 10:26       ` Cyril Hrubis
2020-03-11 12:45         ` Li Wang
2020-03-11 13:11           ` Li Wang
2020-03-12 11:03         ` Viresh Kumar
2020-03-12 11:35           ` Petr Vorel
2020-02-27  5:14 ` [LTP] [PATCH V5 02/10] lapi/fsmount.h: Add fsopen_supported_by_kernel() Viresh Kumar
2020-03-06 12:47   ` Cyril Hrubis
2020-03-11  7:22     ` Viresh Kumar
2020-02-27  5:14 ` [LTP] [PATCH V5 03/10] lapi/fsmount.h: Include "lapi/fcntl.h" Viresh Kumar
2020-02-27  5:14 ` [LTP] [PATCH V5 04/10] syscalls/fsopen: New tests Viresh Kumar
2020-03-06 13:10   ` Cyril Hrubis
2020-03-11  7:25     ` Viresh Kumar
2020-03-12  8:11       ` Petr Vorel
2020-03-12 10:03         ` Viresh Kumar
2020-03-12 10:11           ` Cyril Hrubis
2020-02-27  5:14 ` [LTP] [PATCH V5 05/10] syscalls/fsconfig: " Viresh Kumar
2020-02-28 16:01   ` Petr Vorel
2020-03-02  8:21     ` Viresh Kumar [this message]
2020-03-06 13:25     ` Petr Vorel
2020-02-27  5:14 ` [LTP] [PATCH V5 06/10] syscalls/fsmount: Improve fsmount01 test Viresh Kumar
2020-02-27  5:14 ` [LTP] [PATCH V5 07/10] syscalls/fsmount: Add failure tests Viresh Kumar
2020-02-27  5:14 ` [LTP] [PATCH V5 08/10] syscalls/move_mount: New tests Viresh Kumar
2020-02-27  5:14 ` [LTP] [PATCH V5 09/10] syscalls/fspick: " Viresh Kumar
2020-02-27  5:14 ` [LTP] [PATCH V5 10/10] syscalls/open_tree: " Viresh Kumar
2020-03-06 13:18 ` [LTP] [PATCH V5 00/10] Add new LTP tests related to fsmount family of syscalls Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200302082147.zucnweqqdaaaaxyi@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.