[REGRESSION] exfat: swapon(2) fails with EINVAL after iomap conversion

[Jan Polensky <japo@linux.ibm.com>]

Hi,

we are seeing a regression on linux-next after commit

  614f71ca1bdfaa2f25a6f147fe22f3ad031f8e2b
  ("exfat: add iomap buffered I/O support")

With this change, swapon(2) on an exfat swapfile fails with EINVAL.

Observed fallout in LTP:
  swapoff01
  swapoff02
  swapon01
  swapon02
  swapon03

Example failure:

  tst_test.c:1980: TINFO: === Testing on exfat ===
  tst_test.c:1291: TINFO: Formatting /dev/loop0 with exfat opts='' extra opts=''
  tst_test.c:1303: TINFO: Mounting /dev/loop0 to /tmp/LTP_swaKmkGVo/mntpoint fstyp=exfat flags=0
  tse_swap.c:196: TINFO: create a swapfile size of 1 megabytes (MB)
  tst_ioctl.c:26: TINFO: FIBMAP ioctl is supported
  tse_swap.c:228: TFAIL: swapon() on exfat failed: EINVAL (22)

and from swapon02:

  swapon02.c:56: TWARN: swapon(alreadyused) failed: EINVAL (22)
  swapon02.c:73: TFAIL: swapon(2) fail with File already used expected EBUSY: EINVAL (22)

The iomap conversion changes exfat_aops to iomap based callbacks, but does not add a
.swap_activate handler. The VFS documentation says that ->swap_activate() should call
add_swap_extent(), or the helper iomap_swapfile_activate().

So this looks like an exfat swap activation regression triggered by the iomap buffered I/O conversion.

#regzbot introduced: 614f71ca1bdfaa2f25a6f147fe22f3ad031f8e2b
#regzbot monitor: https://lore.kernel.org/all/PUZPR04MB63168E8C2FB92B80F9F6476581002@PUZPR04MB6316.apcprd04.prod.outlook.com/

Thanks
Jan