1. 11 Nov, 2019 1 commit
    • Jan Stancek's avatar
      iomap: fix return value of iomap_dio_bio_actor on 32bit systems · e9f930ac
      Jan Stancek authored
      Naresh reported LTP diotest4 failing for 32bit x86 and arm -next
      kernels on ext4. Same problem exists in 5.4-rc7 on xfs.
      
      The failure comes down to:
        openat(AT_FDCWD, "testdata-4.5918", O_RDWR|O_DIRECT) = 4
        mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f7b000
        read(4, 0xb7f7b000, 4096)              = 0 // expects -EFAULT
      
      Problem is conversion at iomap_dio_bio_actor() return. Ternary
      operator has a return type and an attempt is made to convert each
      of operands to the type of the other. In this case "ret" (int)
      is converted to type of "copied" (unsigned long). Both have size
      of 4 bytes:
          size_t copied = 0;
          int ret = -14;
          long long actor_ret = copied ? copied : ret;
      
          On x86_64: actor_ret == -14;
          On x86   : actor_ret == 4294967282
      
      Replace ternary operator with 2 return statements to avoid this
      unwanted conversion.
      
      Fixes: 4721a601 ("iomap: dio data corruption and spurious errors when pipes fill")
      Reported-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: default avatarJan Stancek <jstancek@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      e9f930ac
  2. 08 Nov, 2019 1 commit
  3. 07 Nov, 2019 1 commit
  4. 29 Oct, 2019 1 commit
  5. 21 Oct, 2019 22 commits
  6. 17 Oct, 2019 1 commit
    • Dave Chinner's avatar
      iomap: iomap that extends beyond EOF should be marked dirty · 7684e2c4
      Dave Chinner authored
      When doing a direct IO that spans the current EOF, and there are
      written blocks beyond EOF that extend beyond the current write, the
      only metadata update that needs to be done is a file size extension.
      
      However, we don't mark such iomaps as IOMAP_F_DIRTY to indicate that
      there is IO completion metadata updates required, and hence we may
      fail to correctly sync file size extensions made in IO completion
      when O_DSYNC writes are being used and the hardware supports FUA.
      
      Hence when setting IOMAP_F_DIRTY, we need to also take into account
      whether the iomap spans the current EOF. If it does, then we need to
      mark it dirty so that IO completion will call generic_write_sync()
      to flush the inode size update to stable storage correctly.
      
      Fixes: 3460cac1 ("iomap: Use FUA for pure data O_DSYNC DIO writes")
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      [darrick: removed the ext4 part; they'll handle it separately]
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      7684e2c4
  7. 15 Oct, 2019 2 commits
  8. 13 Oct, 2019 11 commits