All of lore.kernel.org
 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 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.