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 98D2FC25B78 for ; Wed, 22 May 2024 15:18:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6C096B0085; Wed, 22 May 2024 11:18:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF4306B0088; Wed, 22 May 2024 11:18:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6DEC6B0089; Wed, 22 May 2024 11:18:19 -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 9E2FC6B0085 for ; Wed, 22 May 2024 11:18:19 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id ECB44801C5 for ; Wed, 22 May 2024 15:18:18 +0000 (UTC) X-FDA: 82146387876.15.36382FE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf01.hostedemail.com (Postfix) with ESMTP id D58D94001B for ; Wed, 22 May 2024 15:18:15 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SQw0EXZn; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf01.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716391096; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ulyp3dBHYflCzA+CsU6OOs2LSl0OHKOiv4gLt08Co68=; b=nEfG9Wk3jf1E0cUvfYtKsLg2+S6xB59DqiYsGxVBdOuNaxNgAYxSZ/9BrlVaSMnQ6+2F5Y 30hWcTwdkOe44niWHV4MvreyO9tXI7jCddf6u+S8kwaBSU7R1y6Ssukljc9uspaBjwyDvv LysGbWGun6eK7Fw8jT1MludV3eynDu4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SQw0EXZn; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf01.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716391096; a=rsa-sha256; cv=none; b=ojRJ6NXjZVUNzACdEB206I5jQ/4ac/X/fx/Yn4P1utG705buiOw1uSQdtJ8RSYfi5p5uBt b4ZJMusvPx30BLt3HKY5Xust3u4DVDOzBNArdgRFLYicTbdBb6ZUPulaYDCg2sT+S27nyN TNqBO8MdU20kTqomCp1JxmyJGJbjbaI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1716391095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ulyp3dBHYflCzA+CsU6OOs2LSl0OHKOiv4gLt08Co68=; b=SQw0EXZnqA9UNre9PyxpshopkyAv0ed7+1FQVQ6F1E5NifpEyaqTRUXc/d+OY1u3qf2Qrc /8YP1c0ULDQCgpNXlvRPEMI6ObKhiuvvHl1TcJLWbh0+FcEHSe8pAa6ou7RvCGUzRRwz0w +cIYEt1RInTKtKdedfmloLgiaY/+Ev4= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-303-Mf4zREtMONOUp1zuf8HW0w-1; Wed, 22 May 2024 11:18:14 -0400 X-MC-Unique: Mf4zREtMONOUp1zuf8HW0w-1 Received: by mail-il1-f200.google.com with SMTP id e9e14a558f8ab-36da84df784so706375ab.0 for ; Wed, 22 May 2024 08:18:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716391093; x=1716995893; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ulyp3dBHYflCzA+CsU6OOs2LSl0OHKOiv4gLt08Co68=; b=OgcPZZ2+9kVpuBDJkXpRCPHFHJibDexiwr+AecdqAWJw9k/q0I8YL0KzWqMwGL3baF V49yrB1ZMxeY+efFUvvqzOeR5oI8Y1p69G5OpoOhfm1DCtN5JGncF2/ZN7iFrAbO3QZo Or00anPwTo49kImToMAqiU5k3FNcoDdWFKS/7IORTyoKnYLSKRCFFSTFcyKdpoMOFk9p aOHRf5PSGGE0BccNsQsoa+3dPM3R7iTyQJPabrAc5U7uXzTIlbqm5xqmpV5TStFnLMlb SZ/U6el07g1tRfU+ANP//l/vhhKJCd6jxYNvIVu33cVdi+SA58ERYhhPEY8mnIv3SGSU IE3w== X-Forwarded-Encrypted: i=1; AJvYcCUXVnlvU7qkO/ZlNWHhqWUMCVcYsix0AFFJWr5KccytTYkTZR7aCQONIvauGY3CWmXunnHLO78jbJ7LHjlhkY4fLx8= X-Gm-Message-State: AOJu0YxzZIPCaVDRm0ipwOYcwdKqq8GjO/mcLNr2TRBOico0vUomt/mI Dw/0nJSoyIEIH/j3nUcYgGVS//wS3KBWD7pVrX6uVK03vW2TVkc87rEzK19ey1MpNz6PKhxPneM fM7jcR3bNtWDdT8qfC3MhU1jLHqP2GEAUApURYpZahl/A1to1 X-Received: by 2002:a05:6e02:1c02:b0:36a:38bf:5fb2 with SMTP id e9e14a558f8ab-371fb04c8fdmr24423165ab.2.1716391092261; Wed, 22 May 2024 08:18:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHvnnEDsLrIKhn97E1pHNKsOLgdbP5FcPWedFf7z4C9RS6gQMHNy23x7AOb9kd74Li1AccHAA== X-Received: by 2002:a05:6e02:1c02:b0:36a:38bf:5fb2 with SMTP id e9e14a558f8ab-371fb04c8fdmr24422775ab.2.1716391091527; Wed, 22 May 2024 08:18:11 -0700 (PDT) Received: from x1n (pool-99-254-121-117.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-37137c67c0esm7890395ab.59.2024.05.22.08.18.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 May 2024 08:18:11 -0700 (PDT) Date: Wed, 22 May 2024 11:18:08 -0400 From: Peter Xu To: David Hildenbrand , Mikhail Gavrilov Cc: Mikhail Gavrilov , Pavel Tatashin , axelrasmussen@google.com, nadav.amit@gmail.com, Andrew Morton , Linux Memory Management List , Linux List Kernel Mailing Subject: Re: 6.10/bisected/regression - commit 8430557fc584 cause warning at mm/page_table_check.c:198 __page_table_check_ptes_set+0x306 Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D58D94001B X-Stat-Signature: c1ufqjb5p6ridopfj7ihr1sres1fu5ck X-HE-Tag: 1716391095-287039 X-HE-Meta: U2FsdGVkX19XXsNh7XfdzdEpvnIdcgHkdK1/AYT4Lrbj7A5QoKw5eIU3mEaqOA38X+apqZHMfZZlTPhP6smJyfovSSM9mqsYGrrTPJff7TThNIZg0SOMqWg+dwZmdW3Yfm1DQ2xuz+kDDM0T/nAC8QDX29jK7JBTMY8Ebd99/9LX/jft+rgldobZBf1g0pqo6IWLWnqAKrb4DAf/knuBdtflB96yCORLLgFvDdVXKPc+XSdJ/rt9mDjMfAOkpz3GXvGoApBWe1GzuyUX5qn634dXH28a5WfiefUDke7+P/yq/QEBm2jhNt8es8jtjVz30a9bKhQiAzIJOqIIDOQNVWczRFN6LueFYugBf7NDsXKcY0OXFX6rXAokI8p5cOjZVIIumnpVXZinhumk+qqzsGiUX9YlQ40iWnpSV/ZjNekt4eDTEqpuTdhB/jMBWjuZX5mhA1PD6TXdfGROWmucNaTe/IhE759ldhbyxPOLaDe75CZh4XBe6Yyk5aDl6ISEecpODxsdmFCo/pxBGBkZRjAb6vybrYYnXvWAxYKlNWU1yKKh0aPY2N6Ra7YesTIy4WkjOKqfquzm2WIdW8pGrrGxLkjB5jylLxIIKAYbzqhXmNx2LdFyStne8/TyZXJJrSRqaJCTGIrOrdxSPwSPSlzy6G4cK9pkOOu2eZMhWquNJhurSUOjvvFFjJZme1sBMjMl+M0DMyDjJBnG/go+ArIUMldGyxXp7vUBy2uajDmrx5jPr66fJNlI7n/C8usfepf02SRbEz7jUrXqFIb7X6kvnio1sUoZckYuLKEi1Y3mdg8dnm+hb8xb3LyyJpKhpo1PXjE9PKW7Urgfg77AWbhDy3HjciyajEPWOkWnE54YuIdnj6sLha/e7ByjkNEuSktMRdLLC2d7t5aEAYPOK7913RyYiAzkp3xecbPUbcNXXVNjxOYRRdMJfdFtBKjPvCwcvOYZtYPk8JQYCof grgnA6eg a+NiRAduMzQ5a5bEDuepFD2OnACZVX3Ic477p7u6pw4lMCwducjjcB2pycIYWp0fz1fm+7gc1mB1eErvwp1VHqUa/eneA5RHM7R7Yc70ne7nyCCnEzcNzBM/FXWO7XP2dw3V9BY7uJHHhrNciqWS7CSHBKqvgcOSx+224U6UYv7/V6cvV/riFybeVC8TSR0yRGGv7g+H8CgZe4zXV5kdzP2f48tQ/e/8Iqlk5QoymlkE5LimOxCXu+co7JPaxyzo6V2lhq4HuyRDrG2ITtEtu3nyhaNr1A6ouzS8VQYlaZ/qSZBuiYT1ACZ0RT03Qnq/C6xi+eowrbdwf+xU7/Ci+Oqpn4ICfUtVv6BLlkRDo3IPrZ8qmgtmHt/GzcgrWlxMoqPrc7er6ZxxO8hbpCX88Rnom0TsVUOME9VTJLBhjOvtpdGdaV17qPgF+p1ui/WTQQMepvOm7eb6oEKTX1WByFezQz1k4BzbYjHTC+BcreHnF9Zeu6htBfwDXxDV34uxKk5g4RQI32pc2/aPeuyInmGummKA/6aIdNRTfR10Py0iOCLPUlSEnpVjJtmcGCr+MUNLA 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: List-Subscribe: List-Unsubscribe: On Wed, May 22, 2024 at 09:48:51AM +0200, David Hildenbrand wrote: > On 22.05.24 00:36, Peter Xu wrote: > > On Wed, May 22, 2024 at 03:21:04AM +0500, Mikhail Gavrilov wrote: > > > On Wed, May 22, 2024 at 2:37 AM Peter Xu wrote: > > > > Hmm I still cannot reproduce. Weird. > > > > > > > > Would it be possible for you to identify which line in debug_vm_pgtable.c > > > > triggered that issue? > > > > > > > > I think it should be some set_pte_at() but I'm not sure, as there aren't a > > > > lot and all of them look benign so far. It could be that I missed > > > > something important. > > > > > > I hope it's helps: > > > > Thanks for offering this, it's just that it doesn't look coherent with what > > was reported for some reason. > > > > > > > > > sh /usr/src/kernels/(uname -r)/scripts/faddr2line /lib/debug/lib/modules/(uname -r)/vmlinux debug_vm_pgtable+0x1c04 > > > debug_vm_pgtable+0x1c04/0x3360: > > > native_ptep_get_and_clear at arch/x86/include/asm/pgtable_64.h:94 > > > (inlined by) ptep_get_and_clear at arch/x86/include/asm/pgtable.h:1262 > > > (inlined by) ptep_clear at include/linux/pgtable.h:509 > > > > This is a pte_clear(), and pte_clear() shouldn't even do the set() checks, > > and shouldn't stumble over what I added. > > > > IOW, it doesn't match with the real stack dump previously: > > > > [ 5.581003] ? __page_table_check_ptes_set+0x306/0x3c0 > > [ 5.581274] ? __pfx___page_table_check_ptes_set+0x10/0x10 > > [ 5.581544] ? __pfx_check_pgprot+0x10/0x10 > > [ 5.581806] set_ptes.constprop.0+0x66/0xd0 > > [ 5.582072] ? __pfx_set_ptes.constprop.0+0x10/0x10 > > [ 5.582333] ? __pfx_pte_val+0x10/0x10 > > [ 5.582595] debug_vm_pgtable+0x1c04/0x3360 > > > > Staring at pte_clear_tests(): > > #ifndef CONFIG_RISCV > pte = __pte(pte_val(pte) | RANDOM_ORVALUE); > #endif > set_pte_at(args->mm, args->vaddr, args->ptep, pte); > > So we set random PTE bits, probably setting the present, uffd and write bit > at the same time. That doesn't make too much sense when we want to perform > that such combinations cannot exist. Here the issue is I don't think it should set W bit anyway, as we init page_prot to be RWX but !shared: args->page_prot = vm_get_page_prot(VM_ACCESS_FLAGS); On x86_64 (Mikhail's system) it should have W bit cleared afaict, meanwhile the RANDOM_ORVALUE won't touch bit W due to S390_SKIP_MASK (which contains bit W / bit 1, which is another "accident"..). Then even if with that it should not trigger.. I think that's also why I cannot reproduce this problem locally. But I think applying random bits are indeed tricky, and I don't really know why we did that. I can get that we want to set some non-empty pte, but AFAIU this should be far enough: pte_t pte = pfn_pte(args->pte_pfn, args->page_prot); As that should already be pte_none()==false, then we clear and recheck making sure pte_none(), looks good enough already. Obviously that trick already broke PPC64 and S390 before due to existance of PPC64_SKIP_MASK etc.. I guess it won't hurt in this case to double check, though. Mikhail, would you mind mark this line to see whether it's the line that triggered your WARNING? Perhaps also dump something more than that, something like: ===8<=== diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c index f1c9a2c5abc0..610b1996b2e9 100644 --- a/mm/debug_vm_pgtable.c +++ b/mm/debug_vm_pgtable.c @@ -635,7 +635,8 @@ static void __init pte_clear_tests(struct pgtable_debug_args *args) return; #ifndef CONFIG_RISCV - pte = __pte(pte_val(pte) | RANDOM_ORVALUE); + pr_info("page_prot=0x%lx\n", pgprot_val(args->page_prot)); + pr_info("pteval|RANDOM_ORVALUE=0x%lx\n", pte_val(pte) | RANDOM_ORVALUE); #endif set_pte_at(args->mm, args->vaddr, args->ptep, pte); flush_dcache_page(page); ===8<=== For me it dumps: [ 2.249478] debug_vm_pgtable: [pte_clear_tests ]: page_prot=0x25 [ 2.250049] debug_vm_pgtable: [pte_clear_tests ]: pteval|RANDOM_ORVALUE=0xbffffffffffffff5 Logically you should see the same, but since faddr2line doesn't seem to work properly for some reason, maybe we can try. > > In pmd_clear_tests() and friends we use WRITE_ONCE() instead, so there we > don't run into trouble. Right, and I think they should probably use set_pmd_at() rather than WRITE_ONCE() if we want to cover the helpers.. but that's another story. Thanks, -- Peter Xu