All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Gao via ltp <ltp@lists.linux.it>
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/1] fsconfig03: Skip on FUSE
Date: Thu, 30 Mar 2023 10:14:49 -0400	[thread overview]
Message-ID: <20230330141449.GA23902@localhost> (raw)
In-Reply-To: <20230329133818.GA847898@pevik>

On Wed, Mar 29, 2023 at 03:38:18PM +0200, Petr Vorel wrote:
> > On Tue, Mar 28, 2023 at 04:40:31PM +0200, Petr Vorel wrote:
> > > fsconfig03 is broken not only on vfat and ntfs, but also over FUSE:
> 
> > > tst_supported_fs_types.c:120: TINFO: FUSE does support exfat
> 
> > I have a question on function has_kernel_support.
> 
> > If has_kernel_support start check exfat file system, if exfat not exist then start
> > check fuse, i have no idea why we still need check fuse, i suppose directly
> > return "exfat not support" instead of "FUSE does support exfat".
> 
> Because some filesystems can be supported by both Linux kernel or by FUSE
> (userspace). IMHO only NTFS and exfat are supported by both. We first check
> kernel implementation, but if it's not supported (e.g. kernel configured to
> support particular filesystem, but kernel module not being installed),
> we try to check if FUSE does support that filesystem.
> 
My opinion is has_kernel_support need ONLY check exfat implementation in kernel, this
can better match the name of function. Use for example has_fuse_support return exfat-fuse
or ntfs-3g support.

> > > +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> > > @@ -88,7 +88,7 @@ static struct tst_test test = {
> > >  	.mntpoint = MNTPOINT,
> > >  	.all_filesystems = 1,
> > >  	.taint_check = TST_TAINT_W | TST_TAINT_D,
> > > -	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},
> > > +	.skip_filesystems = (const char *const []){"fuse", NULL},
> 
> > I feel you can not skip fuse system since i found following list in LTP:
> > static const char *const fs_type_whitelist[] = {
> >         "ext2",
> >         "ext3",
> >         "ext4",
> >         "xfs",
> >         "btrfs",
> >         "vfat",
> >         "exfat",
> >         "ntfs",
> >         "tmpfs",
> >         NULL
> > };
> 
> This array name is quite confusing, that I even once proposed to rename it :) [1].
> It's used for .all_filesystems = 1 (if you don't define .skip_filesystems, all
> filesystems defined in fs_type_whitelist will be running. Therefore only
> filesystems defined in it makes sense to whitelist.
> 

I prefer replace .all_filesystems to .def_filesystems_check if we keep current logic.

> But on tests without .all_filesystems = 1, any filesystem can be defined in
> .skip_filesystems (see testcases/kernel/syscalls/fcntl/fcntl33.c, it has "ramfs"
> and "nfs"). In this case filesystem in $TMPDIR is checked and if the same as any
> member in .skip_filesystems, test is being skipped (see the beginning of
> do_test_setup()). I put some effort to document it, but mainly due
> "ext2/ext3/ext4" (when .all_filesystems = 1, is *not defined*) vs. using these
> separately (e.g..skip_filesystems = (const char *const []){"ext2", "ext3", NULL} ).

I have some difficult to understand above logic.

> 
> Back to your question, fuse is somehow special, see functions in lib/safe_macros.c
> Also, note, we don't even use kernel's NTFS driver, see lib/safe_macros.c:
> 

I prefer using more clear word describe fuse or non-fuse filesystem for white list/skip_filesystems such as:
*exfat // means we check exfat kernel version
*exfat-fuse //fuse version, we can add this into current white list
*ntfs // check ntfs kernel version
*ntfs-3g //fuse userspace implemen, we can add this into current white list

> int safe_mount(const char *file, const int lineno, void (*cleanup_fn)(void),
> 	       const char *source, const char *target,
> 	       const char *filesystemtype, unsigned long mountflags,
> 	       const void *data)
> {
> 	int rval = -1;
> 
> 	/*
> 	 * 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;
> 	}
> 
> 	/*
> 	 * The FUSE filesystem executes mount.fuse helper, which tries to
> 	 * execute corresponding binary name which is encoded at the start of
> 	 * the source string and separated by # from the device name.
>          *
> 	 * The mount helpers are called mount.$fs_type.
> 	 */
> 	if (possibly_fuse(filesystemtype)) {
> 		char buf[1024];
> 
> 		tst_resm_(file, lineno, TINFO, "Trying FUSE...");
> 		snprintf(buf, sizeof(buf), "mount.%s '%s' '%s'",
> 			filesystemtype, source, target);
> 
> Kind regards,
> Petr
> 
> [1] https://lore.kernel.org/ltp/20220126141152.6428-1-pvorel@suse.cz/
> [2] https://github.com/linux-test-project/ltp/wiki/C-Test-API#113-filesystem-type-detection-and-skiplist
Thanks again for support so much detail backgroud information!

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2023-03-30 14:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 14:40 [LTP] [PATCH 1/1] fsconfig03: Skip on FUSE Petr Vorel
2023-03-29 11:58 ` Wei Gao via ltp
2023-03-29 13:38   ` Petr Vorel
2023-03-30 14:14     ` Wei Gao via ltp [this message]
2023-03-31 15:34 ` Avinesh Kumar
2023-04-03  5:55   ` 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=20230330141449.GA23902@localhost \
    --to=ltp@lists.linux.it \
    --cc=pvorel@suse.cz \
    --cc=wegao@suse.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 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.