All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	david@fromorbit.com, linux-kernel@vger.kernel.org,
	sandeen@sandeen.net, hch@lst.de,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	Theodore Ts'o <tytso@mit.edu>,
	riteshh@linux.ibm.com, rgoldwyn@suse.de, agruenba@redhat.com,
	linux-btrfs@vger.kernel.org
Subject: [GIT PULL] iomap: new code for 5.10-rc1
Date: Tue, 13 Oct 2020 09:41:31 -0700	[thread overview]
Message-ID: <20201013164131.GB9832@magnolia> (raw)

Hi Linus,

Please pull these new changes to the iomap code for 5.10.  There's not a
lot of new stuff going on here -- a little bit of code refactoring to
make iomap workable with btrfs' fsync locking model, cleanups in
preparation for adding THP support for filesystems, and fixing a data
corruption issue for blocksize < pagesize filesystems.

The branch merges cleanly with your HEAD branch as of a few minutes ago.
Please let me know if there are any strange problems.  It's been a
pretty quiet cycle, so I don't anticipate any more iomap pulls other
than whatever new bug fixes show up.

--D

The following changes since commit f4d51dffc6c01a9e94650d95ce0104964f8ae822:

  Linux 5.9-rc4 (2020-09-06 17:11:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/iomap-5.10-merge-4

for you to fetch changes up to 1a31182edd0083bb9f26e582ed39f92f898c4d0a:

  iomap: Call inode_dio_end() before generic_write_sync() (2020-09-28 08:51:08 -0700)

----------------------------------------------------------------
New code for 5.10:
- Don't WARN_ON weird states that unprivileged users can create.
- Don't invalidate page cache when direct writes want to fall back to
  buffered.
- Fix some problems when readahead ios fail.
- Fix a problem where inline data pages weren't getting flushed during
  an unshare operation.
- Rework iomap to support arbitrarily many blocks per page in
  preparation to support THP for the page cache.
- Fix a bug in the blocksize < pagesize buffered io path where we could
  fail to initialize the many-blocks-per-page uptodate bitmap correctly
  when the backing page is actually up to date.  This could cause us to
  forget to write out dirty pages.
- Split out the generic_write_sync at the end of the directio write path
  so that btrfs can drop the inode lock before sync'ing the file.
- Call inode_dio_end before trying to sync the file after a O_DSYNC
  direct write (instead of afterwards) to match the behavior of the
  old directio code.

----------------------------------------------------------------
Andreas Gruenbacher (1):
      iomap: Fix direct I/O write consistency check

Christoph Hellwig (1):
      iomap: Allow filesystem to call iomap_dio_complete without i_rwsem

Goldwyn Rodrigues (1):
      iomap: Call inode_dio_end() before generic_write_sync()

Matthew Wilcox (Oracle) (12):
      iomap: Clear page error before beginning a write
      iomap: Mark read blocks uptodate in write_begin
      iomap: Fix misplaced page flushing
      fs: Introduce i_blocks_per_page
      iomap: Use kzalloc to allocate iomap_page
      iomap: Use bitmap ops to set uptodate bits
      iomap: Support arbitrarily many blocks per page
      iomap: Convert read_count to read_bytes_pending
      iomap: Convert write_count to write_bytes_pending
      iomap: Convert iomap_write_end types
      iomap: Change calling convention for zeroing
      iomap: Set all uptodate bits for an Uptodate page

Nikolay Borisov (1):
      iomap: Use round_down/round_up macros in __iomap_write_begin

Qian Cai (1):
      iomap: fix WARN_ON_ONCE() from unprivileged users

 fs/dax.c                |  13 ++--
 fs/iomap/buffered-io.c  | 194 ++++++++++++++++++++----------------------------
 fs/iomap/direct-io.c    |  49 +++++++++---
 fs/jfs/jfs_metapage.c   |   2 +-
 fs/xfs/xfs_aops.c       |   2 +-
 include/linux/dax.h     |   3 +-
 include/linux/iomap.h   |   5 ++
 include/linux/pagemap.h |  16 ++++
 8 files changed, 150 insertions(+), 134 deletions(-)

             reply	other threads:[~2020-10-13 16:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 16:41 Darrick J. Wong [this message]
2020-10-14 19:30 ` [GIT PULL] iomap: new code for 5.10-rc1 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=20201013164131.GB9832@magnolia \
    --to=djwong@kernel.org \
    --cc=agruenba@redhat.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=rgoldwyn@suse.de \
    --cc=riteshh@linux.ibm.com \
    --cc=sandeen@sandeen.net \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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.