ltp.lists.linux.it archive mirror
 help / color / mirror / Atom feed
From: Li Wang <liwang@redhat.com>
To: Petr Vorel <pvorel@suse.cz>
Cc: LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH 1/1] utime03.c: Fix filesystem name
Date: Tue, 18 Jan 2022 17:11:58 +0800	[thread overview]
Message-ID: <CAEemH2fNfFes-eUtiQKX9JJxqEQUQ+O5nWQM8G-yNyTo8sxviw@mail.gmail.com> (raw)
In-Reply-To: <YeaB+smLnVt9voPy@pevik>

On Tue, Jan 18, 2022 at 5:01 PM Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi all,
>
> > On Mon, Jan 17, 2022 at 5:04 PM Petr Vorel <pvorel@suse.cz> wrote:
>
> > > Hi Li, Cyril,
>
> > > > > > +++ b/testcases/kernel/syscalls/utime/utime03.c
> > > > > > @@ -93,7 +93,7 @@ static struct tst_test test = {
> > > > > >         .mntpoint = MNTPOINT,
> > > > > >         .all_filesystems = 1,
> > > > > >         .skip_filesystems = (const char *const[]) {
> > > > > > -               "v9",
> > > > > > +               "9p",
>
> > > > > I'm wondering does it really take effect with whatever "v9" or "9p"?
> > > > > Because the fs_type_whitelist[] does not include any of them.
> > > +1. Do we want to add 9p to fs_type_whitelist[]? I suppose not, because (despite
>
> > I agree with you, as 9p is not a widely used filesystem for Linux distribution.
>
> > > of the name containing "whitelist" it's the list of filesystems actually being
> > > tested - this is a bit confusing to me).
>
> > Yes, it is actually the filesystem list that LTP will be tested on.
> > or maybe rename it to better understand.
> +1. I'll try to send patch after release.
>
>
> > > > Unless removing the .all_filesystems as well otherwise, it is impossible
> > > > has a chance to test on 9p.
> > > Yep. I forgot that .skip_filesystems works also on single fs.
> > > So correct entry in .skip_filesystems is kind of documentation in case of
> > > .all_filesystems being removed. I guess we should just remove the entry.
>
> > Sorry, what does that 'remove the entry' mean? I didn't catch your point here.
> As you pointed out it does not have any effect now to whitelist 9p.
> It's kind of documentation. Maybe instead of fixing the line we should remove it
> and put a comment above.

Ah sure, I'm fine with that quick fix (before the new release)
unless Cyril has additional comments.

>
>         /* NOTE: also does not work on 9p */
>         .skip_filesystems = (const char *const[]) {
>                 "vfat",
>                 "exfat",
>                 NULL
>         }
>
> Obviously the best would be to recheck if the limitation still exists,
> because whole problem is 10 years old: it was added
> bc5da68248cc963e17862b7a0c556409c29c763e in 2011 by Cyril:

Agree, we can leave this more time to rethink that.

>
>     The functional tests for utime checks if utime updates the
>     modification and access time to current time, however V9FS,
>     similar to NFS, by default uses the server's localtime if
>     client doesnt specify a new time. The current implentation
>     does not run the test if the underlying filesystem is NFS.
>     A similar check for V9FS is also required, hence this patch.
>
> Note later was found that NFS was ok on 2.6.18:
> d623e2c7fe ("splice01/tee01/utime: add kernel version check for NFS test")
> and remove during Martin's rewrite in ec3c3e5462.
>
> Kind regards,
> Petr
>


-- 
Regards,
Li Wang


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

  reply	other threads:[~2022-01-18  9:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14 21:00 [LTP] [PATCH 1/1] utime03.c: Fix filesystem name Petr Vorel
2022-01-17  2:23 ` Li Wang
2022-01-17  3:13   ` Li Wang
2022-01-17  9:04     ` Petr Vorel
2022-01-18  7:24       ` Li Wang
2022-01-18  9:01         ` Petr Vorel
2022-01-18  9:11           ` Li Wang [this message]
2022-01-18 10:34             ` Cyril Hrubis

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=CAEemH2fNfFes-eUtiQKX9JJxqEQUQ+O5nWQM8G-yNyTo8sxviw@mail.gmail.com \
    --to=liwang@redhat.com \
    --cc=ltp@lists.linux.it \
    --cc=pvorel@suse.cz \
    /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;
as well as URLs for NNTP newsgroup(s).