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 29B0CC43334 for ; Tue, 7 Jun 2022 19:07:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81BEE8D0003; Tue, 7 Jun 2022 15:07:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F2638D0002; Tue, 7 Jun 2022 15:07:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BA0F8D0003; Tue, 7 Jun 2022 15:07:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5D8468D0002 for ; Tue, 7 Jun 2022 15:07:49 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 09F5A60F24 for ; Tue, 7 Jun 2022 19:07:49 +0000 (UTC) X-FDA: 79552374258.11.8C7E304 Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) by imf21.hostedemail.com (Postfix) with ESMTP id 2BAC31C0065 for ; Tue, 7 Jun 2022 19:07:47 +0000 (UTC) Received: by mail-ua1-f49.google.com with SMTP id m10so6123467uao.11 for ; Tue, 07 Jun 2022 12:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s58JyYfxjJZK+xBks84yqht9lKqAP2iTqEYGVHfv2fA=; b=UniKPp2fwri4mGTTugBIeQ1NZBedToPyxhulFcbp+XWVAnwR5PUv5ooePbH/zWikdq 6FaFxdOB4iEIsUrcTX9Qm4jCxkNTtmM6YKlPmKISkWBzbViQ2rTzilpDo+Iz9nowKLFJ WmejIqLXPDwqBVm9B+sGT+TwXPzscXlYaRIvkFA7RNeTqNgz7kP6U+d+Mi1FDaQt+MrA UiCKot2InqF/Xaqatw80AlYd7gtH10a85bDH2ZXIa0NKfAVKksTZaxf1/l+Yk1jbOveM MIAHxHTJmYsEMuYg4W58T1eg1cbE513Klo79bfZpVLgYtgZuYtoWI37VAmFSLRKiTWYb 8MHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s58JyYfxjJZK+xBks84yqht9lKqAP2iTqEYGVHfv2fA=; b=Yyb6Isl9tmNfs3bIIN+/MYYd53mpWVsvErqAF+A9XHhSdlFEz1LW0IQSY+24bX35Sv ZgxAR3V6ZjU3hdWoVgr5G7YTL/61oVfzb+D2LHHdEjsDeY0gwT/6ZVnAyjepbf5T/X41 Fr/4TaR8XT/G2NcHhSRXIq3rNzqz1XIJypuVsUh7+CluvwYAQEoiEQOubi1ahw7GEFWe 7LkPGWk8f+5B/gPsWBdIezvZzwMxGEMoXNFLZjZG/QSBW3srVHi/REBAGYE98W/Xa7Vt PaAojyP2A6v1d91SM3RCIo6fNlc8BkQ5wTWBf/zgEvT+6GRyfear7shVRwTX6SB82Lf7 lmzA== X-Gm-Message-State: AOAM533w4Gpxhn1gn7JAh4D8SUfbS6OgiHTvtPLGyc+F/bMoDCyZprev OKPoc2GWqroh01i32jl6yWuNpz69pBn/EZ7g0IrOlQ== X-Google-Smtp-Source: ABdhPJzS0mtcx5OOOAWXsJb2eTSprTdFF5fKfwZ/5n8eY041PP99y8PgkVi5+GKdcmJEaZnwyH4Uqru8wQ1EJ+a7ziU= X-Received: by 2002:ab0:2008:0:b0:352:2b3a:6bce with SMTP id v8-20020ab02008000000b003522b3a6bcemr37171732uak.19.1654628867656; Tue, 07 Jun 2022 12:07:47 -0700 (PDT) MIME-Version: 1.0 References: <20220518014632.922072-1-yuzhao@google.com> <20220518014632.922072-8-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Tue, 7 Jun 2022 13:07:11 -0600 Message-ID: Subject: Re: [PATCH v11 07/14] mm: multi-gen LRU: exploit locality in rmap To: Barry Song <21cnbao@gmail.com> Cc: Will Deacon , Andrew Morton , Linux-MM , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Johannes Weiner , Jonathan Corbet , Linus Torvalds , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Peter Zijlstra , Tejun Heo , Vlastimil Babka , LAK , Linux Doc Mailing List , LKML , x86 , Kernel Page Reclaim v2 , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain , huzhanyuan@oppo.com Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UniKPp2f; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.49 as permitted sender) smtp.mailfrom=yuzhao@google.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2BAC31C0065 X-Rspam-User: X-Stat-Signature: 7d4anq69oem39kwdwxdqn71s9rw5ocxh X-HE-Tag: 1654628867-190362 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, Jun 7, 2022 at 1:37 AM Barry Song <21cnbao@gmail.com> wrote: > > On Mon, Jun 6, 2022 at 9:25 PM Barry Song <21cnbao@gmail.com> wrote: > > > > On Wed, May 18, 2022 at 4:49 PM Yu Zhao wrote: ... > I can't really explain why we are getting a random app/java vm crash in monkey > test by using ptep_test_and_clear_young() only in lru_gen_look_around() on an > armv8-a machine without hardware PTE young support. > > Moving to ptep_clear_flush_young() in look_around can make the random > hang disappear according to zhanyuan(Cc-ed). This sounds too familiar -- let me ask again: was the following commit included during the test? 07509e10dcc7 arm64: pgtable: Fix pte_accessible() If not, it will cause exactly the problem you described. And what about this one? e914d8f00391 mm: fix unexpected zeroed page mapping with zram swap Missing it also causes userspace memory corruption on Android, i.e., random app crashes. > On x86, ptep_clear_flush_young() is exactly ptep_test_and_clear_young() > after > 'commit b13b1d2d8692 ("x86/mm: In the PTE swapout page reclaim case clear > the accessed bit instead of flushing the TLB")' > > But on arm64, they are different. according to Will's comments in this > thread which > tried to make arm64 same with x86, > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1793881.html > > " > This is blindly copied from x86 and isn't true for us: we don't invalidate > the TLB on context switch. That means our window for keeping the stale > entries around is potentially much bigger and might not be a great idea. > > If we roll a TLB invalidation routine without the trailing DSB, what sort of > performance does that get you? > " > We shouldn't think ptep_clear_flush_young() is safe enough in LRU to > clear PTE young? Any comments from Will? > > > > > btw, lru_gen_look_around() has already included 'address', are we doing > > pte check for 'address' twice here? Explained in the previous reply. Hope that clarifies things.