From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH V5 04/10] syscalls/fsopen: New tests
Date: Thu, 12 Mar 2020 09:11:53 +0100 [thread overview]
Message-ID: <20200312081153.GA16928@dell5510> (raw)
In-Reply-To: <20200311072502.hpj5bycslu6ygk74@vireshk-i7>
Hi Viresh,
> > > + TEST(move_mount(fsmfd, "", AT_FDCWD, MNTPOINT,
> > > + MOVE_MOUNT_F_EMPTY_PATH));
> > > +
> > > + SAFE_CLOSE(fsmfd);
> > > +
> > > + if (TST_RET == -1) {
> > > + tst_res(TFAIL | TERRNO, "move_mount() failed");
> > > + goto out;
> > > + }
> > > +
> > > + if (tst_is_mounted(MNTPOINT))
> > > + tst_res(TPASS, "%s: fsopen() passed", tc->name);
> > > +
> > > + SAFE_UMOUNT(MNTPOINT);
> > I gues sthat the SAFE_UMOUNT() should be inside of the if here and in
> > the rest of the testcases.
> Petr had a similar comment earlier and here is my explanation to it.
> There should always be a unmount() in response to a successful call to
> mount() APIs. What if, because of some other bugs in the kernel or
> testsuite, tst_is_mounted() returns 0? We should still do the
> unmount() part as the mount() API didn't return an error.
But IMHO if device is not mounted we get TBROK due EINVAL in safe_umount().
I'd understand if this was in cleanup function where TBROK turns to TWARN.
Kind regards,
Petr
next prev parent reply other threads:[~2020-03-12 8:11 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 [this message]
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
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=20200312081153.GA16928@dell5510 \
--to=pvorel@suse.cz \
--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.