From: Mark Brown <broonie@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Joanne Koong <joannelkoong@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Namjae Jeon <linkinjeon@kernel.org>
Subject: linux-next: manual merge of the vfs-brauner tree with the exfat tree
Date: Tue, 13 Oct 2026 14:21:56 +0100 [thread overview]
Message-ID: <as4wdHTj_PDybbSd@sirena.org.uk> (raw)
[-- Attachment #1: Type: text/plain, Size: 3244 bytes --]
Hi all,
Today's linux-next merge of the vfs-brauner tree got a conflict in:
fs/exfat/iomap.c
between commit:
80e764ecaf029 ("exfat: map allocated extents for swap activation")
from the exfat tree and commit:
d874f8060847c ("iomap: pass iomap_iter_next_fn directly instead of struct iomap_ops")
from the vfs-brauner tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc fs/exfat/iomap.c
index e50ecbfbfbe0f,72cdfe37bcf91..0000000000000
--- a/fs/exfat/iomap.c
+++ b/fs/exfat/iomap.c
@@@ -160,56 -148,11 +160,52 @@@ static int exfat_iomap_begin(struct ino
static int exfat_write_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
unsigned int flags, struct iomap *iomap, struct iomap *srcmap)
{
- return __exfat_iomap_begin(inode, offset, length, flags, iomap, true);
+ struct exfat_inode_info *ei = EXFAT_I(inode);
+ loff_t valid_size = exfat_get_valid_size(ei);
+ loff_t end;
+ int err;
+
+ err = __exfat_iomap_begin(inode, offset, length, flags, iomap, true);
+ if (err || flags & (IOMAP_DIRECT | IOMAP_FAULT) ||
+ iomap->flags & IOMAP_F_NEW)
+ return err;
+
+ end = iomap->offset + iomap->length;
+ if (end >= valid_size ||
+ round_up(end, i_blocksize(inode)) <= valid_size)
+ return 0;
+
+ /*
+ * Zero the invalid bytes from valid_size to the end of the block
+ * to prevent stale data from being exposed through the page cache.
+ */
+ return iomap_truncate_page(inode, valid_size, NULL, &exfat_iomap_ops,
+ NULL, NULL);
}
- static DEFINE_IOMAP_ITER_NEXT(exfat_iomap_next, exfat_iomap_begin);
-
- const struct iomap_ops exfat_iomap_ops = {
- .iomap_next = exfat_iomap_next,
- };
+ DEFINE_IOMAP_ITER_NEXT(exfat_iomap_next, exfat_iomap_begin);
+#ifdef CONFIG_SWAP
+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 DEFINE_IOMAP_ITER_NEXT(exfat_swap_iomap_next,
+ exfat_swap_iomap_begin);
+
+static const struct iomap_ops exfat_swap_iomap_ops = {
+ .iomap_next = exfat_swap_iomap_next,
+};
+#endif
+
/*
* exfat_write_iomap_end - Update the state after write
*
@@@ -325,10 -267,5 +317,9 @@@ const struct iomap_read_ops exfat_iomap
int exfat_iomap_swap_activate(struct swap_info_struct *sis,
struct file *file, sector_t *span)
{
+#ifdef CONFIG_SWAP
- return iomap_swapfile_activate(sis, file, span,
- &exfat_swap_iomap_ops);
+ return iomap_swapfile_activate(sis, file, span, exfat_iomap_next);
+#else
+ return -EIO;
+#endif
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2026-10-13 13:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 13:21 Mark Brown [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-10-13 13:21 Mark Brown
2026-03-27 17:35 Mark Brown
2026-03-28 1:01 ` Namjae Jeon
2024-08-11 22:10 Stephen Rothwell
2024-08-12 0:54 ` Namjae Jeon
2024-09-16 22:22 ` Stephen Rothwell
2024-09-17 6:44 ` Namjae Jeon
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=as4wdHTj_PDybbSd@sirena.org.uk \
--to=broonie@kernel.org \
--cc=brauner@kernel.org \
--cc=joannelkoong@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
/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®