All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	nvdimm@lists.linux.dev, Dan Williams <dan.j.williams@intel.com>
Subject: Re: [GIT PULL] iomap for 5.17
Date: Tue, 11 Jan 2022 16:30:59 -0800	[thread overview]
Message-ID: <20220112003059.GH398655@magnolia> (raw)
In-Reply-To: <YdyoN7RU/JMOk/lW@casper.infradead.org>

On Mon, Jan 10, 2022 at 09:42:15PM +0000, Matthew Wilcox wrote:
> I know these requests usually come from Darrick, and we had intended
> that they would come that route.  Between the holidays and various
> things which Darrick needed to work on, he asked if I could send the
> pull request directly.  There weren't any other iomap patches pending
> for this release, which probably also played a role.

Just to confirm this explicitly -- yes, it really did transpire that
Matthew submitted the only iomap patches for 5.17, so I told him to go
ahead and send a pull request straight to Linus.

--D

> There is a conflict between this tree and the nvdimm tree.  We've done
> our best to make the resolution easy for you with the last patch in this
> series ("Inline __iomap_zero_iter into its caller").  If you'd rather just
> resolve the entire conflict yourself, feel free to drop that last patch.
> 
> The resolution Stephen has been carrying is here:
> https://lore.kernel.org/all/20211224172421.3f009baa@canb.auug.org.au/
> 
> The following changes since commit 2585cf9dfaaddf00b069673f27bb3f8530e2039c:
> 
>   Linux 5.16-rc5 (2021-12-12 14:53:01 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.infradead.org/users/willy/linux.git tags/iomap-5.17
> 
> for you to fetch changes up to 4d7bd0eb72e5831ddb1288786a96448b48440825:
> 
>   iomap: Inline __iomap_zero_iter into its caller (2021-12-21 13:51:08 -0500)
> 
> ----------------------------------------------------------------
> Convert xfs/iomap to use folios
> 
> This should be all that is needed for XFS to use large folios.
> There is no code in this pull request to create large folios, but
> no additional changes should be needed to XFS or iomap once they
> are created.
> 
> ----------------------------------------------------------------
> Matthew Wilcox (Oracle) (26):
>       block: Add bio_add_folio()
>       block: Add bio_for_each_folio_all()
>       fs/buffer: Convert __block_write_begin_int() to take a folio
>       iomap: Convert to_iomap_page to take a folio
>       iomap: Convert iomap_page_create to take a folio
>       iomap: Convert iomap_page_release to take a folio
>       iomap: Convert iomap_releasepage to use a folio
>       iomap: Add iomap_invalidate_folio
>       iomap: Pass the iomap_page into iomap_set_range_uptodate
>       iomap: Convert bio completions to use folios
>       iomap: Use folio offsets instead of page offsets
>       iomap: Convert iomap_read_inline_data to take a folio
>       iomap: Convert readahead and readpage to use a folio
>       iomap: Convert iomap_page_mkwrite to use a folio
>       iomap: Allow iomap_write_begin() to be called with the full length
>       iomap: Convert __iomap_zero_iter to use a folio
>       iomap: Convert iomap_write_begin() and iomap_write_end() to folios
>       iomap: Convert iomap_write_end_inline to take a folio
>       iomap,xfs: Convert ->discard_page to ->discard_folio
>       iomap: Simplify iomap_writepage_map()
>       iomap: Simplify iomap_do_writepage()
>       iomap: Convert iomap_add_to_ioend() to take a folio
>       iomap: Convert iomap_migrate_page() to use folios
>       iomap: Support large folios in invalidatepage
>       xfs: Support large folios
>       iomap: Inline __iomap_zero_iter into its caller
> 
>  Documentation/core-api/kernel-api.rst |   1 +
>  block/bio.c                           |  22 ++
>  fs/buffer.c                           |  23 +-
>  fs/internal.h                         |   2 +-
>  fs/iomap/buffered-io.c                | 551 +++++++++++++++++-----------------
>  fs/xfs/xfs_aops.c                     |  24 +-
>  fs/xfs/xfs_icache.c                   |   2 +
>  include/linux/bio.h                   |  56 +++-
>  include/linux/iomap.h                 |   3 +-
>  9 files changed, 389 insertions(+), 295 deletions(-)
> 

  reply	other threads:[~2022-01-12  0:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-10 21:42 [GIT PULL] iomap for 5.17 Matthew Wilcox
2022-01-12  0:30 ` Darrick J. Wong [this message]
2022-01-12 21:07 ` pr-tracker-bot

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=20220112003059.GH398655@magnolia \
    --to=djwong@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=torvalds@linux-foundation.org \
    --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 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.