From: John Hubbard <jhubbard@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Christoph Hellwig" <hch@infradead.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"Dave Chinner" <david@fromorbit.com>,
"Ira Weiny" <ira.weiny@intel.com>, "Jan Kara" <jack@suse.cz>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Jonathan Corbet" <corbet@lwn.net>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
"Michal Hocko" <mhocko@suse.com>,
"Mike Kravetz" <mike.kravetz@oracle.com>,
"Shuah Khan" <shuah@kernel.org>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Matthew Wilcox" <willy@infradead.org>,
linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-mm@kvack.org,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [regression] Re: [PATCH v6 06/12] mm/gup: track FOLL_PIN pages
Date: Fri, 24 Apr 2020 12:20:03 -0700 [thread overview]
Message-ID: <5b901542-d949-8d7e-89c7-f8d5ee20f6e9@nvidia.com> (raw)
In-Reply-To: <20200424121846.5ee2685f@w520.home>
On 2020-04-24 11:18, Alex Williamson wrote:
...
> Hi John,
>
> I'm seeing a regression bisected back to this commit (3faa52c03f44
> mm/gup: track FOLL_PIN pages). I've attached some vfio-pci test code
> that reproduces this by mmap'ing a page of MMIO space of a device and
> then tries to map that through the IOMMU, so this should be attempting
> a gup/pin of a PFNMAP page. Previously this failed gracefully (-EFAULT),
> but now results in:
Hi Alex,
Thanks for this report, and especially for source code to test it,
seeing as how I can't immediately spot the problem just from the crash
data so far. I'll get set up and attempt a repro.
Actually this looks like it should be relatively easier than the usual
sort of "oops, we leaked a pin_user_pages() or unpin_user_pages() call,
good luck finding which one" report that I fear the most. :) This one
looks more like a crash that happens directly, when calling into the
pin_user_pages_remote() code. Which should be a lot easier to solve...
btw, if you are set up for it, it would be nice to know what source file
and line number corresponds to the RIP (get_pfnblock_flags_mask+0x22)
below. But if not, no problem, because I've likely got to do the repro
in any case.
thanks,
--
John Hubbard
NVIDIA
>
> BUG: unable to handle page fault for address: ffffae5cbfe5e938
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: 0000 [#1] SMP NOPTI
> CPU: 18 PID: 3365 Comm: vfio-pci-dma-ma Tainted: G OE 5.6.0+ #6
> Hardware name: AMD Corporation Diesel/Diesel, BIOS TDL100CB 03/17/2020
> RIP: 0010:get_pfnblock_flags_mask+0x22/0x70
> Code: c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 48 8b 05 bc e1 d9 01 48 89 f7 49 89 c8 48 c1 ef 0f 48 85 c0 74 48 48 89 f1 48 c1 e9 17 <48> 8b 04 c8 48 85 c0 74 0b 40 0f b6 ff 48 c1 e7 04 48 01 f8 48 c1
> RSP: 0018:ffffb55289b3fcc8 EFLAGS: 00010216
> RAX: ffff9e5cbff50000 RBX: 0000000000000001 RCX: 000001fffffe1d27
> RDX: 0000000000000002 RSI: ffffff0e93acd633 RDI: 0001fffffe1d2759
> RBP: ffffb55289b3fd88 R08: 0000000000000007 R09: ffff9e48a52476a8
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
> R13: 0000000000000000 R14: 0000000000000001 R15: ffff9e48ab358cc0
> FS: 00007f4ef7269740(0000) GS:ffff9e48afa80000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffae5cbfe5e938 CR3: 0000000c61eda000 CR4: 00000000003406e0
> Call Trace:
> __gup_longterm_locked+0x274/0x620
> vaddr_get_pfn+0x74/0x110 [vfio_iommu_type1]
> vfio_pin_pages_remote+0x6e/0x370 [vfio_iommu_type1]
> vfio_iommu_type1_ioctl+0x8e5/0xaac [vfio_iommu_type1]
> ksys_ioctl+0x86/0xc0
> __x64_sys_ioctl+0x16/0x20
> do_syscall_64+0x5b/0x1f0
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f4ef6d7d307
> Code: 44 00 00 48 8b 05 69 1b 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 1b 2d 00 f7 d8 64 89 01 48
> RSP: 002b:00007fff76ada738 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4ef6d7d307
> RDX: 00007fff76ada760 RSI: 0000000000003b71 RDI: 0000000000000003
> RBP: 00007fff76ada930 R08: 0000000000000005 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000213 R12: 0000000000400950
> R13: 00007fff76adaa10 R14: 0000000000000000 R15: 0000000000000000
> Modules linked in: vfio_pci(OE) vfio_virqfd(OE) vfio_iommu_type1(OE) vfio(OE) amd64_edac_mod edac_mce_amd kvm_amd kvm rfkill sunrpc ipmi_ssif vfat irqbypass fat ipmi_si crct10dif_pclmul crc32_pclmul sp5100_tco ghash_clmulni_intel ipmi_devintf pcspkr joydev ccp i2c_piix4 k10temp ipmi_msghandler pinctrl_amd acpi_cpufreq ip_tables nouveau ast video mxm_wmi drm_vram_helper wmi drm_ttm_helper i2c_algo_bit drm_kms_helper cec ttm drm i40e e1000e crc32c_intel
> CR2: ffffae5cbfe5e938
> ---[ end trace a384ab7cc8e37d46 ]---
> RIP: 0010:get_pfnblock_flags_mask+0x22/0x70
> Code: c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 48 8b 05 bc e1 d9 01 48 89 f7 49 89 c8 48 c1 ef 0f 48 85 c0 74 48 48 89 f1 48 c1 e9 17 <48> 8b 04 c8 48 85 c0 74 0b 40 0f b6 ff 48 c1 e7 04 48 01 f8 48 c1
> RSP: 0018:ffffb55289b3fcc8 EFLAGS: 00010216
> RAX: ffff9e5cbff50000 RBX: 0000000000000001 RCX: 000001fffffe1d27
> RDX: 0000000000000002 RSI: ffffff0e93acd633 RDI: 0001fffffe1d2759
> RBP: ffffb55289b3fd88 R08: 0000000000000007 R09: ffff9e48a52476a8
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
> R13: 0000000000000000 R14: 0000000000000001 R15: ffff9e48ab358cc0
> FS: 00007f4ef7269740(0000) GS:ffff9e48afa80000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffae5cbfe5e938 CR3: 0000000c61eda000 CR4: 00000000003406e0
>
> Thanks,
> Alex
>
next prev parent reply other threads:[~2020-04-24 19:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 0:15 [PATCH v6 00/12] mm/gup: track FOLL_PIN pages John Hubbard
2020-02-11 0:15 ` [PATCH v6 01/12] mm/gup: split get_user_pages_remote() into two routines John Hubbard
2020-02-11 0:15 ` [PATCH v6 02/12] mm/gup: pass a flags arg to __gup_device_* functions John Hubbard
2020-02-11 0:15 ` [PATCH v6 03/12] mm: introduce page_ref_sub_return() John Hubbard
2020-02-11 0:15 ` [PATCH v6 04/12] mm/gup: pass gup flags to two more routines John Hubbard
2020-02-11 0:15 ` [PATCH v6 05/12] mm/gup: require FOLL_GET for get_user_pages_fast() John Hubbard
2020-02-11 0:15 ` [PATCH v6 06/12] mm/gup: track FOLL_PIN pages John Hubbard
2020-04-24 18:18 ` [regression] " Alex Williamson
2020-04-24 19:20 ` John Hubbard [this message]
2020-04-24 20:15 ` Alex Williamson
2020-04-24 22:58 ` John Hubbard
2020-04-28 16:54 ` [regression?] " Alex Williamson
2020-04-28 17:49 ` Jason Gunthorpe
2020-04-28 19:07 ` Alex Williamson
2020-04-28 19:22 ` Jason Gunthorpe
2020-04-28 20:12 ` Alex Williamson
2020-04-29 0:29 ` Jason Gunthorpe
2020-04-29 19:56 ` Alex Williamson
2020-04-29 23:03 ` Jason Gunthorpe
2020-02-11 0:15 ` [PATCH v6 07/12] mm/gup: page->hpage_pinned_refcount: exact pin counts for huge pages John Hubbard
2020-02-11 0:15 ` [PATCH v6 08/12] mm/gup: /proc/vmstat: pin_user_pages (FOLL_PIN) reporting John Hubbard
2020-02-12 9:17 ` Jan Kara
2020-02-11 0:15 ` [PATCH v6 09/12] mm/gup_benchmark: support pin_user_pages() and related calls John Hubbard
2020-02-11 0:15 ` [PATCH v6 10/12] selftests/vm: run_vmtests: invoke gup_benchmark with basic FOLL_PIN coverage John Hubbard
2020-02-11 0:15 ` [PATCH v6 11/12] mm: Improve dump_page() for compound pages John Hubbard
2020-02-11 0:15 ` [PATCH v6 12/12] mm: dump_page(): additional diagnostics for huge pinned pages John Hubbard
2020-02-11 13:21 ` Kirill A. Shutemov
2020-02-12 2:10 ` John Hubbard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b901542-d949-8d7e-89c7-f8d5ee20f6e9@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=ira.weiny@intel.com \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=jglisse@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=shuah@kernel.org \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).