mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeremy Bingham <jbingham@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, brauner@kernel.org,
	jkoolstra@xs4all.nl, jack@suse.cz, djwong@kernel.org,
	viro@zeniv.linux.org.uk, Jeremy Bingham <jbingham@gmail.com>
Subject: [PATCH v3 2/5] minix: add base iomap begin/end functions
Date: Sat, 11 Jul 2026 13:59:06 -0700	[thread overview]
Message-ID: <555d199291b37e5c1241df648b3adcd760c1fca6.1783707063.git.jbingham@gmail.com> (raw)
In-Reply-To: <cover.1783707063.git.jbingham@gmail.com>

Adds a new file, iomap.c, to fs/minix. This provides minix_iomap_begin,
which is the iomap-based version of get_block in itree_common.c. It also
provides minix_iomap_end, which is a no-op but required by the iomap_ops
struct. This also undoes the nest of gotos inherited from get_block and
uses a set of helper functions instead.

Suggested-by: Darrick J. Wong <djwong@kernel.org>

Signed-off-by: Jeremy Bingham <jbingham@gmail.com>
---
 fs/minix/iomap.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 122 insertions(+)
 create mode 100644 fs/minix/iomap.c

diff --git a/fs/minix/iomap.c b/fs/minix/iomap.c
new file mode 100644
index 000000000000..90e016aaa01e
--- /dev/null
+++ b/fs/minix/iomap.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * iomap functions for minix.
+ */
+
+static inline void minix_chain_cleanup(Indirect *chain, Indirect *partial)
+{
+	while (partial > chain) {
+		brelse(partial->bh);
+		partial--;
+	}
+}
+
+static inline void minix_iomap_set_mapped(struct iomap *iomap, sector_t phys,
+		unsigned int blkbits, sector_t iblock)
+{
+	iomap->type = IOMAP_MAPPED;
+	iomap->addr = (u64)phys << blkbits;
+	iomap->length = 1 << blkbits;
+	iomap->offset = (u64)iblock << blkbits;
+}
+
+static inline void minix_iomap_set_hole(struct iomap *iomap,
+		unsigned int blkbits, sector_t iblock)
+{
+	iomap->type = IOMAP_HOLE;
+	iomap->addr = IOMAP_NULL_ADDR;
+	iomap->length = 1 << blkbits;
+	iomap->offset = (u64)iblock << blkbits;
+}
+
+/*
+ * minix_iomap_begin - map a file range to disk blocks. It acts as a replacement
+ * for get_block in itree_common.c, at least in the important ways, and is
+ * adapted from it, but it uses iomap instead of buffer_head.
+ */
+static int minix_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
+	unsigned int flags, struct iomap *iomap, struct iomap *srcmap)
+{
+	struct super_block *sb = inode->i_sb;
+	unsigned int blkbits = sb->s_blocksize_bits;
+	sector_t iblock = offset >> blkbits;
+	int create = flags & IOMAP_WRITE;
+
+	int offsets[DEPTH];
+	Indirect chain[DEPTH];
+	Indirect *partial;
+	int depth = block_to_path(inode, iblock, offsets);
+	int left;
+	int err = -EIO;
+
+	sector_t phys;
+
+	/* block is beyond max file size */
+	if (depth == 0)
+		return -EINVAL;
+
+	iomap->bdev = inode->i_sb->s_bdev;
+
+reread:
+	partial = get_branch(inode, depth, offsets, chain, &err);
+
+	/* Simplest case - block found, no allocation needed */
+	if (!partial) {
+		iomap->flags = 0;
+		phys = block_to_cpu(chain[depth - 1].key);
+		partial = chain+depth-1;
+		minix_iomap_set_mapped(iomap, phys, blkbits, iblock);
+		minix_chain_cleanup(chain, partial);
+		return err;
+	}
+
+	/* Next simple case - plain lookup or failed read of indirect block */
+	if (!create || err == -EIO) {
+		minix_iomap_set_hole(iomap, blkbits, iblock);
+		minix_chain_cleanup(chain, partial);
+		return err;
+	}
+
+	/*
+	 * This is held over from the original get_block logic, where it
+	 * acted as a guard in case truncate() deleted blocks from under that
+	 * function. There should not be a race with iomap operations, but
+	 * we're retaining the defensive coding here to be extra safe just in
+	 * case.
+	 */
+	if (err == -EAGAIN) {
+		minix_chain_cleanup(chain, partial);
+		goto reread;
+	}
+
+	left = (chain + depth) - partial;
+	err = alloc_branch(inode, left, offsets + (partial - chain), partial);
+	if (err) {
+		minix_chain_cleanup(chain, partial);
+		return err;
+	}
+
+	if (splice_branch(inode, chain, partial, left) < 0) {
+		minix_chain_cleanup(chain, partial);
+		goto reread;
+	}
+
+	/* Successful allocation, mapping it. */
+	iomap->flags = IOMAP_F_NEW;
+	phys = block_to_cpu(chain[depth - 1].key);
+	minix_iomap_set_mapped(iomap, phys, blkbits, iblock);
+	minix_chain_cleanup(chain, partial);
+
+	return err;
+}
+
+/*
+ * minix_iomap_end ends up being a nop; since minix doesn't have any extents or
+ * transactions to worry about, there isn't anything to update here. The on-disk
+ * indirect blocks get dirtied in minix_iomap_begin.
+ */
+static int minix_iomap_end(struct inode *inode, loff_t offset, loff_t length,
+	ssize_t written, unsigned int flags, struct iomap *iomap)
+{
+	return 0;
+}
-- 
2.47.3


  parent reply	other threads:[~2026-07-11 20:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-11 20:59 [PATCH v3 0/5] minix: convert to iomap and add direct I/O Jeremy Bingham
2026-07-11 20:59 ` [PATCH v3 1/5] iomap: add iomap_symlink_write Jeremy Bingham
2026-07-13  9:44   ` Christoph Hellwig
2026-07-11 20:59 ` Jeremy Bingham [this message]
2026-07-13  9:46   ` [PATCH v3 2/5] minix: add base iomap begin/end functions Christoph Hellwig
2026-07-11 20:59 ` [PATCH v3 3/5] minix: update itree* files to add iomap functions Jeremy Bingham
2026-07-11 20:59 ` [PATCH v3 4/5] minix: add file operation functions Jeremy Bingham
2026-07-13  9:48   ` Christoph Hellwig
2026-07-13 19:17     ` Jeremy Bingham
2026-07-11 20:59 ` [PATCH v3 5/5] minix: iomap inode operations Jeremy Bingham
2026-07-13  9:32 ` [PATCH v3 0/5] minix: convert to iomap and add direct I/O Christoph Hellwig
2026-07-13 19:26   ` Jeremy Bingham
2026-07-14  0:53     ` Darrick J. Wong

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=555d199291b37e5c1241df648b3adcd760c1fca6.1783707063.git.jbingham@gmail.com \
    --to=jbingham@gmail.com \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=jkoolstra@xs4all.nl \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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®