All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Jeremy Bingham <jbingham@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	brauner@kernel.org, jkoolstra@xs4all.nl, jack@suse.cz,
	hch@infradead.org, viro@zeniv.linux.org.uk,
	syzkaller@googlegroups.com
Subject: Re: [PATCH v2 2/4] minix: convert address space operations to iomap
Date: Wed, 1 Jul 2026 11:47:07 -0700	[thread overview]
Message-ID: <20260701184707.GE6507@frogsfrogsfrogs> (raw)
In-Reply-To: <CAMyBmMCVQpA+X_M6nH1nx6O-QCfng2OWqrDWOxcL7qNohE797Q@mail.gmail.com>

On Wed, Jul 01, 2026 at 11:37:10AM -0700, Jeremy Bingham wrote:
> On Wed, Jul 1, 2026 at 11:14 AM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > On Sat, Jun 27, 2026 at 10:15:54PM -0700, Jeremy Bingham wrote:
> > > Convert minix regular file and symlink address space operations from
> > > buffer_head to iomap. The new minix_aops uses iomap_dirty_folio,
> > > iomap_invalidate_folio, iomap_bio_read_folio, iomap_bio_readahead,
> > > iomap_writepages, iomap_bmap, and related iomap helpers.
> > > The write_begin/write_end callbacks are removed since buffered writes
> > > now go through iomap_file_buffered_write in file.c.
> > >
> > > Directories keep using buffer_heads via a new minix_dir_aops, which
> > > retains the old block_dirty_folio, block_read_full_folio,
> > > block_write_begin, generic_write_end, and mpage_writepages. This is
> > > necessary because directory entry manipulation (minix_prepare_chunk,
> > > minix_write_begin) still uses the buffer_head chunk protocol.
> > >
> > > minix_bmap is converted from generic_block_bmap to iomap_bmap.
> >
> > I'd drop BMAP support entirely, unless you know of people who use LILO
> > and minixfs.  If all you want is swapfile activation, use
> > iomap_swapfile_activate... assuming that anyone actually cares about
> > hosting swapfiles on minixfs.
> 
> I'm not dead set against dropping BMAP support entirely, but is there a
> compelling reason to drop it?

It's a terrible legacy interface -- you can only ask about a single
block, the block and sector numbers are limited to u32, the magic value
0 means no mapping, and it doesn't actually tell you which device.

Anyone who really wants to find the sparse areas of a file would be
better off calling SEEK_{DATA,HOLE} ... which I guess is something you
could implement as part of this patchset.

--D

