linux-fsdevel.vger.kernel.org archive mirror
 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 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).