All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH V5 04/10] syscalls/fsopen: New tests
Date: Thu, 12 Mar 2020 11:11:28 +0100	[thread overview]
Message-ID: <20200312101127.GA3803@rei.lan> (raw)
In-Reply-To: <20200312100316.7w67e5salel3dfue@vireshk-i7>

Hi!
> > > > 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().
> 
> But why won't move_mount() fail if device isn't mounted ? Why do we
> need the tst_is_mounted() helper at all ? Just to catch a case where
> move_mount() is buggy and doesn't report the failure properly, right ?
> In case of that bug, isn't it possible that move_mount() allocates
> some resources which must be freed with a call to umount()
> nevertheless ?

We can't really clean things up when something in kernel is misbehaving.
If there is a bug we enter the wast lands of undefined behavior where
anything is possible and any attempt to restore the system in a defined
state is doomed to fail anyways.

So in the end I do not care here as long as we clean up properly when
things work as expected, so either way is fine. It only looks a bit
strange when we attempt to umount things that are possibly not mounted.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2020-03-12 10: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
2020-03-12 10:03         ` Viresh Kumar
2020-03-12 10:11           ` Cyril Hrubis [this message]
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=20200312101127.GA3803@rei.lan \
    --to=chrubis@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.