Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2381541ioo; Sat, 28 May 2022 11:53:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyY8dHhZKlhlKRnoIiOpMxod0y2rCm7538C/lD7tInBtq5L/X4++bss9gelwZJq44QxvDd9 X-Received: by 2002:a17:90a:fd91:b0:1e0:ca18:423c with SMTP id cx17-20020a17090afd9100b001e0ca18423cmr14580073pjb.48.1653763988895; Sat, 28 May 2022 11:53:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653763988; cv=none; d=google.com; s=arc-20160816; b=ZlxH0OjjjtUSN1lsmW2/YfTOKaW4vyCfVnDqNX2sGLBINh+trRxccA9pwDXqKACkFV 5Esaydmbywd5m2q4EZk1sXsZ5xDq+GFxngMH+wP3n16iAnMcsnx/vx6cF1g+3bDLLmX0 sSeKKbGJWR/c15cgZr4GJUMsAE0Oi36zMV0D6TFoRILURtN3zsc2NE6T1UmOP/8etqfi 6Ej5hLgz0fvJw+XcfPUqmh6ED++4uTfSVJ/2Jlg8QjRQ/BH4Ftj5RyKwP5V9jqCpgAAt Px9lEPUML4Cf+BfXB1zpNYxlocT/3wDRhwN6KtWyDt8oMuKqBw+imNA48D8rLZjaopPQ 9f7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=74LV4BJ0hvYMDeE+JXTcnjOCGMPOv6ddg32Qph+cP1s=; b=PvzQ7pBLO57B3E8BzW3WaOXm7RdouAKFoSWXQmEmCzfzp8MTGvXeJgWnXhdnyzdl/P zz2rFZ1v8u5+mWaWgfn9fYpc6sIc222e6JBvflZwUqbD9ND77xegtjKeV1TREJ3YC0jE WHv6HjB2UCTtxdLVAQL7rfIPvvInO47jwBP8onqhsIhXo0FoNiU2vTkUYmE0pVAAzaxk kz1JeneVO8H2q9tk6fyNd7jRjtCLmNnD1gqJNtbQab5+3mpjrYigYw5ADOomFMRT6k5p 0Rn8EsdAFL496YZ+A2op2RKBqksiR3iL1EXeGEdDu6Qp08p6++BDk4AzhZM29YsFCQPS lOTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=io894yW6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id j14-20020a170903024e00b0016229a39343si11084086plh.115.2022.05.28.11.53.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 May 2022 11:53:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=io894yW6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6D69E33A21; Sat, 28 May 2022 11:40:15 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345268AbiEZSPw (ORCPT + 99 others); Thu, 26 May 2022 14:15:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237702AbiEZSPv (ORCPT ); Thu, 26 May 2022 14:15:51 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6441B36EE for ; Thu, 26 May 2022 11:15:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A5C60B8219C for ; Thu, 26 May 2022 18:15:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19817C385A9; Thu, 26 May 2022 18:15:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1653588947; bh=eDa5JDlzOG2uepfEmO8AYQmRjiuCz3wWQubHDZpva1c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=io894yW6l2/GaI547yCazzlKFHTxBZJyDq+d85oc6e4RoydxxnEAMrcQ92AygDOVv kUyvwHR+qf6Fci6chzGVLtdCM54BpaiJl+taObTWxwAsY7nPn2sxqRjuU6SEKFQfim dHdXPqpOjcC7lFry6r7mINTz7qO56CyMwofHCiLw= Date: Thu, 26 May 2022 11:15:46 -0700 From: Andrew Morton To: Pasha Tatashin Cc: Matthew Wilcox , Miaohe Lin , David Rientjes , linux-mm , LKML Subject: Re: [PATCH] mm/page_table_check: fix accessing unmapped ptep Message-Id: <20220526111546.50102da288cccbe913cadbf4@linux-foundation.org> In-Reply-To: References: <20220526113350.30806-1-linmiaohe@huawei.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 26 May 2022 09:37:43 -0400 Pasha Tatashin wrote: > On Thu, May 26, 2022 at 9:34 AM Matthew Wilcox wrote: > > > > On Thu, May 26, 2022 at 07:33:50PM +0800, Miaohe Lin wrote: > > > ptep is unmapped too early, so ptep will be accessed while it's unmapped. > > > Fix it by deferring pte_unmap() until page table checking is done. > > > > > > Fixes: 80110bbfbba6 ("mm/page_table_check: check entries at pmd levels") > > > Signed-off-by: Miaohe Lin > > > --- > > > mm/page_table_check.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/mm/page_table_check.c b/mm/page_table_check.c > > > index 3692bea2ea2c..971c3129b0e3 100644 > > > --- a/mm/page_table_check.c > > > +++ b/mm/page_table_check.c > > > @@ -234,11 +234,11 @@ void __page_table_check_pte_clear_range(struct mm_struct *mm, > > > pte_t *ptep = pte_offset_map(&pmd, addr); > > > unsigned long i; > > > > > > - pte_unmap(ptep); > > > for (i = 0; i < PTRS_PER_PTE; i++) { > > > __page_table_check_pte_clear(mm, addr, *ptep); > > > addr += PAGE_SIZE; > > > ptep++; > > > } > > > + pte_unmap(ptep); > > > > But ptep was mutated in the loop. So surely this needs to be: > > > > pte_unmap(ptep - PTRS_PER_PTE); > > > > or you'll be unmapping the wrong page. > > Right, thank you Matthew. > > Miaohe, please store the ptep, or maybe drop this patch entirely. I think it's best to fix it. I rewrote the changelog as : ptep is unmapped too early, so ptep could theoretically be accessed while : it's unmapped. This might become a problem if/when CONFIG_HIGHPTE becomes : available on riscv. : : Fix it by deferring pte_unmap() until page table checking is done. I'll retain the Fixes:. This doesn't imply cc:stable in MM, and anyone who backports the original patchset will want to know about this fixup. And I queued a fixup for the thing Matthew noticed.