From patchwork Mon Jun 25 14:59:23 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alexander Potapenko X-Patchwork-Id: 10486503 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 181DB601D5 for ; Mon, 25 Jun 2018 14:59:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1D2E728429 for ; Mon, 25 Jun 2018 14:59:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 11BC92842E; Mon, 25 Jun 2018 14:59:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, USER_IN_DEF_DKIM_WL autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D366D28429 for ; Mon, 25 Jun 2018 14:59:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D39EA6B026A; Mon, 25 Jun 2018 10:59:36 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id D0F586B026C; Mon, 25 Jun 2018 10:59:36 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C00656B026D; Mon, 25 Jun 2018 10:59:36 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) by kanga.kvack.org (Postfix) with ESMTP id 878A76B026A for ; Mon, 25 Jun 2018 10:59:36 -0400 (EDT) Received: by mail-vk0-f69.google.com with SMTP id a7-v6so6274623vka.22 for ; Mon, 25 Jun 2018 07:59:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:mime-version:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=hl+Jfnm6OkuOENt+WoOPQhhVGwc2LHyfplkGhZG8g+U=; b=ORqBXrwxHc7JEyy/bpYOYpwZAZPQAb49aXl+Knd5hJkfUUJyF/J3Dpzendn9wGMzKF 78aAGo9/sjEATbh1z7zLzyRbAXbO9MTUYfnY1QWT/A3bF4V62B5HPX5nzU3F2xrwxyqM naPXknoW+YMQzyLNJBMRuMNK5VJtEkAq+zr1OwVJiX4+P6dlSy3BecBVZX68ftKTe08F QQ+KBu0gBYYUWS2ar8WUntBVKtVc1etm46fDoPQ8zts9scg6u7KhN7Ng7MAi2ifzzJfh nyNv4BeKCcIyae2LIw0sYhkd5pRh9kY3sgZ/EBHxI61qrrmZ1fbURl012UhnDZ2TUXQv cvvA== X-Gm-Message-State: APt69E3fdOEtk/wJMR+wpj9GBGNKPYWfIeIixo8JJ72NVkC5pdfF0lRl R+fnvj82E1kPUg71cYSSQvdXrs7PznEuuj7bra5s4VJTO7eBqyZ/e8FaZnZBAq+Viqw8aSPtESO IoEL6t2llbW2QbBM0yUHUNtdvX+lArfKp+gD3F7nz4JvUC7E2yxlFiQOTXnZzPrMrHwB2+3wtQw 9r6Sn6D5+/IyYi1U8BvyFMyN58+JzJquA2tXNdAh4k4CxbhoYt6dXmLqBwJx+tpiPWe+6NR2NMS mufRYgzSIFUTo1Idp9Ws33FIjy9Bc+D7nj0nX35bVhIlpCx3x0bUpsER3hjnhq8byejjdLhEDIt vXAss0mhwzq1ibZXHZeSA9uZL7VYdJK0Ys2gafg0vL0sQuT9d2vxFVmu8RWEHCPJxaLh5mw4uOY E X-Received: by 2002:a1f:e483:: with SMTP id b125-v6mr7545925vkh.149.1529938776025; Mon, 25 Jun 2018 07:59:36 -0700 (PDT) X-Received: by 2002:a1f:e483:: with SMTP id b125-v6mr7545899vkh.149.1529938775313; Mon, 25 Jun 2018 07:59:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529938775; cv=none; d=google.com; s=arc-20160816; b=M1pBc1sGLXFhk/XHRGllOFXNph1H3VpM3Qhe3GL71hBtoLx04pF6lCLTtw3VJiWWXk npC9BmXkfoKC0VIgytopYfYEVlcUwdYBPbck/OgzF8qe2Bq9IS7elpq/ZyGxs8P47rPI eIWowEPp6OEN9KmvZTYcLLhPFud7fDCz2iwv1x9VLvwzQHDeq/IGTj94kvJ7iI9tidzF dKYwTj9s9mvqtZA467sVYEMqcCH7aq07Ih+ZHFuJCFm1JjOic1Hr4Jg3j1Z//tz6O73s s98jQZK3enw1Nu+a4G2KNQmVQYNFuwsGTVuPhHNLQRDhwpGjojWa6gA10FeoEj8J3gIj zMXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:dkim-signature:arc-authentication-results; bh=hl+Jfnm6OkuOENt+WoOPQhhVGwc2LHyfplkGhZG8g+U=; b=FFjH6sLq/BZ37I3A/sa6yhVn+ul4tlDogEwVFtTZRtbD8gPJMqoHqiNF8yIZtdAhSc A49LNHsC2Yt+59XDtWWhscSV8zcbQrWNirU5/zqvOKa5PL2mig5SM/kK6hKXrGIgLqxg /BUsptsp3xOPh62sBl3Ozq5MvdzPt7nniOYsLHtF67M6gG7S3HvcKAgsc8hFMVl6fgFg bYiPAqXB6HeU+0H6x1PFk8PGsUtL2g4gjICX97w1WbNncuA2H4cmLg6CM+PHet7YHsYw kiWnLf9xpFoSwR9jiwvWVZ1iZ1PVOr6XPMlYilCz9GLqEphp1H7JXQlrtpsDfcwodJ8f cSGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VlXDQHCX; spf=pass (google.com: domain of glider@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id x124-v6sor5829830vkf.59.2018.06.25.07.59.35 for (Google Transport Security); Mon, 25 Jun 2018 07:59:35 -0700 (PDT) Received-SPF: pass (google.com: domain of glider@google.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VlXDQHCX; spf=pass (google.com: domain of glider@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=hl+Jfnm6OkuOENt+WoOPQhhVGwc2LHyfplkGhZG8g+U=; b=VlXDQHCXGh+LYGo+4j4HrOFq0vxqu3WirNI3E581HuLeEvz44Q26AoP9t5hSENgJP5 vDkTTZbSTFy3alePttMHqCb4YchfIIkYijFnBpJPbXQWqOboGpKewu/z3Ax1E3/NoQwq y7vAWZZOAKjWYQWU8xsYNYmLl7rKB9YpedLvhE///Tgrq/2UGraD5m5PZDqgLapeXoaX 8CQgHvtTcFCGaPyHX0URoJ8yCyoxXhyPK1X6xFe+JmHXT38r+6LpMillqevdVHr80/Cz IJ/2AyIfAORWc4X2u+bEGPEu+9IQAP+uoFowTEvikjxIRs6T2AWd3OOzh7PYM7GP1bsA FfYw== X-Google-Smtp-Source: AAOMgpfMrSM1hIxyBcQ7l47cPDhI9nhMXg5C0uBuuaINRp48+34RIZMQoJjxsVrwmuhgp7lnNYvWF6tWZE11SWGs1vM= X-Received: by 2002:a1f:dc85:: with SMTP id t127-v6mr5989448vkg.120.1529938774681; Mon, 25 Jun 2018 07:59:34 -0700 (PDT) MIME-Version: 1.0 From: Alexander Potapenko Date: Mon, 25 Jun 2018 16:59:23 +0200 Message-ID: Subject: Calling vmalloc_to_page() on ioremap memory? To: Ard Biesheuvel , Mark Rutland , Andrew Morton Cc: Linux Memory Management List X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP Hi Ard, Mark, Andrew and others, AFAIU, commit 029c54b09599573015a5c18dbe59cbdf42742237 ("mm/vmalloc.c: huge-vmap: fail gracefully on unexpected huge vmap mappings") was supposed to make vmalloc_to_page() return NULL for pointers not returned by vmalloc(). But when I call vmalloc_to_page() for the pointer returned by acpi_os_ioremap() (see the patch below) I see that the resulting `struct page *` points to unmapped memory: } Thanks, Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg ============================ ACPI: Enabled 2 GPEs in block 00 to 0F phys: 00000000fed00000, vmalloc: ffffc9000019a000, page: ffff8800fed00000 [ffffea0003fb4000] BUG: unable to handle kernel paging request at ffffea0003fb4000 PGD 3f7d5067 P4D 3f7d5067 PUD 3f7d4067 PMD 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc2+ #1325 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/= 2014 RIP: 0010:acpi_os_map_iomem+0x1c5/0x210 ??:? Code: 00 88 ff ff 4d 89 f8 48 c1 f9 06 4c 89 f6 48 c7 c7 60 5f 01 82 48 c1 e1 0c 48 01 c1 e8 6d 42 70 ff 4d 85 ff 0f 84 14 ff ff ff <49> 8b 37 48 c7 c7 d2 61 01 82 e8 55 42 70 ff e9 00 ff ff ff 48 c7 RSP: 0000:ffff88003e253840 EFLAGS: 00010286 RAX: 000000000000005c RBX: ffff88003d857b80 RCX: ffffffff82245d38 RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffffffff8288e86c RBP: 00000000fed00000 R08: 00000000000000ae R09: 0000000000000007 R10: 0000000000000000 R11: ffffffff828908ad R12: 0000000000001000 R13: ffffc9000019a000 R14: 00000000fed00000 R15: ffffea0003fb4000 FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:000000000000000= 0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffea0003fb4000 CR3: 000000000220a000 CR4: 00000000000006f0 Call Trace: acpi_ex_system_memory_space_handler+0xca/0x19f ??:? ============================ For memory error detection purposes I'm trying to map the addresses from the vmalloc range to valid struct pages, or at least make sure there's no struct page for a given address. Looking up the vmap_area_root rbtree isn't an option, as this must be done from instrumented code, including interrupt handlers. I've been trying to employ vmalloc_to_page(), but looks like it doesn't work for ioremapped addresses. Is this at all possible? Patch showing the problem follows. I'm building using GCC 7.1.1 on a defconfig for x86_64. --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -279,14 +279,23 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size si= ze) static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long pg_sz) { unsigned long pfn; + void __iomem *ret; + struct page *page; pfn =3D pg_off >> PAGE_SHIFT; if (should_use_kmap(pfn)) { if (pg_sz > PAGE_SIZE) return NULL; return (void __iomem __force *)kmap(pfn_to_page(pfn)); - } else - return acpi_os_ioremap(pg_off, pg_sz); + } else { + ret =3D acpi_os_ioremap(pg_off, pg_sz); + BUG_ON(!is_vmalloc_addr(ret)); + page =3D vmalloc_to_page(ret); + pr_err("phys: %px, vmalloc: %px, page: %px [%px]\n", pg_off, ret, page_address(page), page); + if (page) + pr_err("flags: %d\n", page->flags); + return ret; + }