Re: [PATCH] lib/iov_iter: Fix pipe handling in _copy_to_iter_mcsafe

[Ross Zwisler <ross.zwisler@linux.intel.com>]

On Sun, Jul 01, 2018 at 08:52:20AM -0700, Dan Williams wrote:
> By mistake the ITER_PIPE early-exit / warning from copy_from_iter() was
> cargo-culted in _copy_to_iter_mcsafe() rather than a machine-check-safe
> version of copy_to_iter_pipe().
> 
> Implement copy_pipe_to_iter_mcsafe() being careful to return the
> indication of short copies due to a CPU exception.
> 
> Without this regression-fix all splice reads to dax-mode files fail.
> 
> Fixes: 8780356ef630 ("x86/asm/memcpy_mcsafe: Define copy_to_iter_mcsafe()")
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Tony Luck <tony.luck@intel.com>
> Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> Hi Ingo,
> 
> I'm submitting this fix back through the tip tree since the regression
> originated through tip/x86/dax.
> 
>  lib/iov_iter.c |   37 +++++++++++++++++++++++++++++++++----
>  1 file changed, 33 insertions(+), 4 deletions(-)

Hey Dan,

I retested the current linux/master with this patch applied, and XFS + DAX +
generic/323 still dies for me:

  run fstests generic/323 at 2018-07-02 10:51:35
  BUG: unable to handle kernel paging request at 00007f16dc001000 
  PGD 80000000bb71a067 P4D 80000000bb71a067 PUD bb71b067 PMD bb6e8067 PTE 0
  Oops: 0002 [#1] PREEMPT SMP PTI
  CPU: 1 PID: 1598 Comm: aio-last-ref-he Not tainted
  4.18.0-rc3-00001-g5174f2f2b6e5 #2
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
  rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014
  RIP: 0010:__memcpy+0x12/0x20
  Code: c3 e8 42 fb ff ff 48 8b 43 60 48 2b 43 50 88 43 4e 5b 5d c3 90 90 90
  90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3
  a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4
  RSP: 0018:ffffc90002783a60 EFLAGS: 00010246
  RAX: 00007f16dc001000 RBX: ffff880151229000 RCX: 0000000000002000
  RDX: 0000000000000000 RSI: ffff880151219000 RDI: 00007f16dc001000
  RBP: ffffc90002783a68 R08: 0000004227a4083c R09: ffff880151219000
  R10: ffffc90002783d40 R11: 0000000000000000 R12: 0000000000000000
  R13: 0000000000010000 R14: ffffc90002783d18 R15: 0000000000010000
  FS:  00007f16f1ec5700(0000) GS:ffff880114600000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f16dc001000 CR3: 0000000035508000 CR4: 00000000000006e0
  Call Trace:
   ? copyout_mcsafe+0x3e/0x60
   _copy_to_iter_mcsafe+0x9e/0x4c0
   ? __lock_is_held+0x65/0xb0
   pmem_copy_to_iter+0x17/0x20 [nd_pmem]
   dax_copy_to_iter+0x49/0x70
   dax_iomap_actor+0x1f8/0x280
   ? dax_iomap_rw+0x100/0x100
   iomap_apply+0xb5/0x130
   ? dax_iomap_rw+0x100/0x100
   dax_iomap_rw+0x95/0x100
   ? dax_iomap_rw+0x100/0x100
   xfs_file_dax_read+0x83/0x1f0
   xfs_file_read_iter+0xac/0xc0
   aio_read+0x11f/0x1a0
   ? __might_fault+0x3e/0x90
   io_submit_one+0x39d/0x5f0
   ? io_submit_one+0x39d/0x5f0
   __x64_sys_io_submit+0xa1/0x280
   do_syscall_64+0x65/0x220
   ? do_syscall_64+0x65/0x220
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

This failure looks identical to what I was hitting with the original bug
report.

- Ross