From: Petr Vorel <pvorel@suse.cz>
To: Namjae Jeon <linkinjeon@kernel.org>
Cc: Cyril Hrubis <chrubis@suse.cz>, Jan Polensky <japo@linux.ibm.com>,
ltp@lists.linux.it, linux-kernel@vger.kernel.org,
regressions@lists.linux.dev,
Andrea Cervesato <andrea.cervesato@suse.com>,
Sungjong Seo <sj1557.seo@samsung.com>,
Yuezhang Mo <yuezhang.mo@sony.com>,
Christoph Hellwig <hch@lst.de>,
"Darrick J . Wong" <djwong@kernel.org>
Subject: Re: [LTP] [PATCH v1 1/1] swap: Add exfat to filesystems requiring tst_fill_file
Date: Wed, 26 Aug 2026 09:41:14 +0200 [thread overview]
Message-ID: <20260826074114.GA32334@pevik> (raw)
In-Reply-To: <CAKYAXd_3Za8Jzan9VV4WrK1ATB2WXTazLVuGJ5ViQ8RGp0xbLw@mail.gmail.com>
Hi Namjae,
> On Tue, Aug 25, 2026 at 10:46 PM Cyril Hrubis <chrubis@suse.cz> wrote:
> > Hi!
> Hi Cyril, Petr,
> > > > That does not make much sense, if swap_activate was added to kernel,
> > > > pre-filling the fallocated file shouldn't be needed anymore.
> > > Good catch, you're right. I'm also confused, before v7.2 swap worked on exfat,
> > > now even with 82a81a7352bc ("exfat: add iomap buffered I/O support") [2]
> > > and your fix 03a43677ca91 ("exfat: add swap_activate support") [3] is not
> > > working. Obviously the fix was not good enough.
> > There were two bugs I suppose, one is that fallocate() support for exfat broke
> > the swapon on fallocated file. The second bug was introduced later when
> > exfat was rewritten to use iomap. The iomap case was fixed in the patch
> > above, however it looks like the original bug caused by fallocate()
> > implementation for exfat is still there.
> Can you check if an attached patch improves this issue?
> Thanks.
LGTM.
Tested-by: Petr Vorel <pvorel@suse.cz>
Tested on rapido-linux with:
CONFIG_EXFAT_FS=y
CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8"
Hopefully Jan will test it as well, built as module.
Kind regards,
Petr
> From 5679a624816454c8e7683842eb0ab3f1adf0dcca Mon Sep 17 00:00:00 2001
> From: Namjae Jeon <linkinjeon@kernel.org>
> Date: Wed, 26 Aug 2026 09:14:14 +0900
> Subject: [PATCH] exfat: map allocated extents for swap activation
> exFAT reports allocated ranges beyond valid_size as IOMAP_HOLE when
> IOMAP_REPORT is set. iomap_swapfile_activate() also uses IOMAP_REPORT
> while collecting physical extents for a swap file, so it treats the
> preallocated tail as unallocated and rejects the file with -EINVAL.
> Use swap-specific iomap operations that suppress IOMAP_REPORT before
> mapping the file. This reports physically allocated ranges as
> IOMAP_UNWRITTEN during swap activation without changing the
> byte-accurate SEEK_HOLE and SEEK_DATA behavior of the regular iomap
> operations.
> Fixes: 03a43677ca91 ("exfat: add swap_activate support")
> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
> ---
> fs/exfat/iomap.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
> diff --git a/fs/exfat/iomap.c b/fs/exfat/iomap.c
> index 0c805bf6676a..bf8baf78a9b8 100644
> --- a/fs/exfat/iomap.c
> +++ b/fs/exfat/iomap.c
> @@ -155,6 +155,22 @@ const struct iomap_ops exfat_iomap_ops = {
> .iomap_begin = exfat_iomap_begin,
> };
> +static int exfat_swap_iomap_begin(struct inode *inode, loff_t offset,
> + loff_t length, unsigned int flags, struct iomap *iomap,
> + struct iomap *srcmap)
> +{
> + /*
> + * Swap activation needs the physical mappings of preallocated
> + * ranges. Do not report the VDL tail as a hole.
> + */
> + return __exfat_iomap_begin(inode, offset, length,
> + flags & ~IOMAP_REPORT, iomap, false);
> +}
> +
> +static const struct iomap_ops exfat_swap_iomap_ops = {
> + .iomap_begin = exfat_swap_iomap_begin,
> +};
> +
> /*
> * exfat_write_iomap_end - Update the state after write
> *
> @@ -274,5 +290,6 @@ const struct iomap_read_ops exfat_iomap_bio_read_ops = {
> int exfat_iomap_swap_activate(struct swap_info_struct *sis,
> struct file *file, sector_t *span)
> {
> - return iomap_swapfile_activate(sis, file, span, &exfat_iomap_ops);
> + return iomap_swapfile_activate(sis, file, span,
> + &exfat_swap_iomap_ops);
> }
prev parent reply other threads:[~2026-08-26 7:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ajQFErzQW4qfU_Cp@li-276bd24c-2dcc-11b2-a85c-945b6f05615c.ibm.com>
[not found] ` <6a463902.41a38e5f.27f5bd.337a@mx.google.com>
[not found] ` <akzN_iISxNTztbEw@li-276bd24c-2dcc-11b2-a85c-945b6f05615c.ibm.com>
[not found] ` <20260825112755.GA62429@pevik>
[not found] ` <ao2TtyQpCGP5TLpx@yuki.lan>
2026-08-25 13:26 ` Petr Vorel
2026-08-25 13:46 ` Cyril Hrubis
2026-08-26 0:23 ` Namjae Jeon
2026-08-26 7:41 ` Petr Vorel [this message]
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=20260826074114.GA32334@pevik \
--to=pvorel@suse.cz \
--cc=andrea.cervesato@suse.com \
--cc=chrubis@suse.cz \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=japo@linux.ibm.com \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=regressions@lists.linux.dev \
--cc=sj1557.seo@samsung.com \
--cc=yuezhang.mo@sony.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
all inboxes | Powered by JetHome®