All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: "chenhx.fnst@fujitsu.com" <chenhx.fnst@fujitsu.com>
Cc: "ltp@lists.linux.it" <ltp@lists.linux.it>
Subject: Re: [LTP]  回复:  [PATCH v2] syscalls/mount_setattr01: Add basic functional test
Date: Fri, 22 Apr 2022 16:11:48 +0200	[thread overview]
Message-ID: <YmK3pJ4HPsZeAPt4@pevik> (raw)
In-Reply-To: <OS3PR01MB644958457FD5DD0B37BF2A83E6F79@OS3PR01MB6449.jpnprd01.prod.outlook.com>

Hi Chen,

> > I guess we need SAFE_ variants for not having to check it all the time.

> It's hard for a SAFE_MOUNT_SETATTR:
> mount_setattr(2) need:
> #include <linux/mount.h> /* Definition of MOUNT_ATTR_* constants */

> But linux/mount.h have some conflicts with sys/mount.h, which is widely used in LTP.
> If we really want SAFE_MOUNT_SETATTR, we may need a big refactor.

Well, you don't have to bother with SAFE_MOUNT_SETATTR() unless you have time
for it. That will not block this patchset.

FYI I did some cleanup of include/lapi/mount.h and include/lapi/fsmount.h:
c0cb5d1962 ("lapi/mount.h: Include kernel/libc header")
8ae596f8b5 ("lapi/fsmount.h: Include lapi/mount.h instead libc header")

FYI we include kernel header and if missing, we include libc header:
#ifdef HAVE_LINUX_MOUNT_H
# include <linux/mount.h>
#else
# include <sys/mount.h>
#endif

If kernel header is old enough (theoretically we support compilation on 3.10 [1]),
we just include it and don't bother about checks.

If you want to work on SAFE_*(): not only SAFE_MOUNT_SETATTR(), but more
functions could be defined:
SAFE_MOVE_MOUNT() (could be used in fs{config,mount,open} tests), maybe
SAFE_OPEN_TREE() (it'd be used only in this test as open_tree tests should
probably keep using TEST(open_tree(...)).

I'd put it/them into new file lib/tst_safe_fsmount.c and include/tst_safe_fsmount.h.

NOTE: Although we have SAFE_MOUNT() in lib/safe_macros.c, IMHO we should keep it
there, instead of creating lib/tst_safe_mount.c, because lib/safe_macros.c
supports also legacy API (which we don't want to continue developing) and we
don't want to put many include/tst_safe_mount.h.

TODO for myself: SAFE_STATVFS() and SAFE_FSTATVFS()


> Sure, I'll post v3 soon.
+1

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/wiki/Supported-kernel,-libc,-toolchain-versions

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

      reply	other threads:[~2022-04-22 14:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 10:29 [LTP] [PATCH v2] syscalls/mount_setattr01: Add basic functional test Chen Hanxiao
2022-04-20 20:43 ` Petr Vorel
2022-04-21  9:13   ` Cyril Hrubis
2022-04-21  9:14     ` Petr Vorel
2022-04-22 11:05   ` [LTP] 回复: " chenhx.fnst
2022-04-22 14:11     ` 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=YmK3pJ4HPsZeAPt4@pevik \
    --to=pvorel@suse.cz \
    --cc=chenhx.fnst@fujitsu.com \
    --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.