kernel-packages team mailing list archive

[Avi Kivity <avi@xxxxxxxxxxxx>]

Public bug reported:

An appending DIO write will corrupt files on XFS.

The following patch needs to be backported:

commit b9d59846f73713d77f0f3fb784c7f84249fc2b93
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Thu Apr 16 22:03:07 2015 +1000
 
    xfs: DIO write completion size updates race
   
    xfs_end_io_direct_write() can race with other IO completions when
    updating the in-core inode size. The IO completion processing is not
    serialised for direct IO - they are done either under the
    IOLOCK_SHARED for non-AIO DIO, and without any IOLOCK held at all
    during AIO DIO completion. Hence the non-atomic test-and-set update
    of the in-core inode size is racy and can result in the in-core
    inode size going backwards if the race if hit just right.
   
    If the inode size goes backwards, this can trigger the EOF zeroing
    code to run incorrectly on the next IO, which then will zero data
    that has successfully been written to disk by a previous DIO.
   
    To fix this bug, we need to serialise the test/set updates of the
    in-core inode size. This first patch introduces locking around the
    relevant updates and checks in the DIO path. Because we now have an
    ioend in xfs_end_io_direct_write(), we know exactly then we are
    doing an IO that requires an in-core EOF update, and we know that
    they are not running in interrupt context. As such, we do not need to
    use irqsave() spinlock variants to protect against interrupts while
    the lock is held.
   
    Hence we can use an existing spinlock in the inode to do this
    serialisation and so not need to grow the struct xfs_inode just to
    work around this problem.
   
    This patch does not address the test/set EOF update in
    generic_file_write_direct() for various reasons - that will be done
    as a followup with separate explanation.
   
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
    Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.19.0-25-generic 3.19.0-25.26~14.04.1 [modified: boot/vmlinuz-3.19.0-25-generic]
ProcVersionSignature: Ubuntu 3.19.0-25.26~14.04.1-generic 3.19.8-ckt2
Uname: Linux 3.19.0-25-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Sep 29 19:29:28 2015
InstallationDate: Installed on 2015-09-29 (0 days ago)
InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
SourcePackage: linux-lts-vivid
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: linux-lts-vivid (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-vivid in Ubuntu.
https://bugs.launchpad.net/bugs/1500954

Title:
  xfs DIO data corruption

Status in linux-lts-vivid package in Ubuntu:
  New

Bug description:
  An appending DIO write will corrupt files on XFS.

  The following patch needs to be backported:

  commit b9d59846f73713d77f0f3fb784c7f84249fc2b93
  Author: Dave Chinner <dchinner@xxxxxxxxxx>
  Date:   Thu Apr 16 22:03:07 2015 +1000
   
      xfs: DIO write completion size updates race
     
      xfs_end_io_direct_write() can race with other IO completions when
      updating the in-core inode size. The IO completion processing is not
      serialised for direct IO - they are done either under the
      IOLOCK_SHARED for non-AIO DIO, and without any IOLOCK held at all
      during AIO DIO completion. Hence the non-atomic test-and-set update
      of the in-core inode size is racy and can result in the in-core
      inode size going backwards if the race if hit just right.
     
      If the inode size goes backwards, this can trigger the EOF zeroing
      code to run incorrectly on the next IO, which then will zero data
      that has successfully been written to disk by a previous DIO.
     
      To fix this bug, we need to serialise the test/set updates of the
      in-core inode size. This first patch introduces locking around the
      relevant updates and checks in the DIO path. Because we now have an
      ioend in xfs_end_io_direct_write(), we know exactly then we are
      doing an IO that requires an in-core EOF update, and we know that
      they are not running in interrupt context. As such, we do not need to
      use irqsave() spinlock variants to protect against interrupts while
      the lock is held.
     
      Hence we can use an existing spinlock in the inode to do this
      serialisation and so not need to grow the struct xfs_inode just to
      work around this problem.
     
      This patch does not address the test/set EOF update in
      generic_file_write_direct() for various reasons - that will be done
      as a followup with separate explanation.
     
      Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
      Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
      Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx>

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.19.0-25-generic 3.19.0-25.26~14.04.1 [modified: boot/vmlinuz-3.19.0-25-generic]
  ProcVersionSignature: Ubuntu 3.19.0-25.26~14.04.1-generic 3.19.8-ckt2
  Uname: Linux 3.19.0-25-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.11
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Sep 29 19:29:28 2015
  InstallationDate: Installed on 2015-09-29 (0 days ago)
  InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
  SourcePackage: linux-lts-vivid
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-vivid/+bug/1500954/+subscriptions