From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/1] lib: Fix fs support detection for non-root
Date: Thu, 28 Jan 2021 17:03:09 +0100 [thread overview]
Message-ID: <YBLgPafndYT+b2Vr@pevik> (raw)
In-Reply-To: <YBLRadSFcxAWN57a@yuki.lan>
Hi Cyril,
> Hi!
> > grep /proc/filesystems to find kernel support.
> > But consider only 0 (filesystem found) or 1 (not found),
> > ignore other results (e.g. 2: /proc/filesystems not available or
> > no permissions) and fallback to old solution (calling mount()).
> Why is this needed?
generate_lvm_runfile.sh correctly requires TST_NEEDS_ROOT=1, only for this.
zram0{12}.sh (or maybe better zram_lib.sh, which they use) incorrectly don't
require root, they need it for calling modprobe zram and generally for zram use,
but also for this. I'll fix this in my patchset fixing zram and we can ignore
generate_lvm_runfile.sh.
=> It might not be needed. But generally some test in the future (C or shell)
may want to know filesystem support for other reason which does not require
root. Thus we can drop /proc/filesystems, but at least warning would be nice to
have (although that implementation only prints warning and returns 0, thus
warning will be lost for shell).
Also .all_filesystems in C API have .needs_root = 1. Currently copy_file_range01,
preadv03, pwritev03.
They get obvious hint from tst_acquire_loop_device():
tst_device.c:100: TINFO: Not allowed to open /dev/loop-control. Are you root?: EACCES (13)
=> they need to have .needs_root = 1.
And I wonder if we should have check expecting .needs_root for certain flags
(.all_filesystems, .needs_device, .mntpoint at least).
> Also this breaks FUSE detection.
Sorry for this. Agree with all your suggestions and can send v2 if we don't decide wontfix.
Kind regards,
Petr
prev parent reply other threads:[~2021-01-28 16:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 14:46 [LTP] [PATCH 1/1] lib: Fix fs support detection for non-root Petr Vorel
2021-01-28 14:55 ` Petr Vorel
2021-01-28 14:59 ` Cyril Hrubis
2021-01-28 16:03 ` Petr Vorel [this message]
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=YBLgPafndYT+b2Vr@pevik \
--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.