FS/XFS testing framework
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Brian Foster <bfoster@redhat.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH 2/2] fsx: add missing fallocate flag ifdefs
Date: Thu, 26 Sep 2024 07:50:28 -0700	[thread overview]
Message-ID: <20240926145028.GC21840@frogsfrogsfrogs> (raw)
In-Reply-To: <20240926144147.106685-3-bfoster@redhat.com>

On Thu, Sep 26, 2024 at 10:41:47AM -0400, Brian Foster wrote:
> The various fallocate flags are mostly ifdef'd for backward
> compatibility with the exception of the associated test_fallocate()
> calls to verify functionality at runtime. I suspect the reason for
> this was to avoid ifdef ugliness around having to clear the runtime
> flag for each operation, but unfortunately this defeats the purpose
> of the ifdef protection everywhere else.
> 
> Factor out the fallocate related test calls into a new helper and
> add the appropriate ifdefs.
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---
>  ltp/fsx.c | 59 ++++++++++++++++++++++++++++++++++++++++++-------------
>  1 file changed, 45 insertions(+), 14 deletions(-)
> 
> diff --git a/ltp/fsx.c b/ltp/fsx.c
> index 677f8c9f..417743c5 100644
> --- a/ltp/fsx.c
> +++ b/ltp/fsx.c
> @@ -2833,6 +2833,50 @@ __test_fallocate(int mode, const char *mode_str)
>  #endif
>  }
>  
> +void
> +test_fallocate_calls(void)
> +{
> +	if (fallocate_calls)
> +		fallocate_calls = test_fallocate(0);
> +	if (keep_size_calls)
> +		keep_size_calls = test_fallocate(FALLOC_FL_KEEP_SIZE);
> +
> +#ifdef FALLOC_FL_UNSHARE_RANGE
> +	if (unshare_range_calls)
> +		unshare_range_calls = test_fallocate(FALLOC_FL_UNSHARE_RANGE);
> +#else
> +	unshare_range_calls = 0;
> +#endif
> +
> +#ifdef FALLOC_FL_PUNCH_HOLE
> +	if (punch_hole_calls)
> +		punch_hole_calls = test_fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE);
> +#else
> +	punch_hole_calls = 0;
> +#endif
> +
> +#ifdef FALLOC_FL_ZERO_RANGE
> +	if (zero_range_calls)
> +		zero_range_calls = test_fallocate(FALLOC_FL_ZERO_RANGE);
> +#else
> +	zero_range_calls = 0;
> +#endif
> +
> +#ifdef FALLOC_FL_COLLAPSE_RANGE
> +	if (collapse_range_calls)
> +		collapse_range_calls = test_fallocate(FALLOC_FL_COLLAPSE_RANGE);
> +#else
> +	collapse_range_calls = 0;
> +#endif

The concept looks fine, but collapse and zero range have been in the
kernel for a decade now, do we really need to have ifdef tests for them?

--D

> +
> +#ifdef FALLOC_FL_INSERT_RANGE
> +	if (insert_range_calls)
> +		insert_range_calls = test_fallocate(FALLOC_FL_INSERT_RANGE);
> +#else
> +	insert_range_calls = 0;
> +#endif
> +}
> +
>  bool
>  keep_running(void)
>  {
> @@ -3271,20 +3315,7 @@ main(int argc, char **argv)
>  		check_trunc_hack();
>  	}
>  
> -	if (fallocate_calls)
> -		fallocate_calls = test_fallocate(0);
> -	if (keep_size_calls)
> -		keep_size_calls = test_fallocate(FALLOC_FL_KEEP_SIZE);
> -	if (unshare_range_calls)
> -		unshare_range_calls = test_fallocate(FALLOC_FL_UNSHARE_RANGE);
> -	if (punch_hole_calls)
> -		punch_hole_calls = test_fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE);
> -	if (zero_range_calls)
> -		zero_range_calls = test_fallocate(FALLOC_FL_ZERO_RANGE);
> -	if (collapse_range_calls)
> -		collapse_range_calls = test_fallocate(FALLOC_FL_COLLAPSE_RANGE);
> -	if (insert_range_calls)
> -		insert_range_calls = test_fallocate(FALLOC_FL_INSERT_RANGE);
> +	test_fallocate_calls();
>  	if (clone_range_calls)
>  		clone_range_calls = test_clone_range();
>  	if (dedupe_range_calls)
> -- 
> 2.46.1
> 
> 

  reply	other threads:[~2024-09-26 14:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-26 14:41 [PATCH 0/2] fsx: support unshare range fallocate mode Brian Foster
2024-09-26 14:41 ` [PATCH 1/2] " Brian Foster
2024-09-26 14:48   ` Darrick J. Wong
2024-09-26 15:53     ` Brian Foster
2024-09-27  3:40       ` Zorro Lang
2024-09-26 14:41 ` [PATCH 2/2] fsx: add missing fallocate flag ifdefs Brian Foster
2024-09-26 14:50   ` Darrick J. Wong [this message]
2024-09-26 15:55     ` Brian Foster
2024-09-27  5:42       ` Zorro Lang
2024-09-27 12:07         ` Brian Foster
2024-09-27 15:25           ` Darrick J. Wong
2024-09-27 18:34             ` Brian Foster
2024-09-28  8:03             ` Zorro Lang

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=20240926145028.GC21840@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=bfoster@redhat.com \
    --cc=fstests@vger.kernel.org \
    /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