Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp220083imm; Mon, 2 Jul 2018 10:19:09 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIg7evo4gRjYS9UKsOxJP+QF+YItKXflcXAqqNc1XSU01S9aplN7IpEhRbkZyIP39KSzfET X-Received: by 2002:a63:6188:: with SMTP id v130-v6mr22477692pgb.100.1530551949377; Mon, 02 Jul 2018 10:19:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530551949; cv=none; d=google.com; s=arc-20160816; b=fNa7DbjJ1dUvw5w3A0tPJo4qaQ7lalJhSwhGicIjZmzcZ/g4k/tg7V7iQePsxPaJvp dwvlHhJ65sug97RKfXcTvd+iGwylKm3psXExbuG3+3m8jMSicQaq4YrIkl89M1Hlu4Nn gsCXX4Sh8lhmPS8z4XfaJcpEBZM14T0gL2SkX30wdf2Kh4J7TeQKJVlRDSTFFwS81OUO Qozb5/7xESbWFAcSFQ4mvQ3SVkbragxzUeNErCGfeCu3CKjmZJFyapEFk0gQtowCzraM Etj5Klm512S5i0EL8A+332DuLivRU8Fb70D6XKLdkFi7YKsVFC8C0oZ1P3f31CKgw74F 1sGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=WwnQkHzCAvl7rlcOJTWruADebt2jmBhFrhM5cL1PC2A=; b=Dt1iQ1H3Cb2BEdkQejQv7FxFeAb72Reg0TGUTY4qzc0YNkNztYQQ9R1QeGWycPS4bN Tw+Qe3Nm9kM1YePq83wbtthLhjAfCZ31GRohcHJu2VMoWGqy/Ufy7O5mif7IUjeW8LQV jUrqVWgYcmsNFMc3FK4CRltlg8d+Duu8mipHuhl2putbwhjDsnxlxBasD0HnBDSkFIDh zSLqVIWCRfVmjgJGulfvbtupzdJeUSB0BHX5zGlkn25ehNA2wDOlWMIKc/pzUBdXSn/y f8yucBrMpe0sfWl37zTA0V2FGdxYvGdcli2TlQJak0+81KGKzLqTXD3KgLsrkifKj/m1 3WEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=JdbPfpp8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g2-v6si15143763pgo.367.2018.07.02.10.18.54; Mon, 02 Jul 2018 10:19:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=JdbPfpp8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752813AbeGBRR3 (ORCPT + 99 others); Mon, 2 Jul 2018 13:17:29 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:42452 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752215AbeGBRR2 (ORCPT ); Mon, 2 Jul 2018 13:17:28 -0400 Received: by mail-oi0-f68.google.com with SMTP id n84-v6so17776896oib.9 for ; Mon, 02 Jul 2018 10:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=WwnQkHzCAvl7rlcOJTWruADebt2jmBhFrhM5cL1PC2A=; b=JdbPfpp8iooV+rlHDvAGFfyM7Qo1EGoTUDAFq4ypifHksCMWsd1nslThjAGVEfEs69 3NmfT0ejU91pZy3N/mDNBAiCv2vwkvvvelLcbhFLymICRJN1xSEUzFwPPllyOaxNk5N7 +RGwKhY2v4y2+ePMeTKsXj14lCogb1p6cQ1WeiAjnC+3AU9IfZZRC22jG1VieOw3Ofx+ K/jMpaTP6Zw4OdBYwpfO1HP/PBswJsbMxQUWY8icHcmg+LpDcQTFWsndaUhHRfgfiTU0 SDgjOgffrxBRKl0ftsbbyG6DiaIBNgRUdvtaAtn+na0kaRGNjnTtBvsepGZTPDX/aph7 heVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=WwnQkHzCAvl7rlcOJTWruADebt2jmBhFrhM5cL1PC2A=; b=Imk/dAmWDaZn9D5A6MRxKDLPQIrZTYlrO9borI67wym+3BFPOEkEdKoDalVPer5SSr 4L30SiDxMqJJzOGFtILeJyyw/Iwx1suB6/7XAuUjQOO42xtlnqAcHkCubaFTmNTjoIs1 I0J2Mi/WwkwsYQAjEOesEV29kVdCRdGcV+aQVlOG+K4kkhXi2MosqysVPLfOT/YQQlkg RFrK7dxtQ70JyWwLJQ82fhfXbX+sWkBRK/416IrqX0wpEQ+0Z+gVlpaXjcOOSPSY0lEz bl9TFJUqsjabmd4g7gi5j08sPp2csWrlDqxIjvMNTDxt6h9bulcjC6lwNocdQ2omrpGE gQCg== X-Gm-Message-State: APt69E3r6i3bxNQtNLTWWMm6f3hkJLw8dGq9E57fsxtlPRj/dsbv5Saq kZS5UXFp8nqva/qFBjulgPbO2qI2qtqVviGLqzwWQQ== X-Received: by 2002:aca:5f56:: with SMTP id t83-v6mr14808556oib.115.1530551847510; Mon, 02 Jul 2018 10:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:3495:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 10:17:27 -0700 (PDT) In-Reply-To: <20180702165803.GB19488@linux.intel.com> References: <153046008813.2019.6356018879675062644.stgit@dwillia2-desk3.amr.corp.intel.com> <20180702165803.GB19488@linux.intel.com> From: Dan Williams Date: Mon, 2 Jul 2018 10:17:27 -0700 Message-ID: Subject: Re: [PATCH] lib/iov_iter: Fix pipe handling in _copy_to_iter_mcsafe To: Ross Zwisler , Dan Williams , Ingo Molnar , Al Viro , Andrew Morton , Andy Lutomirski , Borislav Petkov , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Tony Luck , Linux Kernel Mailing List , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 2, 2018 at 9:58 AM, Ross Zwisler wrote: > 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 >> Cc: Andrew Morton >> Cc: Andy Lutomirski >> Cc: Borislav Petkov >> Cc: Linus Torvalds >> Cc: Peter Zijlstra >> Cc: Thomas Gleixner >> Cc: Tony Luck >> Reported-by: Ross Zwisler >> Signed-off-by: Dan Williams >> --- >> 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 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. I see it now, my run was skipping generic/323.