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(-)
next 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.