The Linux Kernel Mailing List
 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 0/5] minix: convert to iomap and add direct I/O
Date: Sat, 11 Jul 2026 13:59:04 -0700	[thread overview]
Message-ID: <cover.1783707063.git.jbingham@gmail.com> (raw)

This is version 3 of the minix iomap conversion patch series. Versions 1
and 2 both had issues that syzbot found while testing, while Darrick J.
Wong gave some critiques of the version 2 patches that I have addressed
here.

This patch series converts the minix filesystem module from using the
buffer_head based path to the iomap API, and adds direct I/O support in
the process.

Patch 1 adds a new iomap_symlink_write function to
fs/iomap/buffered-io.c. This allows minix's symlinks to be written and
read without bypassing iomap entirely. (I considered whether this ought
to be broken out as its own patch since it's outside of fs/minix, but
decided that since it was suggested as part of this and is a necessary
piece that I would include it unless told otherwise.) This was suggested
by Darrick J. Wong, who also provided an initial implementation that I
only had to modify slightly.

Patch 2 adds the base iomap functions in fs/minix/iomap.c. This provides
the iomap begin/end functions which sit at the base of the rest of this.

Patch 3 wires iomap.c into the itree*.c files, adds version specific
helper functions, and moves the old buffer_head based functions over to
new names to support directory operations.

Patch 4 adds the new iomap file operations functions to file.c,
including the direct i/o functions.

Patch 5 updates the inode operations to use iomap, except for directory
operations which work the old way. The minix_symlink function in namei.c
is also updated to use the new iomap_write_symlink function.

Changes since v2:
  * Reorganized the patches entirely.
  * Addressed Darrick Wong's critiques of v2:
    - Added a new iomap_symlink_write function per his suggestion.
    - Removed the minix custom __page_symlink function that replaced the
      usual page_symlink function and the changes to minix_get_link that
      allowed symlinks to be written and read by bypassing iomap
      entirely. This ended up also removing both the issue syzbot found
      in v2 of the patch and the fix for it.
    - Reworked minix_iomap_begin to remove the nest of gotos inherited
      from get_block to use helper functions instead.
    - Pared down some unnecessary comments.
    - Dropped bmap entirely.
    - Dropped IOMAP_F_MERGED in minix_iomap_begin since there aren't any
      merged blocks to worry about.
    - Removed unneeded manual page cache invalidation.

This patch series has been verified to compile cleanly between each
patch and has been tested with a script that exercises mounting,
unmounting, file creation/writing/reading/verification, directory
creation and listing, symlink creation/reading/following, hard links,
file truncation (both shrinking and growing), deep directory nesting,
large files that span multiple blocks and indirect blocks for both size
and content, deleting files and directories, persistence, and that
fsck.minix behaves as expected for all versions of the minix filesystem.

Unfortunately, no version of the minix fs module can support an xfstests
run; all of the tests either fail (seemingly for reasons unrelated to
the module itself) or aren't run because minix doesn't support the
features in question. Getting xfstests to run would be nice, but either
requires or would be greatly helped by making changes to minix's mkfs
and fsck programs. It would definitely be a nice-to-have, but is outside
the scope of this series.

Jeremy Bingham (5):
  iomap: add iomap_symlink_write
  minix: add base iomap begin/end functions
  minix: update itree* files to add iomap functions
  minix: add file operation functions
  minix: iomap inode operations

 fs/iomap/buffered-io.c  |  31 ++++++++
 fs/minix/file.c         | 153 ++++++++++++++++++++++++++++++++++++++--
 fs/minix/inode.c        |  87 +++++++++++++++++++----
 fs/minix/iomap.c        | 122 ++++++++++++++++++++++++++++++++
 fs/minix/itree_common.c |  11 ++-
 fs/minix/itree_v1.c     |  25 ++++++-
 fs/minix/itree_v2.c     |  17 ++++-
 fs/minix/minix.h        |  24 ++++++-
 fs/minix/namei.c        |   8 ++-
 include/linux/iomap.h   |   4 ++
 10 files changed, 457 insertions(+), 25 deletions(-)
 create mode 100644 fs/minix/iomap.c

-- 
2.47.3


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

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-11 20:59 Jeremy Bingham [this message]
2026-07-11 20:59 ` [PATCH v3 1/5] iomap: add iomap_symlink_write Jeremy Bingham
2026-07-11 20:59 ` [PATCH v3 2/5] minix: add base iomap begin/end functions Jeremy Bingham
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-11 20:59 ` [PATCH v3 5/5] minix: iomap inode operations Jeremy Bingham

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=cover.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