All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v4] syscalls/newmount: new test case for new mount API
Date: Thu, 23 Jan 2020 11:41:14 +0100	[thread overview]
Message-ID: <20200123104114.GD27845@rei> (raw)
In-Reply-To: <20200117110554.GG14282@dhcp-12-102.nay.redhat.com>

Hi!
> > The only thing with bothers me is is that NTFS related failure
> > on CONFIG_NTFS_FS is not set and mkfs.ntfs installed.
> > I'd prefer at least to have a warning, but but better to fix it.
> > I guess it's LTP problem, see code at safe_mount() in lib/safe_macros.c
> > 
> > 	/*
> > 	 * Don't try using the kernel's NTFS driver when mounting NTFS, since
> > 	 * the kernel's NTFS driver doesn't have proper write support.
> > 	 */
> > 	if (!filesystemtype || strcmp(filesystemtype, "ntfs")) {
> > 		rval = mount(source, target, filesystemtype, mountflags, data);
> > 		if (!rval)
> > 			return 0;
> > 	}
> > 
> > But obviously we don't use it as we do mount in the test, not in the library.
> > So I propose (and can implement) to add flag TST_FS_SKIP_NTFS 0x02 into include/tst_fs.h
> > and use it in test.
> 
> Maybe LTP should do more check to decide a fs list will be tested, not only check
> mkfs.$FSTPE tools. For example, check:
> 1) mkfs.$FSTYPE is exist
> 2) ${FSTYPE}.ko is loaded, or can be loaded.

That obivously does not work for filesystems build into the kernel.

> Or check:
> 1) mkfs.$FSTYPE $tmpdev run passed
> 2) mount $tmpdev $tmpmnt passed
> 3) umount $tmpdev
> 4) remove $tmpdev and $tmpmnt

If you have a look at the lib/tst_supported_fs_types.c we actually do
this for filesystems implemented in the kernel. For FUSE we only check
that FUSE is enabled in the kernel and that mount.$fs_type is present,
which should be enough to tell if the filesystem is supported.

> For FUSE, I think we'd better to not test FUSE by default. Then let the case decide if
> it would like to support a FUSE fs test. Change the TST_FS_SKIP_FUSE to TST_FS_SUP_FUSE,
> if someone case wants to test a FUSE fs (likes ntfs), it should do special steps to mount
> it, or it'll test linux internal ntfs.ko.

It works fine for majority of testcases, the mount() and fsmount()
syscalls are kind of special here. I guess that all we need to do here
is to skip the fuse here.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2020-01-23 10:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  7:56 [LTP] [PATCH v4] syscalls/newmount: new test case for new mount API Zorro Lang
2020-01-16 11:49 ` Cyril Hrubis
2020-01-16 15:08   ` Zorro Lang
2020-01-17  7:48     ` Petr Vorel
2020-01-17 11:05       ` Zorro Lang
2020-01-23 10:41         ` Cyril Hrubis [this message]
2020-01-23 13:15           ` Petr Vorel
2020-01-16 11:52 ` Petr Vorel

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=20200123104114.GD27845@rei \
    --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.