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 05D5EC3DA7F for ; Tue, 30 Jul 2024 21:18:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FE7C6B0082; Tue, 30 Jul 2024 17:18:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8ADD36B0096; Tue, 30 Jul 2024 17:18:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74F0E6B0098; Tue, 30 Jul 2024 17:18:02 -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 57D426B0096 for ; Tue, 30 Jul 2024 17:18:02 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EADF31204EA for ; Tue, 30 Jul 2024 21:18:01 +0000 (UTC) X-FDA: 82397681562.08.76BF28A Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf11.hostedemail.com (Postfix) with ESMTP id 3264E40008 for ; Tue, 30 Jul 2024 21:18:00 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pbQCMPD6; spf=pass (imf11.hostedemail.com: domain of jthoughton@google.com designates 209.85.160.180 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=1722374275; 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=GQzlvmVa30s7/0Cvf/ONz0CiTkA5Kxf3WVqHHnXgoEc=; b=UWwvsLn/+WNpjjY3yc9UfwUqMuSgDgtznOVnqupTjeOfaelqYY6Rx51vQpKy1Yv3J/n2Lq w87KrEMEABvpKSovpgp3rDOnXNiCfGKZesqwZ/Y6y5vKAvr8QDVkEi2VMil9NoTxHY/6Fk W8mTFUlMPVlJgOYVoCNaN7IFuu8J9Wc= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pbQCMPD6; spf=pass (imf11.hostedemail.com: domain of jthoughton@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722374275; a=rsa-sha256; cv=none; b=MkFNZ4GX2oUGLh4LoZe0NeSZD6SyDCTEImvZ6gDtcJgNAfAMwzj0JE1RmtLnvcPjLICfPG r5pemz74QZ/hImvOz5/2nYaQGFJqgJe7XyPGWdkXzRbEN4XinjafkVJNpCOLFOLz8oM6aN m0hVCPzn0yEQ3bqRmHZyA4/i3OGLLvQ= Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-44fe76fa0b8so89201cf.0 for ; Tue, 30 Jul 2024 14:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722374279; x=1722979079; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GQzlvmVa30s7/0Cvf/ONz0CiTkA5Kxf3WVqHHnXgoEc=; b=pbQCMPD6bgi0ArWv+xe/zuRwMZDpO45Ebrp+inoI+TY2VH42oqTEDgD8/GaW7l+gkJ oYbC0qS/SR7i/dhwrIVK1FqakL6uT1DYEq/ReOeNO+IrTfu4rQzttbrOULrUICp4u/Az 3ti6w8HYnZquQfhnlVUm3SOoQJmT3YLoQu0ToiFWh3K3Ppl7siZR++v2LKUwFxsmh1mH WCQsjnG/Ke91VewJv/AS7g/kml/c8NMQ15no8BgsixEiU786+FPoujQXHyQA9GI8LGSU pFLIpHHVHmLKT6Exy2KimsWQGxVNlVbpIMYjKRSemX38vU+7kfG/5KJDSQOeyVWAjznS Sy0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722374279; x=1722979079; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GQzlvmVa30s7/0Cvf/ONz0CiTkA5Kxf3WVqHHnXgoEc=; b=E3cawpRNkZK23ro1Do9c3p9PklqmA51TeClCeawW2A8QskqAonQ6TozfCbeTmtGC0B r75tGAw+OKHl+ya/yGbCnhf5ne4YnzE1dWn3YP1cH1P6tdQ8SmtkKdW1MTaVtoAKxQmb rezLZw8su4F+5cCD12vDxLWCqNNRYXKrOkCtDlv7x8hmDMxpTY3am833Mop7kWJOE1NQ cSjj7ShcPRcSoQsy4XAziEGd0ruIBSjoSXKFtBQ/TJte/cunfQ+x9oYr8fs3CzNBLH5V WWs3pk/utpWgxXzkWvpSlms7eLzzxH5d0fAiRjUCVfyNu5aLNRX0H85yEKSA8sVez2tr 7R3g== X-Forwarded-Encrypted: i=1; AJvYcCVmCTKX8v71CaCufTV/SxpzwiXCHt4h43jNnTRjKH9WaPi0nFMs2PMj9YHyfwYv/lHPKeFaB/UJfDLBaLwydTKRZLA= X-Gm-Message-State: AOJu0YxySw8wcDjwMKoFs9D0/VmgGbWKiPg+AOTe/MjNmWJ7iFL9Lz0o rhGxeG9oWg6mR8r0aX/AgKRQRmviDw7ZKz4i/B1eGA487GOUe3UQ1VI4wlbdolksp6J8AH1OzDy J1ofsbn2tGUaoe5lXkeSFV1/YdbVG4QKNA4BR X-Google-Smtp-Source: AGHT+IGeKl2MOsrgbgEMzNO2zod+Gnz547WZLav1AuvB9pAYXBjlGRyP+IPA8eSDlgyvuFGiez+ewEJrRBnpTpkL6V4= X-Received: by 2002:a05:622a:410:b0:447:d555:7035 with SMTP id d75a77b69052e-4504314cf01mr166851cf.13.1722374279116; Tue, 30 Jul 2024 14:17:59 -0700 (PDT) MIME-Version: 1.0 References: <20240730200341.1642904-1-david@redhat.com> <3f6c97b5-ccd8-4226-a9ac-78d555b0d048@redhat.com> In-Reply-To: From: James Houghton Date: Tue, 30 Jul 2024 14:17:22 -0700 Message-ID: Subject: Re: [PATCH v2] mm/hugetlb: fix hugetlb vs. core-mm PT locking To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, Peter Xu , Oscar Salvador , Muchun Song , Baolin Wang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: aht1o8my314oaryzchtrtiuix6gjjidm X-Rspamd-Queue-Id: 3264E40008 X-Rspamd-Server: rspam11 X-HE-Tag: 1722374280-433435 X-HE-Meta: U2FsdGVkX1/2bDNtnt5Bf3mcB4SzsBA60CcmH39tbHAsSwVEMw4GZWnQ7m4bSW4WB4sxuryIaVqeJn+uBgcxOKGrV/FNTNNzY363LFyRjc4YVpQJvTn3dBr3FAZqnv/i+tgOSAAix4RIeuD1oW1Rdq4S9UjdH6+rVubwD3pcGHIMre3mnf17gvMfm17kd4txv0O/R0GQLF7TOPXMDMZaLk4UPztZjZr3SJbBswtLxhu3oSLpfvFrZnn/uJPAsDbgHvdPUDgyEuztFW5pqMrS5aaZz+BtbNfVYns4BzBB5ISRUE3QjprraBHp7XQo99NQYkQDN062SqOH60r/eJ0kf1mDJSS9GDQYbMK+g6Nb2J2MJ2ta3HJDUw4KnkDLguAVWBfbaA3tk6htuNY/qjKnZVR6Xw8mdCJ2SFC908f2IZ81J/g1xMxurLT/0yclgMa4kmRoMwdYTdv1p+UD58QsIaCS400MV50L9zTL2rn3RYhwi7633BMTHbrvLzrXXELZ+/mZYFi1dOKdY9Lylnex/rHJauld4pxMTH+3oyPrB7MISkiz7mSFmI6u+jqmdzUEr1KFQwRLHZ+43pQ5C5s+clc3Y9RKltAPkm3MpaWKe9vHhLASJlESRbkOSdQfE//p//UWZtCGpJPceCiuU8VKN4ARzE023FYy5PD+WAzfOeJsNgTRncaHdxCIEYtT2C6dLlQZyFN174lIYrdh+ryjCNdG1hBUH1xjYhzGn1RYyjdE8v1hkEhy3NgKYwBmU4sGxFypNIJUepep5essd5nznct68P8u39ClwQYLBeGrqAZ1PeMHEOiQtfU6G/GAiu/jpBPwanp5WnuQOkHmgjLAcEQ1tfiSDbZQf+of53mEdYCUPAydGQBQcz1pIAdSlAcLNYG9dm5XbojHbIGLzgXH0M2n8q03Jq+j0XdQMCVtNGGWX2fvRlVBaE9ueAT6/X+fexfLfR8rA4q8BQaMpL1 viK2Cslg IBMu/kkY7rExtYVXcP1hACdXGFccM/LRpE3GZ8kz2OvOSq7szB6g+gI5fOoPx+2tA96FaTepIsD9QR6v9yCwIfhEBFgRvRZxxliU+j+MzbuXIROMriWSFpWOJs5rCvoIJERtrTOSpNb4FhmKFAL2sn8IRG1pfDbQ9g01HtZZanQpw5+WB7kIMAYCwUPkckJAfRurCrCU8WYqd3gFPFkgkK9dErw== 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 Tue, Jul 30, 2024 at 2:07=E2=80=AFPM David Hildenbrand wrote: > > On 30.07.24 23:00, David Hildenbrand wrote: > > On 30.07.24 22:43, James Houghton wrote: > >> On Tue, Jul 30, 2024 at 1:03=E2=80=AFPM David Hildenbrand wrote: > >>> diff --git a/include/linux/mm.h b/include/linux/mm.h > >>> index b100df8cb5857..1b1f40ff00b7d 100644 > >>> --- a/include/linux/mm.h > >>> +++ b/include/linux/mm.h > >>> @@ -2926,6 +2926,12 @@ static inline spinlock_t *pte_lockptr(struct m= m_struct *mm, pmd_t *pmd) > >>> return ptlock_ptr(page_ptdesc(pmd_page(*pmd))); > >>> } > >>> > >>> +static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *= pte) > >>> +{ > >>> + BUILD_BUG_ON(IS_ENABLED(CONFIG_HIGHPTE)); > >>> + return ptlock_ptr(virt_to_ptdesc(pte)); > >> > >> Hi David, > >> > > > > Hi! > > > >> Small question: ptep_lockptr() does not handle the case where the size > >> of the PTE table is larger than PAGE_SIZE, but pmd_lockptr() does. > > > > I thought I convinced myself that leaf page tables are always single > > pages and had a comment in v1. > > > > But now I have to double-check again, and staring at > > pagetable_pte_ctor() callers I am left confused. > > > > It certainly sounds more future proof to just align the pointer down to > > the start of the PTE table like pmd_lockptr() would. > > > >> IIUC, for pte_lockptr() and ptep_lockptr() to return the same result > >> in this case, ptep_lockptr() should be doing the masking that > >> pmd_lockptr() is doing. Are you sure that you don't need to be doing > >> it? (Or maybe I am misunderstanding something.) > > > > It's a valid concern even if it would not be required. But I'm afraid I > > won't dig into the details and simply do the alignment in a v3. > > To be precise, the following on top: > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 1b1f40ff00b7d..f6c7fe8f5746f 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2926,10 +2926,22 @@ static inline spinlock_t *pte_lockptr(struct mm_s= truct *mm, pmd_t *pmd) > return ptlock_ptr(page_ptdesc(pmd_page(*pmd))); > } > > -static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte) > +static inline struct page *ptep_pgtable_page(pte_t *pte) > { > + unsigned long mask =3D ~(PTRS_PER_PTE * sizeof(pte_t) - 1); > + > BUILD_BUG_ON(IS_ENABLED(CONFIG_HIGHPTE)); > - return ptlock_ptr(virt_to_ptdesc(pte)); > + return virt_to_page((void *)((unsigned long)pte & mask)); > +} > + > +static inline struct ptdesc *ptep_ptdesc(pte_t *pte) > +{ > + return page_ptdesc(ptep_pgtable_page(pte)); > +} > + > +static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte) > +{ > + return ptlock_ptr(ptep_ptdesc(pte)); > } Thanks! That looks right to me. Feel free to add Reviewed-by: James Houghton > > > virt_to_ptdesc() really is of limited use in core-mm code as it seems ... > > -- > Cheers, > > David / dhildenb >