FS/XFS testing framework
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Daniel Gomez <da.gomez@samsung.com>
Cc: "fstests@vger.kernel.org" <fstests@vger.kernel.org>,
	Pankaj Raghav <p.raghav@samsung.com>,
	"mcgrof@kernel.org" <mcgrof@kernel.org>,
	"hughd@google.com" <hughd@google.com>
Subject: Re: [PATCH 4/5] common/rc: fix scratch mount options for tmpfs
Date: Mon, 24 Jun 2024 09:47:15 -0700	[thread overview]
Message-ID: <20240624164715.GI103020@frogsfrogsfrogs> (raw)
In-Reply-To: <jnyfwimjjfi56fqbfb4lvrauzinkgokdsftxa4k4o5o7eomokm@ghgk5vt46rcz>

On Mon, Jun 24, 2024 at 01:50:33PM +0000, Daniel Gomez wrote:
> On Fri, Jun 14, 2024 at 08:47:28AM GMT, Darrick J. Wong wrote:
> > On Fri, Jun 14, 2024 at 06:17:25AM +0000, Daniel Gomez wrote:
> > > Make sure tmpfs scratch device inherits the extra tmpfs mount options
> > > variable (TMPFS_MOUNT_OPTIONS).
> > > 
> > > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > > ---
> > >  common/rc | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/common/rc b/common/rc
> > > index 7f995b0fa..a42792c37 100644
> > > --- a/common/rc
> > > +++ b/common/rc
> > > @@ -224,7 +224,7 @@ _test_options()
> > >  # hosted on $SCRATCH_DEV, so can't use external scratch devices).
> > >  _common_dev_mount_options()
> > >  {
> > > -	echo $MOUNT_OPTIONS $SELINUX_MOUNT_OPTIONS $*
> > > +	echo $MOUNT_OPTIONS $SELINUX_MOUNT_OPTIONS $TMPFS_MOUNT_OPTIONS $*
> > 
> > Why is it necessary to include tmpfs mount options for all fs types?
> > XFS does not accept tmpfs mount options.
> 
> You are right. We should not do this.
> 
> However, _scratch_mount_options() calls _common_dev_mount_options() ignoring the
> specific mount options based on fstyp.

Ah, _mount_opts only gets run for configuration files.

> specific mount options based on fstyp. Replacing it with _common_mount_opts()
> makes this work. In addition, _common_dev_mount_options() function description
> says 'Used for mounting non-scratch devices with the safe set of scratch mount
> options'. So, why is it used to mount scratch devices?

I think the comment isn't very good.  Six of the seven callers:

common/dmdelay|23| _mount -t $FSTYP `_common_dev_mount_options` $SCRATCH_OPTIONS \
common/dmdust|19| _mount -t $FSTYP `_common_dev_mount_options $*` $SCRATCH_OPTIONS \
common/dmerror|94| _mount -t $FSTYP `_common_dev_mount_options $*` $SCRATCH_OPTIONS \
common/dmlogwrites|107| _mount -t $FSTYP `_common_dev_mount_options $*` $SCRATCH_OPTIONS \
common/dmthin|226| echo `_common_dev_mount_options $*` $SCRATCH_OPTIONS $DMTHIN_VOL_DEV $SCRATCH_MNT
common/rc|272| echo `_common_dev_mount_options $*` $SCRATCH_OPTIONS \

appear to use this to mount the scratch filesystem from devices that are
not the regular scratch device.  The one exception is this one:

common/overlay|32| _mount -t overlay $diropts `_common_dev_mount_options $*`

which AFAICT seem to mount arbitrary overlayfs instances with some of
the mount options.

> This fixes the issue:
> 
> diff --git a/common/rc b/common/rc
> index 51827119c..627dbaaaa 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -231,8 +231,8 @@ _scratch_mount_options()
>  {
>         _scratch_options mount
> 
> -       echo `_common_dev_mount_options $*` $SCRATCH_OPTIONS \
> -                                       $SCRATCH_DEV $SCRATCH_MNT
> +       echo `_common_mount_opts` $SCRATCH_OPTIONS \
> +                                       $SCRATCH_DEV $SCRATCH_MNT $*
>  }
> 
> > 
> > For that matter, why is TMPFS_MOUNT_OPTIONS necessary at all?  Shouldn't
> > that simply be "MOUNT_OPTIONS=<stuff> FSTYP=tmpfs ./check" ?
> 
> TMPFS_MOUNT_OPTIONS is used to specify mount options in each section of the
> configuration file. For example, the following snippet is part of my conf file:
> 
> ```
> [tmpfs_noswap_huge_always]
> TMPFS_MOUNT_OPTIONS="-o noswap,huge=always"
> 
> [tmpfs_noswap_huge_within_size]
> TMPFS_MOUNT_OPTIONS="-o noswap,huge=within_size"
> ```
> 
> Then I run -s option to switch between profiles, e.g., 'check -s
> tmpfs_noswap_huge_within_size -R xunit -g auto'.
> 
> I’m not sure if this addresses your question. Please let me know if I
> misunderstood.

Ahah, this is one of those parts of fstests that differ depending on
whether you use configuration files (you do) or not (I don't).  AFAICT,
get_next_config has this slightly odd (to me) behavior where if a config
section doesn't explicitly set MOUNT_OPTIONS, it will reuse
MOUNT_OPTIONS from a previous section if FSTYP hasn't changed.  You
instead want to change the mount between sections

So I /think/ the correct thing to do here is

[tmpfs_noswap_huge_always]
MOUNT_OPTIONS="-o noswap,huge=always"

[tmpfs_noswap_huge_within_size]
MOUNT_OPTIONS="-o noswap,huge=within_size"

Though I'm not exactly an expert on these things.

--D

> 
> > 
> > --D
> > 
> > >  }
> > >  
> > >  _scratch_mount_options()
> > > -- 
> > > 2.43.0
> > > 

  reply	other threads:[~2024-06-24 16:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20240614061726eucas1p13b3cf24fce9d28ce29ee029224bf4378@eucas1p1.samsung.com>
2024-06-14  6:17 ` [PATCH 0/5] tmpfs fixes Daniel Gomez
2024-06-14  6:17   ` [PATCH 1/5] generic/449: not run on tmpfs earlier Daniel Gomez
2024-06-14 15:43     ` Darrick J. Wong
2024-06-14  6:17   ` [PATCH 2/5] common/config: fix RECREATE_TEST_DEV initialization Daniel Gomez
2024-06-14 15:44     ` Darrick J. Wong
2024-06-17  6:57     ` Zorro Lang
2024-06-14  6:17   ` [PATCH 4/5] common/rc: fix scratch mount options for tmpfs Daniel Gomez
2024-06-14 15:47     ` Darrick J. Wong
2024-06-24 13:50       ` Daniel Gomez
2024-06-24 16:47         ` Darrick J. Wong [this message]
2024-06-24 20:47           ` Daniel Gomez
2024-06-14  6:17   ` [PATCH 3/5] common/rc: add recreation support " Daniel Gomez
2024-06-14 15:48     ` Darrick J. Wong
2024-06-17  7:06     ` Zorro Lang
2024-06-24 13:33       ` Daniel Gomez
2024-06-28  3:13         ` Zorro Lang
2024-06-28 22:29           ` Daniel Gomez
2024-06-14  6:17   ` [PATCH 5/5] common/rc: print scratch and test mount options Daniel Gomez
2024-06-14 15:55     ` Darrick J. Wong
2024-06-24 14:02       ` Daniel Gomez
2024-06-24 16:24         ` Darrick J. Wong
2024-06-24 20:57           ` Daniel Gomez

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=20240624164715.GI103020@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=da.gomez@samsung.com \
    --cc=fstests@vger.kernel.org \
    --cc=hughd@google.com \
    --cc=mcgrof@kernel.org \
    --cc=p.raghav@samsung.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox