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);
> }
WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Namjae Jeon <linkinjeon@kernel.org>
Cc: regressions@lists.linux.dev, Yuezhang Mo <yuezhang.mo@sony.com>,
linux-kernel@vger.kernel.org,
"Darrick J . Wong" <djwong@kernel.org>,
Sungjong Seo <sj1557.seo@samsung.com>,
Christoph Hellwig <hch@lst.de>,
ltp@lists.linux.it
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);
> }
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-08-26 7:41 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 15:52 [LTP] [PATCH v1 1/1] swap: Add exfat to filesystems requiring tst_fill_file Jan Polensky
2026-06-08 16:29 ` [LTP] " linuxtestproject.agent
2026-06-09 9:19 ` [LTP] [PATCH v1 1/1] " Cyril Hrubis
2026-06-09 14:17 ` Jan Polensky
2026-06-12 9:06 ` Andrea Cervesato via ltp
2026-06-12 9:07 ` Cyril Hrubis
2026-06-17 13:56 ` Andrea Cervesato via ltp
2026-06-17 14:59 ` Andrea Cervesato via ltp
2026-06-17 15:19 ` Andrea Cervesato via ltp
2026-06-18 11:53 ` Jan Polensky
2026-06-18 12:04 ` Andrea Cervesato via ltp
2026-06-18 14:47 ` Jan Polensky
2026-06-18 14:57 ` Andrea Cervesato via ltp
2026-07-02 10:10 ` Andrea Cervesato via ltp
2026-07-07 9:59 ` Jan Polensky
2026-08-25 11:27 ` Petr Vorel
2026-08-25 12:17 ` Andrea Cervesato via ltp
2026-08-25 13:08 ` Cyril Hrubis
2026-08-25 13:26 ` Petr Vorel
2026-08-25 13:26 ` Petr Vorel
2026-08-25 13:46 ` Cyril Hrubis
2026-08-25 13:46 ` Cyril Hrubis
2026-08-26 0:23 ` Namjae Jeon
2026-08-26 0:23 ` Namjae Jeon via ltp
2026-08-26 7:41 ` Petr Vorel [this message]
2026-08-26 7:41 ` Petr Vorel
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 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.