Linux: Check for block_dirty_folio

Linux: Check for block_dirty_folio

The build for the openafs Linux kernel module fails on RHEL9.1 with an
undefined function reference for block_dirty_folio().

RedHat 9.1 includes the Linux commit:
  fs: Add aops->dirty_folio (6f31a5a261db)
which added the dirty_folio member to the address_space_operations
structure.

However RedHat 9.1 does not include the following 2 Linux commits:
  fs: Convert __set_page_dirty_buffers to block_dirty_folio (e621900ad2)
which introduced block_dirty_folio() as a function that could be used to
handle the address_space_operations's dirty_folio operation.

And
  fs: Remove aops ->set_page_dirty (3a3bae50af)
which removed the set_page_dirty member in the address_space_operations
structure.

The openafs commit:
  Linux-5.18 replace set_page_dirty with dirty_folio (6aa129e743e88)
introduced an autoconf test that checks for the presence of aops'
dirty_folio member and assumed that the Linux function
block_dirty_folio() was also provided (since all three of the above
Linux commits were added in Linux-5.18-rc1).

Without the (e621900ad2) commit, the openafs Linux kernel module fails
to build since block_dirty_folio() is not defined by Linux.

Introduce new autoconf tests that checks for the presence of the
block_dirty_folio() function.

Change the preprocessor conditional within LINUX/osi_vnodeops.c to only
use dirty_folio if aops has dirty_folio and block_dirty_folio() is
available.  When block_dirty_folio() is not available, we continue to
use the older set_page_dirty method, which remains a valid method until
its removal by the (3a3bae50af) Linux commit.

Note: Reviewing the Linux source for RedHat 9.1 shows that there is only
one location that is defining the dirty_folio member and it is providing
its own function instead of relying on block_dirty_folio.

Change-Id: If8f7bba3fa779e344ba1d51f7a837197586142bd
Reviewed-on: https://gerrit.openafs.org/15199
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>