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 5D1C5C433F5 for ; Tue, 22 Mar 2022 17:42:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB38A6B0071; Tue, 22 Mar 2022 13:42:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A63FA6B0072; Tue, 22 Mar 2022 13:42:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92AAE6B0074; Tue, 22 Mar 2022 13:42:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 7FC476B0071 for ; Tue, 22 Mar 2022 13:42:02 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4ADD4FED for ; Tue, 22 Mar 2022 17:42:02 +0000 (UTC) X-FDA: 79272740484.15.5BC8706 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 5CE34140034 for ; Tue, 22 Mar 2022 17:42:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=8NPFTqOy0kt3lZeVKKmQVjmMBZq+0SvWrJCCpCebezk=; b=thxXJ8Oh1tcsZTbD6VXhD2SK7C phNEsK9M1HDw1L9Y+WTWtsDd41PmZwp7ydNIp8Vvqw9kjtXuTGlpHt1L9foasN7CtSdjk1ZN6yfM4 9W0v1cCITyUUNhVjs65dNwv/4u/QznYu6i2m7mnqdR1ZKkoPFMoiFPadiZ2QkjnAE3nS6uDfUT+FG vF/ftxd9rgq6gp+ohBBzsApzNEfi0wIAmJOPsB419sF0w5gUCOwZcgAxyIyMSly0DKtwK41q3cLsK Rf0JOG4wxeMFdHnOhWPBYdnf8lTnHOIB3Qsljws6bawmVTXVCUBhhy8Oe0ss/2dG7sCxoAPWBE7kx lBcKxGwQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWiW7-00Bnro-88; Tue, 22 Mar 2022 17:41:59 +0000 Date: Tue, 22 Mar 2022 17:41:59 +0000 From: Matthew Wilcox To: Sebastian Andrzej Siewior Cc: linux-mm@kvack.org, Andrew Morton , Thomas Gleixner , Alistair Popple Subject: Re: BUG_ON() in pfn_swap_entry_to_page() Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5CE34140034 X-Stat-Signature: c6reqi6x8ytybmihsdum443gq3fcbb7x X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=thxXJ8Oh; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1647970921-454100 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 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". 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. 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.