From: "Darrick J. Wong" <djwong@kernel.org>
To: Brian Foster <bfoster@redhat.com>
Cc: Zorro Lang <zlang@redhat.com>, fstests@vger.kernel.org
Subject: Re: [PATCH 2/2] fsx: add missing fallocate flag ifdefs
Date: Fri, 27 Sep 2024 08:25:37 -0700 [thread overview]
Message-ID: <20240927152537.GQ21877@frogsfrogsfrogs> (raw)
In-Reply-To: <ZvagFdWEcffZs06i@bfoster>
On Fri, Sep 27, 2024 at 08:07:49AM -0400, Brian Foster wrote:
> On Fri, Sep 27, 2024 at 01:42:31PM +0800, Zorro Lang wrote:
> > On Thu, Sep 26, 2024 at 11:55:21AM -0400, Brian Foster wrote:
> > > On Thu, Sep 26, 2024 at 07:50:28AM -0700, Darrick J. Wong wrote:
> > > > 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?
> > > >
> > >
> > > Probably not.. but why even bother worrying about individual flags? The
> > > insert and unshare flags have been around for 9 and 8 years
> > > respectively, none of these were fully ifdef'd from the beginning, and
> > > I'm not aware of anyone that has actually complained.
> > >
> > > I'm not convinced that this patch matters for anybody in practice. I
> > > included it just because it was simple enough to include the minimum
> > > mechanical fix and I was slightly curious if somebody could come up with
> > > a more elegant solution. In the spirit of being practical, maybe the
> > > better approach here is to just remove the (at least the falloc flag
> > > related) ifdefs entirely? We can always add them back if somebody
> > > complains...
> >
> > As this patch is still controversial, I'll merge the other one at first, to
> > catch up the release of this week. We can talk this one later, if you still
> > hope to have it :)
> >
>
> Thanks. In thinking more about it.. my reasoning above was that it seems
> like the value of these ifdefs is to avoid disruption when new
> functionality is introduced, but at the same time the fstests user base
> may not be necessarily all that interested in eternal backwards
> compatibility for ancient runtimes, etc. Therefore, I wonder if it's
> reasonable to have an (informal) expiration date for when we can clear
> out some of this cruft to keep the code cleaner and more maintainable
> going forward.
>
> So I largely agree with Darrick's point, it's just that personally I'm
> less interested in discussion over which fallocate flags to include or
> not because to my mind that suggests we might as well just drop the
> ifdefs entirely. That said, I'm not all that invested beyond just trying
> to be proactive since I happened to be hacking in this area, so if you
> guys want to leave things as is, or agree on a subset of flags to ifdef,
> just let me know and I'll drop it or send a v2.
Usually I just let Christoph complain and remove the ifdefs, but if I
have to use my own rule, it would be that ifdefs and ./configure
trickery isn't necessary for any symbol that is at least 5 years old.
Recent complaints on the mailing list have caused me to revise that to
10 years old though (see recent memfd_create fixes). :)
I also remember that a lot of the old crufty ifdef stuff (iirc) was kept
around so that fstests would continue to run on old RHELs. Once in a
while our QA folks rebase fstests to latest, but they also tend to patch
back in whatever ./configure magic they need for 2.6 era kernels.
--D
> Brian
>
>
> > Thanks,
> > Zorro
> >
> > >
> > > Brian
> > >
> > > > --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
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
next prev parent reply other threads:[~2024-09-27 15:25 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
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 [this message]
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=20240927152537.GQ21877@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bfoster@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=zlang@redhat.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