> Thanks,
> 
> -j
> 
> > > The minix_get_block function is exported (non-static) so the
> > > directory aops can still use it for block_write_begin and
> > > mpage_writepages.
> > >
> > > Signed-off-by: Jeremy Bingham <jbingham@gmail.com>
> > > ---
> > >  fs/minix/inode.c | 86 +++++++++++++++++++++++++++++++++++++++++++-----
> > >  1 file changed, 78 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/fs/minix/inode.c b/fs/minix/inode.c
> > > index c30cc590698d..2ba6766fce51 100644
> > > --- a/fs/minix/inode.c
> > > +++ b/fs/minix/inode.c
> > > @@ -436,7 +436,32 @@ static int minix_statfs(struct dentry *dentry, struct kstatfs *buf)
> > >       return 0;
> > >  }
> > >
> > > -static int minix_get_block(struct inode *inode, sector_t block,
> > > +static ssize_t minix_writeback_range(struct iomap_writepage_ctx *wpc,
> > > +     struct folio *folio, u64 pos, unsigned int len, u64 end_pos)
> > > +{
> > > +     int error;
> > > +
> > > +     if (pos < wpc->iomap.offset ||
> > > +                     pos >= wpc->iomap.offset + wpc->iomap.length) {
> > > +             if (INODE_VERSION(wpc->inode) == MINIX_V1)
> > > +                     error = V1_minix_iomap_begin(wpc->inode, pos, len, IOMAP_WRITE,
> > > +                             &wpc->iomap, NULL);
> > > +             else
> > > +                     error = V2_minix_iomap_begin(wpc->inode, pos, len, IOMAP_WRITE,
> > > +                             &wpc->iomap, NULL);
> > > +             if (error)
> > > +                     return error;
> > > +     }
> > > +
> > > +     return iomap_add_to_ioend(wpc, folio, pos, end_pos, len);
> > > +}
> > > +
> > > +static const struct iomap_writeback_ops minix_writeback_ops = {
> > > +     .writeback_range = minix_writeback_range,
> > > +     .writeback_submit = iomap_ioend_writeback_submit,
> > > +};
> > > +
> > > +int minix_get_block(struct inode *inode, sector_t block,
> > >                   struct buffer_head *bh_result, int create)
> > >  {
> > >       if (INODE_VERSION(inode) == MINIX_V1)
> > > @@ -445,17 +470,45 @@ static int minix_get_block(struct inode *inode, sector_t block,
> > >               return V2_minix_get_block(inode, block, bh_result, create);
> > >  }
> > >
> > > -static int minix_writepages(struct address_space *mapping,
> > > +/* The old minix_writepages, preserved for directory operations. */
> > > +static int minix_block_writepages(struct address_space *mapping,
> > >               struct writeback_control *wbc)
> > >  {
> > >       return mpage_writepages(mapping, wbc, minix_get_block);
> > >  }
> > >
> > > +static int minix_writepages(struct address_space *mapping,
> > > +             struct writeback_control *wbc)
> > > +{
> > > +     struct iomap_writepage_ctx wpc = {
> > > +             .inode = mapping->host,
> > > +             .wbc = wbc,
> > > +             .ops = &minix_writeback_ops,
> > > +     };
> > > +     return iomap_writepages(&wpc);
> > > +}
> > > +
> > >  static int minix_read_folio(struct file *file, struct folio *folio)
> > > +{
> > > +     const struct iomap_ops *ops = minix_iomap_ops_ver(folio->mapping->host);
> > > +
> > > +     iomap_bio_read_folio(folio, ops);
> > > +     return 0;
> > > +}
> > > +
> > > +/* The old minix_read_folio, preserved for directory operations. */
> > > +static int minix_block_read_folio(struct file *file, struct folio *folio)
> > >  {
> > >       return block_read_full_folio(folio, minix_get_block);
> > >  }
> > >
> > > +static void minix_readahead(struct readahead_control *rac)
> > > +{
> > > +     const struct iomap_ops *ops = minix_iomap_ops_ver(rac->mapping->host);
> > > +
> > > +     iomap_bio_readahead(rac, ops);
> > > +}
> > > +
> > >  int minix_prepare_chunk(struct folio *folio, loff_t pos, unsigned len)
> > >  {
> > >       return __block_write_begin(folio, pos, len, minix_get_block);
> > > @@ -487,19 +540,36 @@ static int minix_write_begin(const struct kiocb *iocb,
> > >
> > >  static sector_t minix_bmap(struct address_space *mapping, sector_t block)
> > >  {
> > > -     return generic_block_bmap(mapping,block,minix_get_block);
> > > +     const struct iomap_ops *ops = minix_iomap_ops_ver(mapping->host);
> > > +
> > > +     return iomap_bmap(mapping, block, ops);
> > >  }
> > >
> > > -static const struct address_space_operations minix_aops = {
> > > -     .dirty_folio    = block_dirty_folio,
> > > -     .invalidate_folio = block_invalidate_folio,
> > > +const struct address_space_operations minix_aops = {
> > > +     .dirty_folio    = iomap_dirty_folio,
> > > +     .invalidate_folio = iomap_invalidate_folio,
> > >       .read_folio = minix_read_folio,
> > > +     .readahead = minix_readahead,
> > >       .writepages = minix_writepages,
> > > +     .migrate_folio = filemap_migrate_folio,
> > > +     .bmap = minix_bmap,
> > > +     .is_partially_uptodate = iomap_is_partially_uptodate,
> > > +     .release_folio = iomap_release_folio,
> > > +     .error_remove_folio = generic_error_remove_folio,
> > > +};
> > > +
> > > +/* A special aops for directories that keeps using the buffer head chunks, at
> > > + * least for the time being.
> > > + */
> > > +static const struct address_space_operations minix_dir_aops = {
> > > +     .dirty_folio = block_dirty_folio,
> > > +     .invalidate_folio = block_invalidate_folio,
> > > +     .read_folio = minix_block_read_folio,
> > >       .write_begin = minix_write_begin,
> > >       .write_end = generic_write_end,
> > >       .migrate_folio = buffer_migrate_folio,
> > >       .bmap = minix_bmap,
> > > -     .direct_IO = noop_direct_IO
> >
> > I forget, does one have to set FMODE_CAN_ODIRECT if the address_space
> > operations don't supply a ->direct_IO function?
> >
> > --D
> >
> > > +     .writepages = minix_block_writepages,
> > >  };
> > >
> > >  static const struct inode_operations minix_symlink_inode_operations = {
> > > @@ -516,7 +586,7 @@ void minix_set_inode(struct inode *inode, dev_t rdev)
> > >       } else if (S_ISDIR(inode->i_mode)) {
> > >               inode->i_op = &minix_dir_inode_operations;
> > >               inode->i_fop = &minix_dir_operations;
> > > -             inode->i_mapping->a_ops = &minix_aops;
> > > +             inode->i_mapping->a_ops = &minix_dir_aops;
> > >       } else if (S_ISLNK(inode->i_mode)) {
> > >               inode->i_op = &minix_symlink_inode_operations;
> > >               inode_nohighmem(inode);
> > > --
> > > 2.47.3
> > >
> > >
> 

  reply	other threads:[~2026-07-01 18:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-28  5:15 [PATCH v2 0/4] minix: convert to iomap and add direct I/O Jeremy Bingham
2026-06-28  5:15 ` [PATCH v2 1/4] minix: add iomap infrastructure Jeremy Bingham
2026-07-01 18:06   ` Darrick J. Wong
2026-07-01 18:32     ` Jeremy Bingham
2026-06-28  5:15 ` [PATCH v2 2/4] minix: convert address space operations to iomap Jeremy Bingham
2026-07-01 18:14   ` Darrick J. Wong
2026-07-01 18:37     ` Jeremy Bingham
2026-07-01 18:47       ` Darrick J. Wong [this message]
2026-06-28  5:15 ` [PATCH v2 3/4] minix: convert file operations to iomap and add Jeremy Bingham
2026-07-01 18:21   ` Darrick J. Wong
2026-07-01 18:42     ` Jeremy Bingham
2026-06-28  5:15 ` [PATCH v2 4/4] minix: fix symlink and truncate for iomap Jeremy Bingham
2026-06-29  5:27 ` [syzbot ci] Re: minix: convert to iomap and add direct I/O syzbot ci
2026-06-30  3:05   ` Jeremy Bingham
2026-06-30  4:05     ` syzbot ci
2026-07-01 18:00 ` [PATCH v2 0/4] " Darrick J. Wong
2026-07-02 18:42   ` 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=20260701184707.GE6507@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=brauner@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=jbingham@gmail.com \
    --cc=jkoolstra@xs4all.nl \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller@googlegroups.com \
    --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 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.