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 A5EE8C433F5 for ; Tue, 5 Apr 2022 10:44:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D0046B0071; Tue, 5 Apr 2022 06:43:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 258EC6B0073; Tue, 5 Apr 2022 06:43:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FB396B0074; Tue, 5 Apr 2022 06:43:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id F0C5C6B0071 for ; Tue, 5 Apr 2022 06:43:54 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id B225C121265 for ; Tue, 5 Apr 2022 10:43:44 +0000 (UTC) X-FDA: 79322489568.11.AFD9774 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf07.hostedemail.com (Postfix) with ESMTP id 1DA6F4000E for ; Tue, 5 Apr 2022 10:43:43 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id CF62F1F390; Tue, 5 Apr 2022 10:43:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649155422; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZV6J9Il753rBNuhU1RPeVKSIez37U0dfz5W2smwY0X4=; b=eb00yWHMq9w1ZkkiXOQR2T4sGf+wUVynhUp66A9hY0CVxtite1vGwNZ6BPzb1UlU2BL28d wTKf5ISHxuLw0xTrZeVg13mSC3JyfTO62/IGZv0f6GZutjtwNLvkg41UFt8cdhdaPGNu6A Jc6p/QZRaGS1QklGnXhx3JQS5q7ylDc= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 95D3EA3B93; Tue, 5 Apr 2022 10:43:42 +0000 (UTC) Date: Tue, 5 Apr 2022 12:43:41 +0200 From: Michal Hocko To: Alexander Sverdlin Cc: Nicholas Piggin , Alexander Duyck , Matthew Wilcox , Hugh Dickins , Yu Zhao , Mel Gorman , Lee Schermerhorn , Sasha Levin , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: mm: swap: locking in release_pages() Message-ID: References: <89009285-c75d-0f09-5b08-d133c42a18f9@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89009285-c75d-0f09-5b08-d133c42a18f9@nokia.com> X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=eb00yWHM; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1DA6F4000E X-Stat-Signature: faup9xsnppkf8pgmdb4kfefikmnf3mba X-HE-Tag: 1649155423-691261 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 05-04-22 12:20:15, Alexander Sverdlin wrote: > Dear mm developers! > > After experiencing a crash in release_pages() [1] I'm trying to understand the locking in the release_pages(): > > No matter if we consider v5.17 or v5.4 (as in my case), they both have similar locking patterns: Similar but the notable difference is that 5.4 used per node lru locking while newer versions 5.11+ kernels use per memcg locking. If you see the issue on 5.4 then this is unlikely a regression. [...] > What I don't understand here is, what guarantees us that "if (PageLRU(page))" condition > is still valid after we swap the locks in "if (pgdat != locked_pgdat)" case? The underlying reasoning is that the PageLRU handling is done after the last reference has been dropped. isolate_lru_page and others should elevate the reference count before isolating page from LRU lists. Some callers user TestClearPageLRU > If we check under one lock and VM_BUG_ON_PAGE() under another lock, what actually stops > it from crashing as below or BUG() from time to time? G > > 1. Crash of v5.4.170 on an ARM32 machine: > > Unable to handle kernel NULL pointer dereference at virtual address 00000104 > pgd = e138149d > [00000104] *pgd=84d2fd003, *pmd=8ffd6f003 > Internal error: Oops: a07 [#1] PREEMPT SMP ARM > ... > CPU: 1 PID: 6172 Comm: AaSysInfoRColle Tainted: G B O 5.4.170-... #1 > Hardware name: Keystone > PC is at release_pages+0x194/0x358 > LR is at release_pages+0x10c/0x358 Which LOC does this correspond to? (faddr2line should give you a nice output). -- Michal Hocko SUSE Labs