All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Viacheslav Dubeyko <slava@dubeyko.com>
Cc: glaubitz@physik.fu-berlin.de, frank.li@vivo.com, hch@lst.de,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 6/6] hfsplus: switch address_space_operations on iomap-based support
Date: Fri, 24 Jul 2026 07:37:48 +0200	[thread overview]
Message-ID: <20260724053748.GG4181@lst.de> (raw)
In-Reply-To: <20260722213759.1360225-7-slava@dubeyko.com>

> @@ -605,20 +606,32 @@ void hfsplus_file_truncate(struct inode *inode)
>  		inode->i_ino, (long long)hip->phys_size, inode->i_size);
>  
>  	if (inode->i_size > hip->phys_size) {
> +		if (S_ISREG(inode->i_mode)) {
> +			res = hfsplus_iomap_cont_expand(inode, inode->i_size);
> +			if (res)
> +				return;
> +
> +			mark_inode_dirty(inode);
> +		} else {
> +			struct address_space *mapping = inode->i_mapping;
> +			struct folio *folio;
> +			void *fsdata = NULL;
> +
> +			res = hfsplus_write_begin(NULL, mapping,
> +						  inode->i_size, 0,
> +						  &folio, &fsdata);
> +			if (res)
> +				return;
> +
> +			res = generic_write_end(NULL, mapping,
> +						inode->i_size, 0, 0,
> +						folio, fsdata);
> +			if (res < 0)
> +				return;
> +
> +			mark_inode_dirty(inode);

Can't this use the iomap zeroing helpers?

> -static int hfsplus_writepages(struct address_space *mapping,
> +static int hfsplus_legacy_writepages(struct address_space *mapping,
>  			      struct writeback_control *wbc)
>  {
>  	return mpage_writepages(mapping, wbc, hfsplus_get_block);
> @@ -196,8 +139,8 @@ static int hfsplus_writepages(struct address_space *mapping,
>  const struct address_space_operations hfsplus_btree_aops = {
>  	.dirty_folio	= block_dirty_folio,
>  	.invalidate_folio = block_invalidate_folio,
> -	.read_folio	= hfsplus_read_folio,
> -	.writepages	= hfsplus_writepages,
> +	.read_folio	= hfsplus_legacy_read_folio,
> +	.writepages	= hfsplus_legacy_writepages,

Would btree be a better name then legacy?  So the story here is
there is a btree inode, and you want to keep the buffer_head based
path for this, at least for now?

> @@ -290,10 +274,22 @@ static int hfsplus_setattr(struct mnt_idmap *idmap,
>  	    attr->ia_size != i_size_read(inode)) {
>  		inode_dio_wait(inode);
>  		if (attr->ia_size > inode->i_size) {
> -			error = generic_cont_expand_simple(inode,
> -							   attr->ia_size);
> -			if (error)
> -				return error;
> +			if (S_ISREG(inode->i_mode)) {
> +				loff_t old_size = inode->i_size;
> +
> +				i_size_write(inode, attr->ia_size);
> +				error = hfsplus_iomap_cont_expand(inode,
> +								  attr->ia_size);
> +				if (error) {
> +					i_size_write(inode, old_size);
> +					return error;
> +				}
> +			} else {
> +				error = generic_cont_expand_simple(inode,
> +								   attr->ia_size);
> +				if (error)
> +					return error;
> +			}

You're not suppoed to see ->setattr for ATTR_SIZE for anything but
regular files from the VFS.  I don't think there's any hfsplus specific
path that could cause this either, could it?


      reply	other threads:[~2026-07-24  5:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22 21:37 [PATCH 0/6] hfsplus: convert regular file I/O to iomap-based operations Viacheslav Dubeyko
2026-07-22 21:37 ` [PATCH 1/6] hfs/hfsplus: exchange hardcoded number of extents on named constants Viacheslav Dubeyko
2026-07-24  5:28   ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 2/6] hfsplus: rework hfsplus_get_block() logic Viacheslav Dubeyko
2026-07-24  5:28   ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 3/6] hfsplus: take the bitmap page lock for allocate/free Viacheslav Dubeyko
2026-07-24  5:29   ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 4/6] hfsplus: add iomap operations for regular file data Viacheslav Dubeyko
2026-07-24  5:32   ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 5/6] hfsplus: add iomap-based file_operations Viacheslav Dubeyko
2026-07-24  5:33   ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 6/6] hfsplus: switch address_space_operations on iomap-based support Viacheslav Dubeyko
2026-07-24  5:37   ` Christoph Hellwig [this message]

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=20260724053748.GG4181@lst.de \
    --to=hch@lst.de \
    --cc=frank.li@vivo.com \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=slava@dubeyko.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.