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 D8C92C433F5 for ; Wed, 23 Mar 2022 01:22:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 131366B0072; Tue, 22 Mar 2022 21:22:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0DEE86B0073; Tue, 22 Mar 2022 21:22:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC1FC6B0074; Tue, 22 Mar 2022 21:22:55 -0400 (EDT) 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 DF2306B0072 for ; Tue, 22 Mar 2022 21:22:55 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AE195226E8 for ; Wed, 23 Mar 2022 01:22:55 +0000 (UTC) X-FDA: 79273901910.02.7059A9A Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2057.outbound.protection.outlook.com [40.107.212.57]) by imf18.hostedemail.com (Postfix) with ESMTP id 202371C000B for ; Wed, 23 Mar 2022 01:22:54 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nfv1i4aotjvdj8/hnQX1SXnWrT7qqffB4/w3xE1Ad697b+Vqw5hNh8zAlQOqPDs7vOXRmmWKs85HEkt+dDQYTL24uDZbj/8+kZjJJ9obUWUWK1hrrv7yF7PHPAXXaZWgf+77xUrZB/a9KtlYePyBa0W0uXi/ii9N83kAvGqdIlphh+fWPwOVdUrQ/JUM31JUh5QqhIHYElKS+k/YIB2xgdwBUmJUBigS600/KEnQ7d5JruD2vwiIc8lKIYDSQ/9NIlmsKfbbYG8LJq2ao7iCOSeWSJ6BhDW15FfJKnYrBdZw0s/kqv1lJ6aM7DFNZdIcJuFMimVPoAoVZkm89zHQkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hw0EC3jcCLFS0jqbxGzXxOoVbGFNLxYm/kSgqcN0e3o=; b=Uvot2msj60sjeNfuxGcv8ejr1ecrIh8AE4loV5aejIe48qTXo7cR9agAPsFloUedoV+eHbku5sfzPT86/V4K5oRUzkcqLM3eugTGFwxFzhogYeUOZfVGa70nOuQVrHRg8YVqBWGVXWibP7TAGkS5BpJaqS5RD4LOyOw1OatLv+IBHbXQUT/kSPh9ks57A4rszXwVwyyQ23ZLiq4NJCx28mSgWhnCG6mgvXL3IgPFkRp6/osRfbpQp9CPXkrp64jRw0moh2hvBQ2IGrmw0lLlADFEwBD2pXQ12WJzgOBJGFDnVrhgd/1W7W9yJHzbHuGmXpLt7bVHvkiG36PwfNBvsw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hw0EC3jcCLFS0jqbxGzXxOoVbGFNLxYm/kSgqcN0e3o=; b=qQ9GFUcLV8uYcbnj1DJSU3GnYDLzbepx29yyi7AUGNkuEr/Y554aqZjdXdK/EapI5HtFm2p9zd7xb1RP/3KQpPDIb38ng8juJlZSmjgT804cUzO5ry3mwIXzXtLqB1741j3HZyX57858mqsSgaBpYUbdx2oscMpnZxdMaaIMaLy4+ypKpm1kpTmcZtMlS+305WiLLWqOo4hHpTZLi4aDJokwhoXz+OkmeIBkpqlFgMbF+6h+pqwffsd7qILzho48csY1wK2YdMUlv1har0GZRMIrtdJWa2GJudcUlYsUCqJ4DKW2hC/ZGjBBciTPKdqzjDG6YHg6uRZXZmd0V/x7XA== Received: from BYAPR12MB3176.namprd12.prod.outlook.com (2603:10b6:a03:134::26) by BL0PR12MB4690.namprd12.prod.outlook.com (2603:10b6:208:8e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.15; Wed, 23 Mar 2022 01:22:51 +0000 Received: from BYAPR12MB3176.namprd12.prod.outlook.com ([fe80::152f:613b:7041:68d6]) by BYAPR12MB3176.namprd12.prod.outlook.com ([fe80::152f:613b:7041:68d6%7]) with mapi id 15.20.5081.023; Wed, 23 Mar 2022 01:22:51 +0000 From: Alistair Popple To: Matthew Wilcox Cc: Sebastian Andrzej Siewior , linux-mm@kvack.org, Andrew Morton , Thomas Gleixner Subject: Re: BUG_ON() in pfn_swap_entry_to_page() Date: Wed, 23 Mar 2022 11:29:12 +1100 References: User-agent: mu4e 1.6.9; emacs 27.1 In-reply-to: Message-ID: <871qyt4g4a.fsf@nvdebian.thelocal> Content-Type: multipart/mixed; boundary="=-=-=" X-ClientProxiedBy: BYAPR02CA0057.namprd02.prod.outlook.com (2603:10b6:a03:54::34) To BYAPR12MB3176.namprd12.prod.outlook.com (2603:10b6:a03:134::26) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 971b6be3-563f-4ce1-fbe8-08da0c6ba57b X-MS-TrafficTypeDiagnostic: BL0PR12MB4690:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vKlGlAjvvJXK+6bgWqYH4jLUvNZqpGvaXAEjbiufLzphpV8er0+ts79J8YdtOuzdJaySoRrsACMBJHLE89SUYwxoKXT0hIQC6kKplq0o7GfEGHdIsGthNmIqDCNK+RgZGRS4MiJFJ88CXFwHC2UEMZfsf4f2iY+4gfIqjkyjv88axJR+bSaKgsxMo7QnUnpgc0e9NoBPfkK7+oLHhM2UZA60TseXz48i68VGtsD8WhOesdScXRPibCsEAd5wHp7G10SALaUKBmLTGbMTYNUzI+AkRHvSyadV0wI/K6Keob57xb/P0OjCCGqMl3z/PfJUCa73IBiPj10mJ3UjRvHJIvKHaPGrPjjs3w4HK5FsNAgGIQeiCX/R5r6f+ebGJAndK1GZnOWrE1tDReLY7VcHc1CrbX8X51qZXF98tbVKx/ImyoM8FteJE00wouILYCUQRSd2jkQmFRhXCI4ehYFARr7B+pzLgqBTJW0+HCGuCuhVue5pxy3d+uYa3BxeYOhKjE6zMUoGezzI+3V8wStegC7UeGLz02ESx0byS/gibSFo18XOekLiYS9heD9ezlfcyviqqRJXn3wJS7VEwPX93wSWsx6weJq3fipGFrbRVC0HS9q9f69+TGkdR2jPr2g6oFBP+CP4sVjq+mb/xzfR3Q== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR12MB3176.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(2906002)(54906003)(86362001)(66556008)(66476007)(4326008)(8676002)(316002)(6916009)(66946007)(6486002)(9686003)(6512007)(186003)(26005)(6506007)(44144004)(83380400001)(8936002)(508600001)(38100700002)(5660300002)(6666004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?8kdrSKn22Ll4xdwFgD4EjmqsSgaA9xuTUOuzdTd71ZnVlcm40oG5oGAjAYHY?= =?us-ascii?Q?fXFTv97S5SS9wWComI4YPhsJ7Upt7s7kQIw30tD3Ze1Kp+PWu4sYLf69YK2D?= =?us-ascii?Q?jAR553uNDnESz3kkMW4FxmFoKrrbX54yFQta4rR/p5Wfzek3xotBNn7muliE?= =?us-ascii?Q?uLYhoC9Mlh9dIF0sTq3m/87I9aFznuX3wpYGV3tzQlB/sg7jFq4oVJBVZDDO?= =?us-ascii?Q?FMsWEXYRO4oBJdUfO/O5C7dyQKnxDSk7s5xY4CrfHilaQ1AWj0otzTKXsBb4?= =?us-ascii?Q?Wz7Hj7XtItW91c1kT9YGhLRUPN2Ru0v9M68MEu4CsJ0GFZcMqaV1MYZ6xGE5?= =?us-ascii?Q?pxBzNZ6mcy+Fbkb/g4oxW8AX6pi9D9iglOjm9pJlGlIpho0S+YZ+gDeFEDoK?= =?us-ascii?Q?fZ+DSLwLg+qJCIN8FoMRCQBc8CkO32B2liW7Aq5F+XI20k+1f01g46cIw7sU?= =?us-ascii?Q?2bveEx5A0AOARrutF6jjetJNMmB44G/0C0Bh25xRSK8W78eCkFdruXQYos/l?= =?us-ascii?Q?pVdTCW4LlaLDlI83l7ikdfzVb00bvI0+2O/f8j4PP08wKY5X7RKIVkAl4eFH?= =?us-ascii?Q?0OIeKN6vb2fPQjaG3KN0IqOwJkckQLnKYRVjPherSg1Aoh37hdC6hkm1LDHC?= =?us-ascii?Q?7hqU7uWX+Ec2feWGO4jIzCIW/WOdzNYJ8THcQlhD+JIwmQGQVgMA2cGNNcFc?= =?us-ascii?Q?e68+kbqdHyQ0UvaQksMHZP2u35PKu1UARPq2PNNcEMFGlMs9Tx9qckCLpQJd?= =?us-ascii?Q?eBVKxP4Evq3yKEaj1YtvYQPT/iQFiOuUJXy4tmFLFpH4k9zam6f1nxm0Bmau?= =?us-ascii?Q?66/3Ml1H8rQ6gb13sWAX7w2QHxGbCvX74odmp34/8nGi5HdZdQTj3ICDcX6R?= =?us-ascii?Q?biB+3aJHChTciNROZRCDagp2NQeYgDcfLfcwJIyvL9j0k7Zu3gIwBb1HQX2W?= =?us-ascii?Q?XHY1H0IZPLUO2v/XR8SK0M8zOfhuFDD7IYbiAAyaGoJBZQyvPkGA+cGM+C/f?= =?us-ascii?Q?CYeEUOdNRbTQWP376x2yZu2anF7+tOGeRv7CxMGiR9/7P5dO/CgzL6EA+dFD?= =?us-ascii?Q?3AioM4T9GvMIjmuzgJwyjnkmmaARZeX8OxgfNOwqtuxUOXyEHvviKhVWXDRB?= =?us-ascii?Q?5f6ZX88exKPseJgun2BYJ6bZpIDLuOaWIByinfHXshQwnqk/ZdGURYykHMR3?= =?us-ascii?Q?gqrD56bEGvz8F2msMGQKU8PruSs78riTaXmHM+BTraSSLdCw/EyRHgUrDO0d?= =?us-ascii?Q?Ras21zodcPepWVrcSkXRU0pvM9BausDrFCimbgk5B8GFV1aQYfZw6cXNPMMT?= =?us-ascii?Q?J2SJaXYASOGz+jGxDDmbOmlF/nICHEf2NGfBKiJxRSIRchywW31e9Ar//vRU?= =?us-ascii?Q?uBJozBYdARst8xZuma8clZ6kKg+fh39pp1vDNR47S5JZ62sfWWQM/IO7tLxM?= =?us-ascii?Q?N37snmJj8cdc+SXHaAxTo/BoqCUzG1kv?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 971b6be3-563f-4ce1-fbe8-08da0c6ba57b X-MS-Exchange-CrossTenant-AuthSource: BYAPR12MB3176.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2022 01:22:51.2339 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Z0/oPaWOq1Yg/NdazhQLqvoQ0xVSrmTw9zvfGJ1bF9o7diG1iq6IfH26FNGzbG707U56pzNx8YArSnhWuyx9ig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB4690 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 202371C000B X-Stat-Signature: p3sgjjq13rpgrbenknihinhgdnxdu8sa X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=qQ9GFUcL; dmarc=pass (policy=reject) header.from=nvidia.com; spf=none (imf18.hostedemail.com: domain of apopple@nvidia.com has no SPF policy when checking 40.107.212.57) smtp.mailfrom=apopple@nvidia.com X-HE-Tag: 1647998574-787014 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: --=-=-= Content-Type: text/plain Content-Disposition: inline Matthew Wilcox writes: > On Tue, Mar 22, 2022 at 06:25:02PM +0100, Sebastian Andrzej Siewior wrote: >> Run into >> >> |kernel BUG at include/linux/swapops.h:258! >> |RIP: 0010:migration_entry_wait_on_locked+0x233/0x2c0 >> |Call Trace: >> | >> | __handle_mm_fault+0x2bf/0x1810 >> | handle_mm_fault+0x136/0x3e0 >> | exc_page_fault+0x1d2/0x850 >> | asm_exc_page_fault+0x22/0x30 >> >> This is the BUG_ON() in pfn_swap_entry_to_page(). The box itself has no >> swapspace configured. Is this something known? > > It's not been reported before, but it seems obvious why it triggers. > I think it's ffa65753c431 "mm/migrate.c: rework migration_entry_wait() > to not take a pageref". It's obvious the BUG_ON() is because the page isn't locked, but it's less obvious to me at least why we have a migration entry pointing to an unlocked page. > There's a lot of inlining going on, so let's write this out: > > __handle_mm_fault > handle_pte_fault > do_swap_page(): > > entry = pte_to_swp_entry(vmf->orig_pte); > if (unlikely(non_swap_entry(entry))) { > if (is_migration_entry(entry)) { > migration_entry_wait(vma->vm_mm, vmf->pmd, > vmf->address); > > We don't (and can't) have the underlying page locked here. We're just > waiting for it to finish migration. Why can't the page be locked here? Waiting for migration to finish is equivalent to waiting for the page to be unlocked. __unmap_and_move() follows this rough sequence: __unmap_and_move() if (!trylock_page(page)) { if (!force || mode == MIGRATE_ASYNC) goto out; /* * It's not safe for direct compaction to call lock_page. * For example, during page readahead pages are added locked * to the LRU. Later, when the IO completes the pages are * marked uptodate and unlocked. However, the queueing * could be merging multiple pages for one bio (e.g. * mpage_readahead). If an allocation happens for the * second or third page, the process can end up locking * the same page twice and deadlocking. Rather than * trying to be clever about what pages can be locked, * avoid the use of lock_page for direct compaction * altogether. */ if (current->flags & PF_MEMALLOC) goto out; lock_page(page); } [...] if (unlikely(!trylock_page(newpage))) goto out_unlock; [...] } else if (page_mapped(page)) { /* Establish migration ptes */ VM_BUG_ON_PAGE(PageAnon(page) && !PageKsm(page) && !anon_vma, page); try_to_migrate(page, 0); page_was_mapped = true; } if (!page_mapped(page)) rc = move_to_new_page(newpage, page, mode); if (page_was_mapped) remove_migration_ptes(page, rc == MIGRATEPAGE_SUCCESS ? newpage : page, false); Both the source and destination pages (page and newpage respectively) are locked prior to installing migration entries in try_to_migrate() and unlocked after migration entries are removed. In order to remove a migration entry the PTL is required. Therefore while holding the PTL for a migration entry it should be impossible to observe it pointing to an unlocked page. > migration_entry_wait > migration_entry_wait_on_locked(): > > struct folio *folio = page_folio(pfn_swap_entry_to_page(entry)); > > pfn_swap_entry_to_page(): > > struct page *p = pfn_to_page(swp_offset(entry)); > > /* > * Any use of migration entries may only occur while the > * corresponding page is locked > */ > BUG_ON(is_migration_entry(entry) && !PageLocked(p)); > > So why did we not hit this earlier? Surely somebody's testing page > migration? I'm not familiar with the migration code, so maybe this > assertion is obsolete and it's now legitimate to use a migration entry > while the page is unlocked. --=-=-=--