All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: brauner@kernel.org, djwong@kernel.org,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] iomap: turn iomap_want_unshare_iter into an inline function
Date: Tue, 15 Oct 2024 09:11:53 -0400	[thread overview]
Message-ID: <Zw5qGY8asl0grLAD@bfoster> (raw)
In-Reply-To: <20241015041350.118403-1-hch@lst.de>

On Tue, Oct 15, 2024 at 06:13:50AM +0200, Christoph Hellwig wrote:
> iomap_want_unshare_iter currently sits in fs/iomap/buffered-io.c, which
> depends on CONFIG_BLOCK.  It is also in used in fs/dax.c whіch has no
> such dependency.  Given that it is a trivial check turn it into an inline
> in include/linux/iomap.h to fix the DAX && !BLOCK build.
> 
> Fixes: 6ef6a0e821d3 ("iomap: share iomap_unshare_iter predicate code with fsdax")
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---

Reviewed-by: Brian Foster <bfoster@redhat.com>

>  fs/iomap/buffered-io.c | 17 -----------------
>  include/linux/iomap.h  | 19 +++++++++++++++++++
>  2 files changed, 19 insertions(+), 17 deletions(-)
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 604f786be4bc54..ef0b68bccbb612 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1270,23 +1270,6 @@ void iomap_write_delalloc_release(struct inode *inode, loff_t start_byte,
>  }
>  EXPORT_SYMBOL_GPL(iomap_write_delalloc_release);
>  
> -bool iomap_want_unshare_iter(const struct iomap_iter *iter)
> -{
> -	/*
> -	 * Don't bother with blocks that are not shared to start with; or
> -	 * mappings that cannot be shared, such as inline data, delalloc
> -	 * reservations, holes or unwritten extents.
> -	 *
> -	 * Note that we use srcmap directly instead of iomap_iter_srcmap as
> -	 * unsharing requires providing a separate source map, and the presence
> -	 * of one is a good indicator that unsharing is needed, unlike
> -	 * IOMAP_F_SHARED which can be set for any data that goes into the COW
> -	 * fork for XFS.
> -	 */
> -	return (iter->iomap.flags & IOMAP_F_SHARED) &&
> -		iter->srcmap.type == IOMAP_MAPPED;
> -}
> -
>  static loff_t iomap_unshare_iter(struct iomap_iter *iter)
>  {
>  	struct iomap *iomap = &iter->iomap;
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index e04c060e8fe185..664c5f2f0aaa2d 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -270,6 +270,25 @@ static inline loff_t iomap_last_written_block(struct inode *inode, loff_t pos,
>  	return round_up(pos + written, i_blocksize(inode));
>  }
>  
> +/*
> + * Check if the range needs to be unshared for a FALLOC_FL_UNSHARE_RANGE
> + * operation.
> + *
> + * Don't bother with blocks that are not shared to start with; or mappings that
> + * cannot be shared, such as inline data, delalloc reservations, holes or
> + * unwritten extents.
> + *
> + * Note that we use srcmap directly instead of iomap_iter_srcmap as unsharing
> + * requires providing a separate source map, and the presence of one is a good
> + * indicator that unsharing is needed, unlike IOMAP_F_SHARED which can be set
> + * for any data that goes into the COW fork for XFS.
> + */
> +static inline bool iomap_want_unshare_iter(const struct iomap_iter *iter)
> +{
> +	return (iter->iomap.flags & IOMAP_F_SHARED) &&
> +		iter->srcmap.type == IOMAP_MAPPED;
> +}
> +
>  ssize_t iomap_file_buffered_write(struct kiocb *iocb, struct iov_iter *from,
>  		const struct iomap_ops *ops, void *private);
>  int iomap_read_folio(struct folio *folio, const struct iomap_ops *ops);
> -- 
> 2.45.2
> 
> 


  reply	other threads:[~2024-10-15 13:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-15  4:13 [PATCH] iomap: turn iomap_want_unshare_iter into an inline function Christoph Hellwig
2024-10-15 13:11 ` Brian Foster [this message]
2024-10-15 13:54 ` Christian Brauner
2024-10-15 16:18 ` 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=Zw5qGY8asl0grLAD@bfoster \
    --to=bfoster@redhat.com \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lkp@intel.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.