mbox series

[GIT,PULL] iomap: new code for 5.9-rc1

Message ID 20200805153214.GA6090@magnolia (mailing list archive)
State New, archived
Headers show
Series [GIT,PULL] iomap: new code for 5.9-rc1 | expand

Pull-request

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

Message

Darrick J. Wong Aug. 5, 2020, 3:32 p.m. UTC
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(-)

Comments

Andreas Gruenbacher Aug. 5, 2020, 3:54 p.m. UTC | #1
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
Darrick J. Wong Aug. 5, 2020, 4:23 p.m. UTC | #2
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.

Oh well, I guess I have to rebase the whole branch now.

Linus: please ignore this pull request.

--D

> 
> Thanks,
> Andreas
>
Darrick J. Wong Aug. 5, 2020, 4:31 p.m. UTC | #3
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
> > 
>