All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: samasth.norway.ananda@oracle.com
Cc: calum.mackay@oracle.com, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] mremap06: fallocate is not supported on nfsv3
Date: Tue, 9 Apr 2024 12:17:53 +0200	[thread overview]
Message-ID: <20240409101753.GA107959@pevik> (raw)
In-Reply-To: <e2368059-647c-4d98-8c90-2cc5f3bb34a4@oracle.com>

Hi all,

> On 4/5/24 5:01 AM, Cyril Hrubis wrote:
> > Hi!
> > > The function fallocate() is not supported on nfsv3. Thus when we run the
> > > mremap06 test over a nfsv3 filesystem the test fails.

> > Can we rather than this just skip the test on nfsv3?

> > If we want to skip the test on nfs in generall we can just set
> > .skip_filesystems = {"nfs", NULL} in the tst_test structure.

> > I'm not sure if we can easily detect the nfs version. The test library
> > does that by checking the NFS_SUPER_MAGIC againts stat, but there is a
> > single SUPER_MAGIC for all nfs versions.

Yeah, include/uapi/linux/magic.h in kernel contains only single magic. BTW I
wonder if magic is stored to the disk or there is some other complication which
prevent to have more magic values which would allow to distinguish version.

I wonder if it makes sense to add support to detect NFS version (read vers
parameter in /proc/mounts). The only reason why to do that would be to make sure
NFS v4.2 did not lost fallocate support by bug/regression. If we don't care,
checking errno is better option (will reflect kernel changes without a need to
adapt LTP test).

> > So if we want to keep the test enabled for nfsv4 we can exit with TCONF
> > when the call fails only when we are on NFS with tst_fs_type() and check
> > that against TST_NFS_MAGIC.


> Hi Cyril,

> Wanted to mention that fallocate() is only supported over NFSv4.2 in
> particular. it's not supported over NFSv3, v4.0 or v4.1.
> I could even see on the fallocate ltp tests that it is handled the same
> manner.

Yeah, these tests have it:
testcases/kernel/mem/hugetlb/hugefallocate/hugefallocate01.c
testcases/kernel/mem/hugetlb/hugefallocate/hugefallocate02.c
testcases/kernel/syscalls/fallocate/fallocate01.c
testcases/kernel/syscalls/fallocate/fallocate02.c
testcases/kernel/syscalls/fallocate/fallocate03.c
testcases/kernel/syscalls/fallocate/fallocate04.c

I guess we should write SAFE_FALLOCATE(). @Samasth any change you would write
it (as a separate effort).

> Thanks,
> Samasth.

> > > Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
> > > ---
> > >   testcases/kernel/syscalls/mremap/mremap06.c | 8 +++++++-
> > >   1 file changed, 7 insertions(+), 1 deletion(-)

> > > diff --git a/testcases/kernel/syscalls/mremap/mremap06.c b/testcases/kernel/syscalls/mremap/mremap06.c
> > > index 3bbaf441a..362b03e19 100644
> > > --- a/testcases/kernel/syscalls/mremap/mremap06.c
> > > +++ b/testcases/kernel/syscalls/mremap/mremap06.c
> > > @@ -104,8 +104,14 @@ static void setup(void)
> > >   	fd = SAFE_OPEN("testfile", O_CREAT | O_RDWR | O_TRUNC, 0600);
> > >   	ret = fallocate(fd, 0, 0, mmap_size);
> > > -	if (ret == -1)
> > > +	if (ret != 0) {
> > > +		if (errno == EOPNOTSUPP || errno == ENOSYS) {
> > > +			tst_brk(TCONF,
> > > +				"fallocate system call is not implemented");
> > > +		}
> > >   		tst_brk(TBROK, "fallocate() failed");
> > > +		return;

I suggest to merge this now, without return (it can be removed before merge).
Reviewed-by: Petr Vorel <pvorel@suse.cz>

Kind regards,
Petr

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

  reply	other threads:[~2024-04-09 10:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-01 15:00 [LTP] [PATCH] mremap06: fallocate is not supported on nfsv3 Samasth Norway Ananda
2024-04-05 12:01 ` Cyril Hrubis
2024-04-08 21:50   ` Samasth via ltp
2024-04-09 10:17     ` Petr Vorel [this message]
2024-04-10  9:30       ` Cyril Hrubis
2024-04-10  9:46         ` Petr Vorel
2024-04-10  9:53           ` Petr Vorel
2024-04-10 10:08           ` Cyril Hrubis
2024-04-10 13:33             ` Petr Vorel
2024-04-11  5:58               ` Samasth via ltp
  -- strict thread matches above, loose matches on Subject: below --
2024-03-26 20:56 Samasth Norway Ananda

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=20240409101753.GA107959@pevik \
    --to=pvorel@suse.cz \
    --cc=calum.mackay@oracle.com \
    --cc=ltp@lists.linux.it \
    --cc=samasth.norway.ananda@oracle.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.