public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>,
	samasth.norway.ananda@oracle.com, calum.mackay@oracle.com,
	ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] mremap06: fallocate is not supported on nfsv3
Date: Wed, 10 Apr 2024 11:53:30 +0200	[thread overview]
Message-ID: <20240410095330.GB184706@pevik> (raw)
In-Reply-To: <20240410094621.GA184706@pevik>

Hi,

...
> > Shouldn't we limit this only to nfs, to make sure that fallocate() is
> > not accidentally disabled on other filesystems? At least that what I
> > suggested when I replied to the patch.

> That's what I also meant by my earlier suggestion (or, better I was not sure
> myself if it's needed). I would vote for this check. But since we already have
> this problem in other files, I would be ok to merge this first and handle
> proper fix as a separate approach if Samasth does not have time to solve it
> himself. @Samasth WDYT?

> The solution would be to at least check for tst_fs_type(".") == TST_NFS_MAGIC.
> Perfect solution would IMHO be to check for NFS version (e.g. in /proc/mounts)
> and TCONF only on NFSv3.

> BTW When I first read man fallocate(2), I interpreted following note related to
> FALLOC_FL_PUNCH_HOLE about general fallocate() support:

> 	Not all filesystems support FALLOC_FL_PUNCH_HOLE; if a filesystem doesn't
> 	support the operation, an error is returned.  The operation is supported on at
> 	least the following filesystems:

> 	•  XFS (since Linux 2.6.38)
> 	•  ext4 (since Linux 3.0)
> 	•  Btrfs (since Linux 3.7)
> 	•  tmpfs(5) (since Linux 3.5)
> 	•  gfs2(5) (since Linux 4.16)

Actually, I correct myself. Very proper check would be should TCONF only on all
filesystems we test (fs_type_whitelist[]) + these listed here from particular
version. i.e. not only NFSv3 is affected. But given it works on NFSv4*, it'd be
good to check the current support. Or we might just ignore the TCONF check, as
most of the filesystems got support in kernel 3.x and the oldest (gfs2) is 4.16.

Kind regards,
Petr

> Some of the tests which are using fallocate() indeed test FALLOC_FL_PUNCH_HOLE:

> $ git grep -l FALLOC_FL_PUNCH_HOLE testcases/
> testcases/kernel/mem/hugetlb/hugefallocate/hugefallocate01.c
> testcases/kernel/mem/hugetlb/hugefallocate/hugefallocate02.c
> testcases/kernel/syscalls/fallocate/fallocate04.c
> testcases/kernel/syscalls/fallocate/fallocate05.c
> testcases/kernel/syscalls/fallocate/fallocate06.c
> testcases/kernel/syscalls/memfd_create/memfd_create_common.c

> and others not, e.g.:
> testcases/kernel/syscalls/fallocate/fallocate0[1-3].c
> testcases/kernel/syscalls/mremap/mremap06.c (which does not check errno at all,
> likely not needed).

> Therefore also check for FALLOC_FL_PUNCH_HOLE would be needed (in addition to
> all NFS or NFSv3).

> BTW the man page does not mention NFS at all. @Samasth would you please send a
> patch to linux-man ML?

> Kind regards,
> Petr

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

  reply	other threads:[~2024-04-10  9:53 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
2024-04-10  9:30       ` Cyril Hrubis
2024-04-10  9:46         ` Petr Vorel
2024-04-10  9:53           ` Petr Vorel [this message]
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=20240410095330.GB184706@pevik \
    --to=pvorel@suse.cz \
    --cc=calum.mackay@oracle.com \
    --cc=chrubis@suse.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox