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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFDC0C43332 for ; Sat, 21 Mar 2020 22:46:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C299B20777 for ; Sat, 21 Mar 2020 22:46:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584830807; bh=pBP/6b4ajfKJCuF6Edxia1qiK6WLfxFlX24bBcuc9dY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=rvx0Tk9GgiVO/aIPMRm8PGAsPhVbpINLlt+rIBrfZHXxdZ6N1dNp8q7Xg43lZK80I BVXpx5AhnLqT+fV2Wk5yK3s7a8m32jLWs21xoXMIMvZWc/M5g4QBDXgi/XiV8Vyo22 TYyBjF4SZDLbv6ZeVN8APtLpGKJU8c7P4dVi1esc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728120AbgCUWqq (ORCPT ); Sat, 21 Mar 2020 18:46:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:56994 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726859AbgCUWqq (ORCPT ); Sat, 21 Mar 2020 18:46:46 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C425E20754; Sat, 21 Mar 2020 22:46:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584830805; bh=pBP/6b4ajfKJCuF6Edxia1qiK6WLfxFlX24bBcuc9dY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Yg0udSPDLvx9DBCpAS4miIQcR5my3Wgw5OgVsuwCeEHl3PEU5nW/yxpZ1ta/O3PqT 2VkvG93i+WOHoL0LiinoUqBAndeB6sqyl9BMeBmJxGy7RZmu+3jGlmTBVQ75eFy86N HjQsE/5wuMkFKDW1r/OxKU9b0IbpsHSa7H5C78H0= Date: Sat, 21 Mar 2020 15:46:44 -0700 From: Andrew Morton To: Mike Kravetz Cc: "Longpeng (Mike)" , Matthew Wilcox , Qian Cai , kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org, arei.gonglei@huawei.com, weidong.huang@huawei.com, weifuqiang@huawei.com, kvm@vger.kernel.org, linux-mm@kvack.org, Sean Christopherson , stable@vger.kernel.org Subject: Re: [PATCH v2] mm/hugetlb: fix a addressing exception caused by huge_pte_offset() Message-Id: <20200321154644.bcbedca64f620d3cbe215231@linux-foundation.org> In-Reply-To: <1b61f55a-d825-5721-2bfe-5e0efc9c9c2d@oracle.com> References: <20200222170222.GJ24185@bombadil.infradead.org> <1b61f55a-d825-5721-2bfe-5e0efc9c9c2d@oracle.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Feb 2020 13:41:46 -0800 Mike Kravetz wrote: > > Secondly, huge_pte_offset in mm/hugetlb.c is for ARCH_WANT_GENERAL_HUGETLB, many > > architectures use it, can you make sure there is no issue on all the > > architectures using it with all the version of gcc ? > > > > Thirdly, there are several places use READ_ONCE to access the page table in mm/* > > (e.g. gup_pmd_range), they're also generical for all architectures, and they're > > much more like unnecessary than here, so why there can use but not here? What's > > more, you can read this commit 688272809. > > Apologies for the late reply. > > In commit 20a004e7 the message says that "Whilst there are some scenarios > where this cannot happen ... the overhead of using READ_ONCE/WRITE_ONCE > everywhere is minimal and makes the code an awful lot easier to reason about." > Therefore, a decision was made to ALWAYS use READ_ONCE in the arm64 code > whether or not it was absolutely necessary. Therefore, I do not think > we can assume all the READ_ONCE additions made in 20a004e7 are necessary. > Then the question remains, it it necessary in two statements above? > I do not believe it is necessary. Why? In the statements, > if (!pgd_present(*pgd)) > and > if (!p4d_present(*p4d)) > the variables are only accessed and dereferenced once. I can not imagine > any way in which the compiler could perform multiple accesses of the variable. > > I do believe the READ_ONCE in code accessing the pud and pmd is necessary. > This is because the variables (pud_entry or pmd_entry) are accessed more than > once. And, I could imagine some strange compiler optimization where it would > dereference the pud or pmd pointer more than once. For this same reason > (multiple accesses), I believe the READ_ONCE was added in commit 688272809. > > I am no expert in this area, so corrections/comments appreciated. > > BTW, I still think there may be races present in lookup_address_in_pgd(). > Multiple dereferences of a p4d, pud and pmd are done. Based on Mike's observations I shall drop this patch. If we still believe it is needed, please enhance the changelog, resend and let's take another look.