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 35C77C43217 for ; Thu, 1 Dec 2022 17:48:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FDB56B0073; Thu, 1 Dec 2022 12:48:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AE2D6B0075; Thu, 1 Dec 2022 12:48:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 775996B0078; Thu, 1 Dec 2022 12:48:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 64E526B0073 for ; Thu, 1 Dec 2022 12:48:47 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 391551C69C5 for ; Thu, 1 Dec 2022 17:48:47 +0000 (UTC) X-FDA: 80194472694.10.D60576C Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by imf14.hostedemail.com (Postfix) with ESMTP id D878310000D for ; Thu, 1 Dec 2022 17:48:46 +0000 (UTC) Received: by mail-pg1-f181.google.com with SMTP id 62so2265208pgb.13 for ; Thu, 01 Dec 2022 09:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3SBTAayTX2wK8XVSyRdATXgh0KCZbeE/CV9oqM7zLpU=; b=g8W58cbnJkSilUHYjf2qNO9y5Qo7f+eRNCrW1RZOx/+UMNhj4AsMsfhEgvVaxR6to0 L+v3WJncRL9q075s0ga7r97nY9fWObtIfzj1PDw/0mb7DuL4kw+YfQymfqx7BtCr6bo5 vZFm4T3SGW29OJUkU1HXJXmUHZR9DKhRd1jURlQOGRZO9u2P1xYG62Myp3H72qUW9lk7 hviYe3z0As5mkGjCVvgDaTp8xz35LYDh/h9HoyKeR2NIDajKKsfUWIX8Bi28vgSerjdl uMglLZP+t7tgU0enCPlcO4PZj96YOiBN9BGquId8iHem7362T6LUmljPcHhAUgzmVRpB aBdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3SBTAayTX2wK8XVSyRdATXgh0KCZbeE/CV9oqM7zLpU=; b=1SFeR4YfrJ4DsHHRnvDJ7ZKLOeWvVV9MuGX6guuIJ+iK4PIhxSuQZ6RAzaXVevXBoZ 7oD0i0Pds35JeJC0UI8XHT9DCwpA63AgML23+LOKDQlCjiO9Xb7nd8wWxedq+gy5M8Dw RBCp94QkPAegVv/UNRcbJWefZ/DyOiXF001KsBIx/0aiUwOYOhwHZumH8ZNgra6cZNLL UhJeNvthqGSQUgpNAJkm3HBrpk/ljaE3kAixK2yFnWWfE+qB7SB8CUtVLoJ5ytu/BO5c 10XQody5mkyGCH0aCA2Eo4DOv+lo5SUr9H412p9TGYYiKOkpBQRm3VOKE7+FWTtmENJs +gLw== X-Gm-Message-State: ANoB5pnVg9B6EflaNGSGotiCYcm2hY1cbRe7L5ourpHqJIrHNbu1aXNX SybFNy258jHmPd60VdTSB/ascG7R6mKpAWOWcxs= X-Google-Smtp-Source: AA0mqf40Q2277TUiv2hV2/wLdzyfYg2DQRdxaYepbDeXltORqM2ZkFMq1ei3vY6O6L9ds6HVdAikHvNXWWpFQPPiGyk= X-Received: by 2002:a63:1f48:0:b0:439:db5:f817 with SMTP id q8-20020a631f48000000b004390db5f817mr42359406pgm.310.1669916925621; Thu, 01 Dec 2022 09:48:45 -0800 (PST) MIME-Version: 1.0 References: <0efeec33-8030-df1e-b055-2e0748fab4e0@redhat.com> In-Reply-To: <0efeec33-8030-df1e-b055-2e0748fab4e0@redhat.com> From: Yang Shi Date: Thu, 1 Dec 2022 09:48:33 -0800 Message-ID: Subject: Re: kernel BUG at include/linux/swapops.h:497! To: David Hildenbrand Cc: "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Hugh Dickins , Peter Xu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=g8W58cbn; spf=pass (imf14.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.181 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669916926; a=rsa-sha256; cv=none; b=A5AvR0ILRlLix/qajNyNPvfaPc2Vmi2ywE5En8WZKL0fqK/RvmUN5aSTKeiWaQ1OqQ79Cf aLlpAkKt6zADlI7b5jpqTBenhyNc1sTcD7oSvmGQOPvl4RrqO8LhE6+OJ1Sut2PigvRkHe JTp9BGzTDGtxGVq/F6KN6npcCyij8PM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669916926; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3SBTAayTX2wK8XVSyRdATXgh0KCZbeE/CV9oqM7zLpU=; b=4MAECrPwICA2/pK9xWcNzSPCT1COMoorRlfVteoOP7tYoHXtSmnLKJFTmbt8FrPu/xDg+R K7vAzfI81u0c1yzQNrfSyhCyk6jWuRbXXd9/8jy+uM0LPenPWaXk62bwUTJFH2Oa2wFHqV ByegBcmTD13AGpauaCNGbUKceyXnPPc= Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=g8W58cbn; spf=pass (imf14.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.181 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D878310000D X-Stat-Signature: fcqxrq1nhqfdz5oedfjjcgk95weijy8y X-Rspam-User: X-HE-Tag: 1669916926-860069 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: On Thu, Dec 1, 2022 at 8:58 AM David Hildenbrand wrote: > > Hi, > > running COW tests (in mm-unstable) on x86-pae with 8GiB, I am able to tri= gger the > following BUG on latest upstream: > > root@debian:/mnt/scratch/linux/tools/testing/selftests/vm# ./cow > # [INFO] detected THP size: 2048 KiB > # [INFO] detected hugetlb size: 2048 KiB > # [INFO] huge zeropage is enabled > TAP version 13 > 1..147 > # [INFO] Anonymous memory tests in private mappings > # [RUN] Basic COW after fork() ... with base page > ok 1 No leak from parent into child > # [RUN] Basic COW after fork() ... with swapped out base page > ok 2 No leak from parent into child > # [RUN] Basic COW after fork() ... with THP > ok 3 No leak from parent into child > # [RUN] Basic COW after fork() ... with swapped-out THP > Segmentation fault > > > [ 879.314600] kernel BUG at include/linux/swapops.h:497! > [ 879.314615] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI > [ 879.314624] CPU: 7 PID: 746 Comm: cow Tainted: G E 6.1= .0-rc7+ #5 > [ 879.314631] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIO= S 1.16.0-1.fc36 04/01/2014 > [ 879.314634] EIP: pagemap_pmd_range+0x644/0x650 > [ 879.314645] Code: 00 00 00 00 66 90 89 ce b9 00 f0 ff ff e9 ff fb ff f= f 89 d8 31 db e8 1b c2 52 00 e9 23 fb ff ff e8 51 80 56 00 e9 b6 fe ff ff <= 0f> 0b bf 00 f0 ff ff e9 38 fa ff ff 3e 8d 74 26 00 55 89 e5 57 31 > [ 879.314651] EAX: ee2bd000 EBX: 00000002 ECX: ee2bd000 EDX: 00000000 > [ 879.314656] ESI: f54b9ed4 EDI: 0001f400 EBP: f54b9db4 ESP: f54b9d68 > [ 879.314660] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010= 246 > [ 879.314670] CR0: 80050033 CR2: b7a00000 CR3: 357452a0 CR4: 00350ef0 > [ 879.314675] Call Trace: > [ 879.314681] ? madvise_free_pte_range+0x720/0x720 > [ 879.314689] ? smaps_pte_range+0x4b0/0x4b0 > [ 879.314694] walk_pgd_range+0x325/0x720 > [ 879.314701] ? mt_find+0x1d6/0x3a0 > [ 879.314710] __walk_page_range+0x164/0x170 > [ 879.314716] walk_page_range+0xf9/0x170 > [ 879.314720] ? __kmem_cache_alloc_node+0x2a8/0x340 > [ 879.314729] pagemap_read+0x124/0x280 > [ 879.314738] ? default_llseek+0xf1/0x160 > [ 879.314747] ? smaps_account+0x1d0/0x1d0 > [ 879.314754] vfs_read+0x90/0x290 > [ 879.314760] ? do_madvise.part.0+0x24b/0x390 > [ 879.314765] ? debug_smp_processor_id+0x12/0x20 > [ 879.314773] ksys_pread64+0x58/0x90 > [ 879.314778] __ia32_sys_ia32_pread64+0x1b/0x20 > [ 879.314787] __do_fast_syscall_32+0x4c/0xc0 > [ 879.314796] do_fast_syscall_32+0x29/0x60 > [ 879.314803] do_SYSENTER_32+0x15/0x20 > [ 879.314809] entry_SYSENTER_32+0x98/0xf1 > [ 879.314815] EIP: 0xb7f36559 > [ 879.314820] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 0= 7 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <= 5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76 > [ 879.314825] EAX: ffffffda EBX: 00000003 ECX: bff00a50 EDX: 00000008 > [ 879.314829] ESI: 005bd000 EDI: 00000000 EBP: b7f1c000 ESP: bff00a00 > [ 879.314833] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000= 246 > [ 879.314840] Modules linked in: intel_rapl_msr(E) intel_rapl_common(E) = intel_pmc_core(E) kvm_intel(E) kvm(E) irqbypass(E) aesni_intel(E) libaes(E)= crypto_simd(E) cryptd(E) rfkill(E) snd_pcm(E) snd_timer(E) joydev(E) snd(E= ) soundcore(E) sg(E) evdev(E) pcspkr(E) serio_raw(E) qemu_fw_cfg(E) parport= _pc(E) ppdev(E) lp(E) parport(E) fuse(E) configfs(E) ip_tables(E) x_tables(= E) autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(= E) t10_pi(E) crc64_rocksoft(E) crc64(E) crc_t10dif(E) sr_mod(E) crct10dif_g= eneric(E) cdrom(E) crct10dif_common(E) bochs(E) drm_vram_helper(E) drm_ttm_= helper(E) ttm(E) drm_kms_helper(E) ata_generic(E) ata_piix(E) crc32_pclmul(= E) libata(E) crc32c_intel(E) drm(E) e1000(E) scsi_mod(E) psmouse(E) i2c_pii= x4(E) scsi_common(E) floppy(E) button(E) > [ 879.314936] ---[ end trace 0000000000000000 ]--- > [ 879.314940] EIP: pagemap_pmd_range+0x644/0x650 > [ 879.314944] Code: 00 00 00 00 66 90 89 ce b9 00 f0 ff ff e9 ff fb ff f= f 89 d8 31 db e8 1b c2 52 00 e9 23 fb ff ff e8 51 80 56 00 e9 b6 fe ff ff <= 0f> 0b bf 00 f0 ff ff e9 38 fa ff ff 3e 8d 74 26 00 55 89 e5 57 31 > [ 879.314949] EAX: ee2bd000 EBX: 00000002 ECX: ee2bd000 EDX: 00000000 > [ 879.314953] ESI: f54b9ed4 EDI: 0001f400 EBP: f54b9db4 ESP: f54b9d68 > [ 879.314957] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010= 246 > [ 879.314961] CR0: 80050033 CR2: b7a00000 CR3: 357452a0 CR4: 00350ef0 > > > Reading /proc/self/pagemap in THP test case seems to trigger the > BUG_ON(is_migration_entry(entry) && !PageLocked(p)); > in pfn_swap_entry_to_page(). > > I did not have time to cherry pick (slow machine) or look into details. > And I don't remember seeing that BUG 64bit yet during my tests. > > Having a migration entry in the swap testcase is kind-of weird. But maybe= it's > related to THP splitting (which would, however, also be weird). I'd have = expected > a swap entry ... hopefully our swap type doesn't get corrupted. I'm on a slow machine too... anyway some hints off the top of my head. First of all, I don't think we will see a real swap PMD entry since even though THP swap is supported the transhuge PMD is split by try_to_unmap() if I remember correctly. So we should just be able to see a regular PMD, a transhuge PMD, a migration PMD or a PROT_NONE PMD (if autonuma is on). Secondly, THP splitting doesn't convert transhuge PMD to migration PMD either, it just splits transhuge PMD then converts every single PTEs to migration PTEs. Thirdly, before pfn_swap_entry_to_page() is called, it does check whether the swap PMD is migration PMD or not, if it is not a VM_BUG is triggered. So it seems like a migration PMD is fine. The problem seems like the page is not locked when doing migration IIUC. > > > Something slightly realted was reported for -next a couple of months ago: > > https://lore.kernel.org/all/11765.1657004484@turing-police/ > > > -- > Thanks, > > David / dhildenb >