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 969D7C54EE9 for ; Thu, 8 Sep 2022 17:54:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D72DF6B0072; Thu, 8 Sep 2022 13:54:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D22326B0073; Thu, 8 Sep 2022 13:54:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BEA388D0001; Thu, 8 Sep 2022 13:54:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A135B6B0072 for ; Thu, 8 Sep 2022 13:54:50 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6A22B1A0B32 for ; Thu, 8 Sep 2022 17:54:50 +0000 (UTC) X-FDA: 79889668740.23.D160654 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf11.hostedemail.com (Postfix) with ESMTP id 1AA6240076 for ; Thu, 8 Sep 2022 17:54:49 +0000 (UTC) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-348b1838c2bso18853497b3.3 for ; Thu, 08 Sep 2022 10:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=4o6pEGvC0xR1WYCpAN/WgF7OkvsbjOlTp/AoxTDmWXU=; b=MoqgM7jyFVT39XmQ2SFHCSX5yFBGlrr6am1GQA+mo3OH3ZfqZJ0X2qIYszdvXX50bh oRtOzmvY0g9j67TavgJWauoVX88NWkSRVbmNaED64NML/RMlVtggHX466sFYVWRdyGzy xBvrKC60nBUE78KNd5CqrmtjS18ycsR5mWoCiuiHS77pWfU5z160zeGXUM9nAZ1cXyqz 5KiRD1U+/uREhHhVxLO2kCi9T+MdbGZcdqiTb0wE9/5NvWF5cU82QMcZRtu50Vf+H/gC BMNY4l1gP/OIqU4CY3zaz/789iSGF9/yuISlNQ2Bf8vQ7QXt7MW2hvUcorwffvEYMRhz bqhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=4o6pEGvC0xR1WYCpAN/WgF7OkvsbjOlTp/AoxTDmWXU=; b=wW5zEQfpElues2MpjweDsQNFaSdE6hZE564SnSr4Cg1/LuOMnPst4QRkcjbOWcZlOK gfrAGTG0ObLwEZ4XomBotBSOy4cCKuNxWp/Vt9enU+4/ggQLaFtbXcE/4+FOhqyHH9KH TTvrjIQcLPom8YRF9jeJxwDnC91dFSaXB3QUJuWaVe8R30Ptaaaw1Dvdub26adkhlIeS zszjJNdd6Og+7oS1XSMrmt5BNDaatPk9Xh0TXZE96fwfQrNx+Gkgi7B/UXJ9qcy5GUsw lw9mm9j7UR0y2PxGUYwFZ3xxqBZyVvJpB8RiLrm5ZtfJvS9ti4smHkp3H370hnFEICUE Uy1g== X-Gm-Message-State: ACgBeo33l/7kVlI05weKSQXNVe+VctCJpDFKZXoaTnM+9Nxt1E+8VBMK EzVFcA/SPZ/8jH/W6GhMsuh5YIrBeZ8c6Hsr8Hze6w== X-Google-Smtp-Source: AA6agR64MqWStEy43/wInEWWHQqJckl2u3w2fnpuKGZdtvM772eO0H6J4oJPu9XUFZhQcbsuxiooxwVtHUPCgyJqgbE= X-Received: by 2002:a81:5790:0:b0:348:9584:bf4b with SMTP id l138-20020a815790000000b003489584bf4bmr3154763ywb.483.1662659689250; Thu, 08 Sep 2022 10:54:49 -0700 (PDT) MIME-Version: 1.0 References: <20220624173656.2033256-1-jthoughton@google.com> <20220624173656.2033256-8-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Thu, 8 Sep 2022 10:54:37 -0700 Message-ID: Subject: Re: [RFC PATCH 07/26] hugetlb: add hugetlb_pte to track HugeTLB page table entries To: Peter Xu Cc: Mike Kravetz , Muchun Song , David Hildenbrand , David Rientjes , Axel Rasmussen , Mina Almasry , Jue Wang , Manish Mishra , "Dr . David Alan Gilbert" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662659690; a=rsa-sha256; cv=none; b=1KlRDvlNVl5O3ovYoM4y/3uzMYTTKR+KVP5kRmxg9apivvFWerycFCof2qMouyW5Trxb0F lT18m5kM4uDOFlU35eQQSwRbzhs+kiC1b9O3shvFIP1Gbi2kHBfgKkKG0aS/HC9MkSkm5b dx6bku1VxzIKdJBSiToSpKxctltHyeE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MoqgM7jy; spf=pass (imf11.hostedemail.com: domain of jthoughton@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662659690; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4o6pEGvC0xR1WYCpAN/WgF7OkvsbjOlTp/AoxTDmWXU=; b=Zj2OtHCKbpP1RM0UN1tBydlhhlz7dDzpow/spFzflGiwDpgwlFMiSmjPccruupq24D5Xaj 4aCbVzbMF0ToaMv9LgxVCmYpsTb/yhYdgfQwbZXd7xgX4Sshuw3MQ2cocg5M2Uz+EvQII5 NfUcevpmfrlH48iuMjESx2bcOZ919ck= X-Stat-Signature: rcio3u5u37zmyomy9bfk6gq68j9o4m86 X-Rspamd-Queue-Id: 1AA6240076 X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MoqgM7jy; spf=pass (imf11.hostedemail.com: domain of jthoughton@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1662659689-8345 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 Thu, Sep 8, 2022 at 10:38 AM Peter Xu wrote: > > James, > > On Fri, Jun 24, 2022 at 05:36:37PM +0000, James Houghton wrote: > > +static inline > > +spinlock_t *hugetlb_pte_lockptr(struct mm_struct *mm, struct hugetlb_pte *hpte) > > +{ > > + > > + BUG_ON(!hpte->ptep); > > + // Only use huge_pte_lockptr if we are at leaf-level. Otherwise use > > + // the regular page table lock. > > + if (hugetlb_pte_none(hpte) || hugetlb_pte_present_leaf(hpte)) > > + return huge_pte_lockptr(hugetlb_pte_shift(hpte), > > + mm, hpte->ptep); > > + return &mm->page_table_lock; > > +} > > Today when I re-read part of this thread, I found that I'm not sure whether > this is safe. IIUC taking different locks depending on the state of pte > may lead to issues. > > For example, could below race happen where two threads can be taking > different locks even if stumbled over the same pmd entry? > > thread 1 thread 2 > -------- -------- > > hugetlb_pte_lockptr (for pmd level) > pte_none()==true, > take pmd lock > pmd_alloc() > hugetlb_pte_lockptr (for pmd level) > pte is pgtable entry (so !none, !present_leaf) > take page_table_lock > (can run concurrently with thread 1...) > pte_alloc() > ... Thanks for pointing out this race. Yes, it is wrong to change which lock we take depending on the value of the PTE, as we would need to lock the PTE first to correctly make the decision. This has already been fixed in the next version of this series :). That is, we choose which lock to grab based on the PTE's page table level. - James > > -- > Peter Xu >