Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5098769pxv; Wed, 28 Jul 2021 03:06:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyTFUVoOr324G1AhHt4PbpIVLFmRKsoQXRuTrpkpEcK7ih8QOzbwnwA0dE1+Tv1CV4o03Sm X-Received: by 2002:a05:6638:d51:: with SMTP id d17mr26297450jak.109.1627466775363; Wed, 28 Jul 2021 03:06:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627466775; cv=none; d=google.com; s=arc-20160816; b=AWTgOtlS77/3uXLXeY0DnVBilhxKaA5b2GDx/VoMkvhCmgGf4uaqOfZ13pk50L2MaZ fT6k/qiQmz4h7fb/iyhsPZI8Bn5gwcXN9mtDdipW5Mt1iPl80rgXoszwQna2XvGgdPlC hyQcXs8iTfIW0pVnl6OmI8PAfIldnv/Oht1BO6WsNZctLD3Vhra1Ud+abruk6MVxgQ+a yqt0X2v2wG9puUDFueayVLQ9nlIPdrbDDVX7TBWldZ/l3ngVofbJu3P65Ni69VzcpplT lkx3F3Bg5EAr2tZQTdBUuctA1cs+nXlUYrir7QyNP/z3yo0XB+ALdg8RBRmOHoRLiOZe SMCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=H8PV7sVC9fSdeJtQPCpa/aonzXtHYfQfCizlWDnarXg=; b=InBp0NYjjAyW+9vWBnMB4ShOAVEqIAJmGMykUdKrHfk+nKsrMl4jalerfDN5DYVOCP hLi8XoeK3TaskX90Rfr96MjaGY0+KZ64CzH7gztrIX5MJfJ6Ky30uOwkW7EjatCvvVi/ 9/TUHLQk7UYnTIfY0B3UAamopRj9gUeNbUVWgmYOKVqJu6Od/ZnFrm1B+3c2vhx6inNe 3MeUJNMbaYQ3GZSqNIOlWgEcS5aP7NbeHHRC3szHrpuyiD2eKRrFkaEmh0FofeCfNi8h z/v8tAaAk4aTS9LZQDaU/GPOoII+bRM+UDtNc4wvThTeSF/wgbNhKz8SiM7jDmwQmBMy X/SQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l6si6071142ilg.44.2021.07.28.03.06.03; Wed, 28 Jul 2021 03:06:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235764AbhG1KEz (ORCPT + 99 others); Wed, 28 Jul 2021 06:04:55 -0400 Received: from foss.arm.com ([217.140.110.172]:54448 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231635AbhG1KEy (ORCPT ); Wed, 28 Jul 2021 06:04:54 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AB5FC31B; Wed, 28 Jul 2021 03:04:52 -0700 (PDT) Received: from [10.163.65.183] (unknown [10.163.65.183]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 473503F73D; Wed, 28 Jul 2021 03:04:49 -0700 (PDT) Subject: Re: [PATCH v4 12/12] mm/debug_vm_pgtable: Fix corrupted page flag To: Christophe Leroy , Gavin Shan Cc: shan.gavin@gmail.com, chuhu@redhat.com, akpm@linux-foundation.org, will@kernel.org, catalin.marinas@arm.com, cai@lca.pw, aneesh.kumar@linux.ibm.com, gerald.schaefer@linux.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20210727061401.592616-1-gshan@redhat.com> <20210727061401.592616-13-gshan@redhat.com> <20210728095326.Horde.k1npSPaQKh2i7W3XoBsdiQ3@messagerie.c-s.fr> From: Anshuman Khandual Message-ID: <58a1eaa9-ba63-403b-1f4b-c22f23a3a0d3@arm.com> Date: Wed, 28 Jul 2021 15:35:37 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210728095326.Horde.k1npSPaQKh2i7W3XoBsdiQ3@messagerie.c-s.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/28/21 1:23 PM, Christophe Leroy wrote: > Gavin Shan a écrit : > >> In page table entry modifying tests, set_xxx_at() are used to populate >> the page table entries. On ARM64, PG_arch_1 (PG_dcache_clean) flag is >> set to the target page flag if execution permission is given. The logic >> exits since commit 4f04d8f00545 ("arm64: MMU definitions"). The page >> flag is kept when the page is free'd to buddy's free area list. However, >> it will trigger page checking failure when it's pulled from the buddy's >> free area list, as the following warning messages indicate. >> >>    BUG: Bad page state in process memhog  pfn:08000 >>    page:0000000015c0a628 refcount:0 mapcount:0 \ >>         mapping:0000000000000000 index:0x1 pfn:0x8000 >>    flags: 0x7ffff8000000800(arch_1|node=0|zone=0|lastcpupid=0xfffff) >>    raw: 07ffff8000000800 dead000000000100 dead000000000122 0000000000000000 >>    raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 >>    page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag(s) set >> >> This fixes the issue by clearing PG_arch_1 through flush_dcache_page() >> after set_xxx_at() is called. For architectures other than ARM64, the >> unexpected overhead of cache flushing is acceptable. >> >> Signed-off-by: Gavin Shan > > Maybe a Fixes: tag would be good to have Agreed. Fixes: a5c3b9ffb0f4 ("mm/debug_vm_pgtable: add tests validating advanced arch page table helpers") > > And would it be possible to have this fix as first patch of the series so that it can be applied to stable without applying the whole series ? Changing the allocation scheme does solve another problem (using non-owned pages) but is achieved via the entire series applied. But this particular patch could be moved to the beginning without much problem.