| Message ID | 20200805153214.GA6090@magnolia (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | [GIT,PULL] iomap: new code for 5.9-rc1 | expand |
Hi Darrick, On Wed, Aug 5, 2020 at 5:40 PM Darrick J. Wong <djwong@kernel.org> wrote: > ---------------------------------------------------------------- > Andreas Gruenbacher (1): > iomap: Make sure iomap_end is called after iomap_begin that commit (d1b4f507d71de) contains the following garbage in the commit message: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- How did it come to that? Thanks, Andreas
On Wed, Aug 05, 2020 at 09:23:49AM -0700, Darrick J. Wong wrote: > On Wed, Aug 05, 2020 at 05:54:31PM +0200, Andreas Gruenbacher wrote: > > Hi Darrick, > > > > On Wed, Aug 5, 2020 at 5:40 PM Darrick J. Wong <djwong@kernel.org> wrote: > > > ---------------------------------------------------------------- > > > Andreas Gruenbacher (1): > > > iomap: Make sure iomap_end is called after iomap_begin > > > > that commit (d1b4f507d71de) contains the following garbage in the > > commit message: > > > > The message from this sender included one or more files > > which could not be scanned for virus detection; do not > > open these files unless you are certain of the sender's intent. > > > > ---------------------------------------------------------------------- > > > > How did it come to that? > > I have no idea. It's not in the email that I turned into a patch, but > golly roundtripping git patches through email and back to git sucks. Aha-- the effing Oracle email virus scanner doesn't run on mails coming in via mailing lists (which is the copy that I keep in my archive) but the copy that you sent direct to me /did/ get a virus scan, which failed because it's too stupid to recognize plain text, so the virus scanner injected its stupid warning *into the message body*, and then I git-am'd that without noticing. S'ok, they're moving us to Exchange soon, so I expect never to hear from any of you ever again. --D > > Oh well, I guess I have to rebase the whole branch now. > > Linus: please ignore this pull request. > > --D > > > > > Thanks, > > Andreas > > >
Hi Linus, Please pull these new changes to the iomap code for 5.9. The most notable changes are: 1) iomap no longer invalidate the page cache when performing a direct read, since doing so is unnecessary and the old directio code doesn't do that either. 2) iomap embraced the use of returning ENOTBLK from a direct write to trigger falling back to a buffered write since ext4 already did this and btrfs wants it for their port. 3) iomap falls back to buffered writes if we're doing a direct write and the page cache invalidation after the flush fails; this was necessary to handle a corner case in the btrfs port. The branch merges cleanly with your HEAD branch as of 15m ago. Please let me know if there are any strange problems. --D The following changes since commit dcb7fd82c75ee2d6e6f9d8cc71c52519ed52e258: Linux 5.8-rc4 (2020-07-05 16:20:22 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/iomap-5.9-merge-4 for you to fetch changes up to 66143873c6a0b24242f24f65fde70c643b26b4e7: iomap: fall back to buffered writes for invalidation failures (2020-07-23 22:45:59 -0700) ---------------------------------------------------------------- New code for 5.9: - Make sure we call ->iomap_end with a failure code if ->iomap_begin failed in any way; some filesystems need to try to undo things. - Don't invalidate the page cache during direct reads since we already sync'd the cache with disk. - Make direct writes fall back to the page cache if the pre-write cache invalidation fails. This avoids a cache coherency problem. ---------------------------------------------------------------- Andreas Gruenbacher (1): iomap: Make sure iomap_end is called after iomap_begin Christoph Hellwig (2): xfs: use ENOTBLK for direct I/O to buffered I/O fallback iomap: fall back to buffered writes for invalidation failures Dave Chinner (1): iomap: Only invalidate page cache pages on direct IO writes fs/ext4/file.c | 2 ++ fs/gfs2/file.c | 3 ++- fs/iomap/apply.c | 13 +++++++++---- fs/iomap/direct-io.c | 37 +++++++++++++++++++++---------------- fs/iomap/trace.h | 1 + fs/xfs/xfs_file.c | 8 ++++---- fs/zonefs/super.c | 7 +++++-- 7 files changed, 44 insertions(+), 27 deletions(-)