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 6BB13FA3743 for ; Tue, 1 Nov 2022 05:46:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E81316B0072; Tue, 1 Nov 2022 01:46:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E31196B0073; Tue, 1 Nov 2022 01:46:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1FA76B0074; Tue, 1 Nov 2022 01:46:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C6B7E6B0072 for ; Tue, 1 Nov 2022 01:46:57 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 937A5C04E6 for ; Tue, 1 Nov 2022 05:46:57 +0000 (UTC) X-FDA: 80083789674.03.23A75A3 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf01.hostedemail.com (Postfix) with ESMTP id 69BC340005 for ; Tue, 1 Nov 2022 05:46:55 +0000 (UTC) Received: by mail-pf1-f170.google.com with SMTP id 130so12587702pfu.8 for ; Mon, 31 Oct 2022 22:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=M6ipy07kqjTgYjFgwvJ6maNLkyoLrvEhOe6gVx9YFPQ=; b=NaskUVlqdkI/mjlrPOq+/AOceuxy3otEoNFTIgkCyvMnbCCwfYfR7YOPYB6P10gPlZ KSIB2UMpNier4niv7pIOt7JiXL1wnNRJkSK58rQhh/dqAqYAFs0cz9jqiCfNm+lTx6CT qz8eZ0GNtXnqV+q1PV5uehTyA86lMRCCfqDwmTCZaClLjqVDLG1Upc5PECu83fELnh96 +RFYbhQ878pjwt/J57UNPJgRtwyfesSN4HatbKMZeRB257kkcKDZCkHxD2ZAoqt9MP0V hxQorL/wvBV2dsrQNjgU2pCDLCDQ/RYtG8Km4Fi0KP8gQ+EiVA54L5bdZMZ1S26nh02D FiCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=M6ipy07kqjTgYjFgwvJ6maNLkyoLrvEhOe6gVx9YFPQ=; b=pVUkOdYR6b0KFpWpjIqSsJ7evneGjSq5xjdNuYPCgMwLgZda/00voF6Xn7zV5WO50p jQopHGw1ezQFRGpyTaJgWYcxZfFaXCi6SLoh25t21J+VXgmlQXKW0rq8VlcKmIzflDnm emuTlc7v4sTyYj8OOzl93FBBm97g3v795rWDaU3MUeQZZcGEj5DkwIryXCQPA9VasAwz SP0be4780kIpvPNVHEk6Sdw+FTmT4+Q6OiG8Hp9kjW4BdBFknftqp18adWVlOO1rUL37 rKVoUQsSQTkrON1ryG2eCncR/llBSExZGy4Ng3h3uksuVMnBRkGDk2yYcaRdGYI1eOvt Zqow== X-Gm-Message-State: ACrzQf3gGyUZggd6uFR3d85z2OA0ZP944TZZBoWwWkItwqXsrboQYbX5 vkoUTMYMVNFDtu5YETkOsJ8= X-Google-Smtp-Source: AMsMyM5oWCnczOC9pd+APPKnVoSdgzLJSw85swLOw+L1vcq5vjQKyzFOZ+5rzoddgMqLj99lTobQzA== X-Received: by 2002:a63:8643:0:b0:46b:2bef:338b with SMTP id x64-20020a638643000000b0046b2bef338bmr15796617pgd.357.1667281614026; Mon, 31 Oct 2022 22:46:54 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id d12-20020a17090ab30c00b00212daa6f41dsm5181490pjr.28.2022.10.31.22.46.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2022 22:46:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH RFC 02/10] mm/hugetlb: Comment huge_pte_offset() for its locking requirements From: Nadav Amit In-Reply-To: <20221030212929.335473-3-peterx@redhat.com> Date: Mon, 31 Oct 2022 22:46:52 -0700 Cc: kernel list , linux-mm@kvack.org, Andrew Morton , James Houghton , Miaohe Lin , David Hildenbrand , Muchun Song , Andrea Arcangeli , Mike Kravetz , Rik van Riel Content-Transfer-Encoding: 7bit Message-Id: References: <20221030212929.335473-1-peterx@redhat.com> <20221030212929.335473-3-peterx@redhat.com> To: Peter Xu X-Mailer: Apple Mail (2.3696.120.41.1.1) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667281615; a=rsa-sha256; cv=none; b=706QyYAk6ukLyNkoyF7FpwrRts0LMiUIn9NL+e6R7jqAIPVu15RQq9ezxE2NkukKk8sGd9 czCYedMYFptjZ3Reruu/GLCpIet838ZtDF8SSPcK46EXtn44yfC89Li5MTcBSPR/x384kE PlnpdVit/OgqcX6NPfP3fxUayQ4qG/w= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NaskUVlq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667281615; 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=M6ipy07kqjTgYjFgwvJ6maNLkyoLrvEhOe6gVx9YFPQ=; b=LSE8Ge/OBQanJIR8QwGy8C/elAenzl1d0W0DnL5RdTnna2+xmTD7AoN1nhsishc5fMliVr Mt1WOQ2zzdDvnzWX6Dy5tnsi2VmNXMIE1Y/q/E0haadZS8oslE3YShEIMTabo/YVmP1t0a AotqAQEaONfS6yj7YN/6wUl5jkOdGQU= X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NaskUVlq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-Stat-Signature: atagawqmdhz47mhmqk4oujox74s95x1t X-Rspamd-Queue-Id: 69BC340005 X-Rspamd-Server: rspam06 X-HE-Tag: 1667281615-510596 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 Oct 30, 2022, at 2:29 PM, Peter Xu wrote: > huge_pte_offset() is potentially a pgtable walker, looking up pte_t* for a > hugetlb address. > > Normally, it's always safe to walk the pgtable as long as we're with the > mmap lock held for either read or write, because that guarantees the > pgtable pages will always be valid during the process. > > But it's not true for hugetlbfs: hugetlbfs has the pmd sharing feature, it > means that even with mmap lock held, the PUD pgtable page can still go away > from under us if pmd unsharing is possible during the walk. > > It's not always the case, e.g.: > > (1) If the mapping is private we're not prone to pmd sharing or > unsharing, so it's okay. > > (2) If we're with the hugetlb vma lock held for either read/write, it's > okay too because pmd unshare cannot happen at all. > > Document all these explicitly for huge_pte_offset(), because it's really > not that obvious. This also tells all the callers on what it needs to > guarantee huge_pte_offset() thread-safety. > > Signed-off-by: Peter Xu > --- > arch/arm64/mm/hugetlbpage.c | 32 ++++++++++++++++++++++++++++++++ Please excuse my ignorant question - is there something specific for arm64 code here? Other archs seem to have similar code, no?