mm-commits.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruenba@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: mm-commits@vger.kernel.org, tytso@mit.edu, djwong@kernel.org,
	adilger.kernel@dilger.ca, willy@infradead.org
Subject: Re: + mm-add-folio_fill_tail-and-use-it-in-iomap.patch added to mm-unstable branch
Date: Thu, 9 Nov 2023 22:57:27 +0100	[thread overview]
Message-ID: <CAHc6FU7hnOVQh=P_-su5HzroH4SxXHPc9QuUv9qP8rPbs57xyQ@mail.gmail.com> (raw)
In-Reply-To: <20231109215449.006A9C433C8@smtp.kernel.org>

On Thu, Nov 9, 2023 at 10:55 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> The patch titled
>      Subject: mm: add folio_fill_tail() and use it in iomap
> has been added to the -mm mm-unstable branch.  Its filename is
>      mm-add-folio_fill_tail-and-use-it-in-iomap.patch
>
> This patch will shortly appear at
>      https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-add-folio_fill_tail-and-use-it-in-iomap.patch
>
> This patch will later appear in the mm-unstable branch at
>     git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>
> Before you just go and hit "reply", please:
>    a) Consider who else should be cc'ed
>    b) Prefer to cc a suitable mailing list as well
>    c) Ideally: find the original patch on the mailing list and do a
>       reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
>
> The -mm tree is included into linux-next via the mm-everything
> branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> and is updated there every 2-3 working days
>
> ------------------------------------------------------
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> Subject: mm: add folio_fill_tail() and use it in iomap
> Date: Tue, 7 Nov 2023 21:26:41 +0000
>
> The iomap code was limited to PAGE_SIZE bytes; generalise it to cover
> an arbitrary-sized folio, and move it to be a common helper.
>
> Link: https://lkml.kernel.org/r/20231107212643.3490372-3-willy@infradead.org
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> Cc: Andreas Dilger <adilger.kernel@dilger.ca>
> Cc: Andreas Gruenbacher <agruenba@redhat.com>
> Cc: Darrick J. Wong <djwong@kernel.org>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
>  fs/iomap/buffered-io.c  |   14 ++------------
>  include/linux/highmem.h |   38 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 40 insertions(+), 12 deletions(-)
>
> --- a/fs/iomap/buffered-io.c~mm-add-folio_fill_tail-and-use-it-in-iomap
> +++ a/fs/iomap/buffered-io.c
> @@ -305,28 +305,18 @@ static int iomap_read_inline_data(const
>  {
>         const struct iomap *iomap = iomap_iter_srcmap(iter);
>         size_t size = i_size_read(iter->inode) - iomap->offset;
> -       size_t poff = offset_in_page(iomap->offset);
>         size_t offset = offset_in_folio(folio, iomap->offset);
> -       void *addr;
>
>         if (folio_test_uptodate(folio))
>                 return 0;
>
> -       if (WARN_ON_ONCE(size > PAGE_SIZE - poff))
> -               return -EIO;
> -       if (WARN_ON_ONCE(size > PAGE_SIZE -
> -                        offset_in_page(iomap->inline_data)))
> -               return -EIO;
>         if (WARN_ON_ONCE(size > iomap->length))
>                 return -EIO;
>         if (offset > 0)
>                 ifs_alloc(iter->inode, folio, iter->flags);
>
> -       addr = kmap_local_folio(folio, offset);
> -       memcpy(addr, iomap->inline_data, size);
> -       memset(addr + size, 0, PAGE_SIZE - poff - size);
> -       kunmap_local(addr);
> -       iomap_set_range_uptodate(folio, offset, PAGE_SIZE - poff);
> +       folio_fill_tail(folio, offset, iomap->inline_data, size);
> +       iomap_set_range_uptodate(folio, offset, folio_size(folio) - offset);
>         return 0;
>  }
>
> --- a/include/linux/highmem.h~mm-add-folio_fill_tail-and-use-it-in-iomap
> +++ a/include/linux/highmem.h
> @@ -522,6 +522,44 @@ static inline __must_check void *folio_z
>  }
>
>  /**
> + * folio_fill_tail - Copy some data to a folio and pad with zeroes.
> + * @folio: The destination folio.
> + * @offset: The offset into @folio at which to start copying.
> + * @from: The data to copy.
> + * @len: How many bytes of data to copy.
> + *
> + * This function is most useful for filesystems which support inline data.
> + * When they want to copy data from the inode into the page cache, this
> + * function does everything for them.  It supports large folios even on
> + * HIGHMEM configurations.
> + */
> +static inline void folio_fill_tail(struct folio *folio, size_t offset,
> +               const char *from, size_t len)
> +{
> +       char *to = kmap_local_folio(folio, offset);
> +
> +       VM_BUG_ON(offset + len > folio_size(folio));
> +
> +       if (folio_test_highmem(folio)) {
> +               size_t max = PAGE_SIZE - offset_in_page(offset);
> +
> +               while (len > max) {
> +                       memcpy(to, from, max);
> +                       kunmap_local(to);
> +                       len -= max;
> +                       from += max;
> +                       offset += max;
> +                       max = PAGE_SIZE;
> +                       to = kmap_local_folio(folio, offset);
> +               }
> +       }
> +
> +       memcpy(to, from, len);
> +       to = folio_zero_tail(folio, offset, to);

Please note the fix to this patch which I've just posted,

to = folio_zero_tail(folio, offset + len, to + len);

> +       kunmap_local(to);
> +}
> +
> +/**
>   * memcpy_from_file_folio - Copy some bytes from a file folio.
>   * @to: The destination buffer.
>   * @folio: The folio to copy from.
> _
>
> Patches currently in -mm which might be from willy@infradead.org are
>
> mm-add-folio_zero_tail-and-use-it-in-ext4.patch
> mm-add-folio_fill_tail-and-use-it-in-iomap.patch
> gfs2-convert-stuffed_readpage-to-stuffed_read_folio.patch
> mm-remove-test_set_page_writeback.patch
> afs-do-not-test-the-return-value-of-folio_start_writeback.patch
> smb-do-not-test-the-return-value-of-folio_start_writeback.patch
> mm-return-void-from-folio_start_writeback-and-related-functions.patch
> mm-make-mapping_evict_folio-the-preferred-way-to-evict-clean-folios.patch
> mm-convert-__do_fault-to-use-a-folio.patch
> mm-use-mapping_evict_folio-in-truncate_error_page.patch
> mm-convert-soft_offline_in_use_page-to-use-a-folio.patch
> mm-convert-isolate_page-to-mf_isolate_folio.patch
> mm-remove-invalidate_inode_page.patch
>

Thanks,
Andreas


      reply	other threads:[~2023-11-09 21:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09 21:54 + mm-add-folio_fill_tail-and-use-it-in-iomap.patch added to mm-unstable branch Andrew Morton
2023-11-09 21:57 ` Andreas Gruenbacher [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='CAHc6FU7hnOVQh=P_-su5HzroH4SxXHPc9QuUv9qP8rPbs57xyQ@mail.gmail.com' \
    --to=agruenba@redhat.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=djwong@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).