From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36C7AC433F5 for ; Mon, 28 Feb 2022 15:39:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 999658D0002; Mon, 28 Feb 2022 10:39:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 946E58D0001; Mon, 28 Feb 2022 10:39:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80E538D0002; Mon, 28 Feb 2022 10:39:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 6EFB28D0001 for ; Mon, 28 Feb 2022 10:39:10 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 1E68F6049D for ; Mon, 28 Feb 2022 15:39:10 +0000 (UTC) X-FDA: 79192597260.14.D576DA7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf05.hostedemail.com (Postfix) with ESMTP id 7353910001A for ; Mon, 28 Feb 2022 15:39:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646062748; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=mSrk1HuWl/uC94PNpBB4C5YINZehKuU5+5c7mB5Plio=; b=Tp012lupfWldsAYKqrgE72mi/VvZ/5rLEXbXYqBdfmL/InCAtljWEYJpaDx9NptqfGmBIH mwuAtulFvOUGs/FEcY+DMQ2oUyti6gRsZAO07hVJT/DQbx9LCLnV9yVRGUUltXKAg3vPaS GI8gDUHIsGfIDpHSxScw1+uDEHSkpms= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-487-z2lA2SJQMeeD7-qUSyQ1tA-1; Mon, 28 Feb 2022 10:39:07 -0500 X-MC-Unique: z2lA2SJQMeeD7-qUSyQ1tA-1 Received: by mail-wr1-f69.google.com with SMTP id m3-20020adfa3c3000000b001ea95eb48abso2248038wrb.3 for ; Mon, 28 Feb 2022 07:39:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:to:cc:subject:organization :content-transfer-encoding; bh=mSrk1HuWl/uC94PNpBB4C5YINZehKuU5+5c7mB5Plio=; b=B7r5totYjaNfZhQldPv5tYzCrOwPLbUmatU9uu1byajSw8ZybCXqFuaIU9cQ7/YvdX X35907WmvACCEJ98//IvWdkHgBkv6udxIvZ00v+Fhsgib9TlYrTp2LhOxxqvaONrSg1W hfvzwhVWSvCGOLdzx3xsOPwE3ZosMKPPgIm8rYM/3DujsEYtMGDmqLLlRTVoCTAaPdXR uKMnV+Jt1mWgpkqX9iKxFF3w50JadkbkTdYx5QAp101gJRWA/kuRO+iP9CYUOf+FPwYo kI9/rx5VI4FVuX+qYmXQm62ZXgpFGre1lOsEYq/NRZw9J1ymNfnOfyYGqVj6WVCSTbWf yrrw== X-Gm-Message-State: AOAM532Qub3s1fUXD2WGnpWPAPomHXuxXDyb101aVN+E6/QzIW8Ykfvp IRmBeqjVPKpA7OjftL+I5cik/SuOX/isvtPIaJZ1Jxg6ZGfHoncnbnBK67V/Pmg7/Vc9nrfsn4V 32mroL3QuUG52EmbaR1WNc0wcTAB8Wcnv2zWCS8fQMC6Aq/LNABeg/mfhoP4= X-Received: by 2002:a05:600c:1d94:b0:381:53c5:355b with SMTP id p20-20020a05600c1d9400b0038153c5355bmr6170714wms.50.1646062746131; Mon, 28 Feb 2022 07:39:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJxHn6223sOS+pxYMB+4AOGtc2+bjx3v5Ur9RLhE848pfta083SI1Mj1QpVal8ogAdf7UruPIw== X-Received: by 2002:a05:600c:1d94:b0:381:53c5:355b with SMTP id p20-20020a05600c1d9400b0038153c5355bmr6170680wms.50.1646062745749; Mon, 28 Feb 2022 07:39:05 -0800 (PST) Received: from ?IPV6:2003:cb:c702:9700:f1d:e242:33b4:67f? (p200300cbc70297000f1de24233b4067f.dip0.t-ipconnect.de. [2003:cb:c702:9700:f1d:e242:33b4:67f]) by smtp.gmail.com with ESMTPSA id f18-20020a5d6652000000b001e669ebd528sm10751450wrw.91.2022.02.28.07.39.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Feb 2022 07:39:05 -0800 (PST) Message-ID: <811c5c8e-b3a2-85d2-049c-717f17c3a03a@redhat.com> Date: Mon, 28 Feb 2022 16:39:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 From: David Hildenbrand To: "linux-mm@kvack.org" Cc: Mike Kravetz , anshuman.khandual@arm.com Subject: VM_BUG_ON(!tlb->end) on munmap() with CONT hugetlb pages Organization: Red Hat X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7353910001A X-Stat-Signature: 9braj4dx7djsr7p3okq54p56ksg4kqsu Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Tp012lup; spf=none (imf05.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-HE-Tag: 1646062749-445292 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: Hi, playing with anonymous CONT hugetlb pages on aarch64, I stumbled over the following VM_BUG_ON: [ 124.770288] ------------[ cut here ]------------ [ 124.774899] kernel BUG at mm/mmu_gather.c:70! [ 124.779244] Internal error: Oops - BUG: 0 [#1] SMP [ 124.784022] Modules linked in: mlx4_ib ib_uverbs ib_core mlx4_en rfkill vfat fat acpi_ipmi joydev ipmi_ssif igb mlx4_core ipmi_devintf ipmi_msghandler cppc_cpufreq fuse zram ip_tables xfs uas usb_storage dwc3 ulpi ast udc_core i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_ce drm ghash_ce sbsa_gwdt i2c_xgene_slimpro xgene_hwmon ahci_platform gpio_dwapb xhci_plat_hcd [ 124.823045] CPU: 16 PID: 1160 Comm: test Not tainted 5.16.11-200.fc35.aarch64 #1 [ 124.830428] Hardware name: Lenovo HR350A 7X35CTO1WW /HR350A , BIOS hve104r-1.15 02/26/2021 [ 124.840240] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 124.847189] pc : __tlb_remove_page_size+0x88/0xe4 [ 124.851885] lr : __unmap_hugepage_range+0x260/0x504 [ 124.856751] sp : ffff80000f6f3ae0 [ 124.860053] x29: ffff80000f6f3ae0 x28: ffff00080b639d24 x27: ffff000802504080 [ 124.867176] x26: fffffc00210f8000 x25: 0000000000000000 x24: ffff80000a9e8750 [ 124.874299] x23: 0000ffff8da20000 x22: ffff000804f0c190 x21: 0000000000010000 [ 124.881423] x20: ffff80000f6f3cb0 x19: ffff80000f6f3cb0 x18: 0000000000000000 [ 124.888545] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 124.895668] x14: 0000000000000000 x13: 0008000000000000 x12: 0008000000000080 [ 124.902791] x11: 0008000000000000 x10: 00f80008c3e00f43 x9 : ffff800008404e60 [ 124.909914] x8 : 0846000000000000 x7 : 0000000000000000 x6 : ffff80000a8a4000 [ 124.917038] x5 : 0000000000000040 x4 : 0000000000000000 x3 : 0000000000001000 [ 124.924161] x2 : 0000000000010000 x1 : fffffc00210f8000 x0 : 0000000000000000 [ 124.931284] Call trace: [ 124.933718] __tlb_remove_page_size+0x88/0xe4 [ 124.938062] __unmap_hugepage_range+0x260/0x504 [ 124.942580] __unmap_hugepage_range_final+0x24/0x40 [ 124.947445] unmap_single_vma+0x100/0x11c [ 124.951443] unmap_vmas+0x7c/0xf4 [ 124.954746] unmap_region+0xa4/0xf0 [ 124.958222] __do_munmap+0x1b8/0x50c [ 124.961785] __vm_munmap+0x74/0x120 [ 124.965261] __arm64_sys_munmap+0x40/0x54 [ 124.969257] invoke_syscall+0x50/0x120 [ 124.972995] el0_svc_common.constprop.0+0x4c/0x100 [ 124.977774] do_el0_svc+0x34/0xa0 [ 124.981077] el0_svc+0x30/0xd0 [ 124.984120] el0t_64_sync_handler+0xa4/0x130 [ 124.988377] el0t_64_sync+0x1a4/0x1a8 [ 124.992028] Code: b4000140 f9001660 29410402 17fffff4 (d4210000) [ 124.998109] ---[ end trace a74a76b89c9f2d88 ]--- [ 125.002900] ------------[ cut here ]------------ I'm running with 64k hugetlb on 4k aarch64. Reproducer: #define _GNU_SOURCE #include #include #include #include void main(void) { const size_t size = 64*1024; unsigned long cur; char *area; int fd; fd = memfd_create("test", MFD_HUGETLB | MFD_HUGE_64KB); ftruncate(fd, size); area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0); memset(area, 0, size); munmap(area, size); } I assume __unmap_hugepage_range() does a a) tlb_remove_huge_tlb_entry() -> for sz != PMD_SIZE and sz != PUD_SIZE, this calls __tlb_remove_tlb_entry() -> __tlb_remove_tlb_entry() is a NOP on aarch64. __tlb_adjust_range() isn't called. b) tlb_remove_page_size() -> __tlb_remove_page_size() runs into VM_BUG_ON(!tlb->end); Not sure if this is just "ok" and we don't have to adjust the range or if there is some tlb range adjustment missing. -- Thanks, David / dhildenb