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 1E947C3DA4A for ; Fri, 26 Jul 2024 21:28:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 770856B0083; Fri, 26 Jul 2024 17:28:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 720406B0089; Fri, 26 Jul 2024 17:28:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C0346B008A; Fri, 26 Jul 2024 17:28:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3EB366B0083 for ; Fri, 26 Jul 2024 17:28:56 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E17EE140156 for ; Fri, 26 Jul 2024 21:28:55 +0000 (UTC) X-FDA: 82383193830.16.04BBE6A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf12.hostedemail.com (Postfix) with ESMTP id C686640015 for ; Fri, 26 Jul 2024 21:28:53 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=M4FfBEvg; spf=pass (imf12.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722029294; 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=Lq8fcYg7vmbu2tY0cVnCTlYYMnfwT6dNzxghIL6A57Y=; b=SblsRJF7NNGoHT0u0lDUSIN8M+PYc/+ua5aW72Eo8KeBJt/ACVs0anltxtJCnnW8Np37oB kKvmpIHraNG/vPhglC3954iRzPCOF8KBTmEpcsg+1iAyXX8ahiq+qGzvTUeMyZ4T6G182+ kYe9eZBZ/poZpv/XmsmQNCDqTOyXkhY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=M4FfBEvg; spf=pass (imf12.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722029294; a=rsa-sha256; cv=none; b=EL1jb2FPqh57QNsmF7LH+rdACE9pTt4YIZ3Pd52ZW44AFX2iNVVi5g9qAvtrF2NDRtEhE4 QcKInLd6dXh9Vve6o+n8ZtBTHBOedANxVPGngkRJXb0o55pXLOZH6uJuLAYft1HXga77QM 04RmRA75AT5iG5EGA6hbI8ymTlpMrXU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722029333; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lq8fcYg7vmbu2tY0cVnCTlYYMnfwT6dNzxghIL6A57Y=; b=M4FfBEvgdRCwMF5Im/zHaxS5tP6DcSdr9qpN+/O1PnRMlg3T4owibzy2KsnR+Tg32Xy9fe +iC/ZCGGQgZehMvO7F76w4uQW7pkSwA5YK3mvUVO/O+2K+4uvikIQliBlen0KdUlPerpPV 8cpcXat/DjcYn+3ojUXrBmr49fk6pGE= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-48-cccImyG8NLiTU8tzNyzUnw-1; Fri, 26 Jul 2024 17:28:51 -0400 X-MC-Unique: cccImyG8NLiTU8tzNyzUnw-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-44ff25bbfe1so832481cf.3 for ; Fri, 26 Jul 2024 14:28:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722029331; x=1722634131; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Lq8fcYg7vmbu2tY0cVnCTlYYMnfwT6dNzxghIL6A57Y=; b=ncFpVs2Ti9Cbf3Rzy/Dzhbe5l7xhx/kSRijLt4/No3Keqz8WzHXEkeWUXGdRvne7iq CrJhUqgaTD8hAeMNxy7OJkh8vtaGgdvFeHhX4Sl7hoc1qSGy4sQAGn+Fim2freRduoXc LE88JVL4OrKywK8Gw42olHJDPxbF7hZvhv97nV3p0SmaQfdRyft1+CJw8Hh/zT569aMF G5Pm5Zm0/qN1ut+13zKTA0WTkK3c9+Bk5Iqf5b4A1H3mvsGOe4hxawP3WgazdfVuflYT 2OV/4hFKJjODtnBtkTSe6JIEWD+7xA55SXFaq0y8fuWpiKrdUXEapq1fLIl20wDbca31 uHbg== X-Forwarded-Encrypted: i=1; AJvYcCVzcb3YglDkQ+aAniFBDD1YUji9Le/iW10rR0B0gFVbf5ILANZ6NZd8QaARvwa30CJzeXD+kNNupw==@kvack.org X-Gm-Message-State: AOJu0YxK7Cou5/4/sYsxChBGhxOY+zW0uPaV+IDgDUrT0I116grMQtgW 4rGXoXGsTKy1G1bUh2HJJDerQP19N/Cl98i1lL/oq9zNS9vM/5naLszvZ7XWgR9Y3hRAnNLG2dx iIXGfvVIO5xN0zoEzBlk8vNKvGCPPH3fXvavtuFDOW8WtHd6E X-Received: by 2002:a05:620a:1a9f:b0:79e:fc9c:4bc2 with SMTP id af79cd13be357-7a1d690cf22mr524520185a.4.1722029330777; Fri, 26 Jul 2024 14:28:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFyiXPUaaUBgyOseIoBqy+vK4d5h7x2HpItD5MjFagg5KiFr43MKWqy7glmFCF3oJgLIGdk3A== X-Received: by 2002:a05:620a:1a9f:b0:79e:fc9c:4bc2 with SMTP id af79cd13be357-7a1d690cf22mr524518985a.4.1722029330388; Fri, 26 Jul 2024 14:28:50 -0700 (PDT) Received: from x1n (pool-99-254-121-117.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-44fe840cd64sm16520281cf.81.2024.07.26.14.28.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jul 2024 14:28:49 -0700 (PDT) Date: Fri, 26 Jul 2024 17:28:47 -0400 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Muchun Song , Oscar Salvador Subject: Re: [PATCH v1 1/2] mm: let pte_lockptr() consume a pte_t pointer Message-ID: References: <20240725183955.2268884-1-david@redhat.com> <20240725183955.2268884-2-david@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Stat-Signature: nhqfzrxmd4fgda7imda3ao5yiiwcnr3u X-Rspam-User: X-Rspamd-Queue-Id: C686640015 X-Rspamd-Server: rspam02 X-HE-Tag: 1722029333-442863 X-HE-Meta: U2FsdGVkX18128odnAh781S67wk1BDIYV54a4Z0HnPAaA/jJe0Y53c5tB7/O+VFEMyic5jbad9ZK+uf0Od3O7K/Y5Bor6Ne9kIZ/nJj2XPAyjO/swFn7LL/DSH6I+zUBedM5KsuMhShK4C/SFkpxnFvhm1ugZZ+APfl+v6Um+7Mge9smuWA6tG9x/uCBALX6WJFhGiK6tUyEQhOewM37CD03KvQhE8m8aAUsLZ8xuD3U3Bn4UebSwDxaUQaMWupm+vMfsOfXTi9pT8pw/bgdW2q86ULIg8Rc28G4wi8+x/3KrofzyajbyRD8pEoKkOvmkpgM20f4vuWU7dYkWsQUV6h5CY3+K/hdsZ50synHzbU/i5HlyVM8+m8lANlCAoohWIVEJ3JoDnMiYU9nhl/hbXF4QZP5dCy8gkkqRH+3oAygYkUm0a0F7uDdY18k6D/iyDbojDi8m1u9QFxWuW4Cu2FKsjgbi1S9saRK7jnNgXDo7KfT2P1E86usdFwOyH/K2WBWHjikCmaPIRKIaIFcBFII6G++kpPTTqPrY0EN/ae1DvJ1yYut6N705pX8B2rb5JKXcAFk4ImG4SpyrUgvOpoe6dpWAGao/8E53OBQgIyvt+Q+WZPgm6pENNMUwKGbCC9AMyAZPL0yKH4LjM61dqGCy3F/9+XgxGyrGoN+ZZ7fTV0lkxBl2ccP3AZWG9sXFHcTToGrXUdrLnvmHK6o1ZPjJPt6hoLiXMuI/igNMJzD3j/Q5wNgZLzYhKS8RRxn87WfyLgSK1abgc+8yv17GWPgePpjsweIkAOoESkIJlmBrGX5TgbQxJ4NKn6Ha1QK1Ak6DGL2aq7v0r1QJUl9xX7vRAAtn5U5iBVadTe3V04RPJwylg6NgqYEsZPO4tC5S/w/18MUdiI9mExTyJR4/sxnYufNiLOQeKwNgqwtGMdHGijgHrFbIo519LmUOghEfMzhSFRJ5n998Uhp8FN UxovxfqH gZaj0vFP6HYzsqGz7LzUW5jM/xUoujNehHWrzWgsw1GbTrEfDlO6oc4nGH8k9NEvHo+Nz2a4DOhKvQ9pw8dgIzqcKF353gtmehFc0yzVLXImdXm31yzIVdYiNWGUO879DPtULldUNlZeYlBmyrWqXbVpUe4BVhdky/c/191gOSE5vNNU5tVhrWcx4eA1JezNJHrgzDQffHBVvk0fT5NAdPs6FvBlZdLTT9Vs3v5NxjxSI8UFJH/THRYY/39CTxUuFc7olQ0RJRnJPVkHUDm593mwcGSSGUva8Qt/W0nuwcFUpdeVf1C3ZWhJUv0UjpBKa2Rv117OJyFSAofB3Yd0OGIAIF4akMrMTweB4W/0fslec8h8K7mrooXLAC/HkEK+Ty2IzZTb08Ib3M04wEXwd/6njPaas5LpCyMg9mztm76b8SzsiZaclKMBns+umbP4+tNehYUHL0x+ZeiCs3o9SbZDcfNorUPbtClSx6XBdlGqkgxAzyDuC8mznKcowIfLaUPG6QFiz9O9dY0g= 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 Fri, Jul 26, 2024 at 06:02:17PM +0200, David Hildenbrand wrote: > On 26.07.24 17:36, Peter Xu wrote: > > On Thu, Jul 25, 2024 at 08:39:54PM +0200, David Hildenbrand wrote: > > > pte_lockptr() is the only *_lockptr() function that doesn't consume > > > what would be expected: it consumes a pmd_t pointer instead of a pte_t > > > pointer. > > > > > > Let's change that. The two callers in pgtable-generic.c are easily > > > adjusted. Adjust khugepaged.c:retract_page_tables() to simply do a > > > pte_offset_map_nolock() to obtain the lock, even though we won't actually > > > be traversing the page table. > > > > > > This makes the code more similar to the other variants and avoids other > > > hacks to make the new pte_lockptr() version happy. pte_lockptr() users > > > reside now only in pgtable-generic.c. > > > > > > Maybe, using pte_offset_map_nolock() is the right thing to do because > > > the PTE table could have been removed in the meantime? At least it sounds > > > more future proof if we ever have other means of page table reclaim. > > > > I think it can't change, because anyone who wants to race against this > > should try to take the pmd lock first (which was held already)? > > That doesn't explain why it is safe for us to assume that after we took the > PMD lock that the PMD actually still points at a completely empty page > table. Likely it currently works by accident, because we only have a single > such user that makes this assumption. It might certainly be a different once > we asynchronously reclaim page tables. I think it's safe because find_pmd_or_thp_or_none() returned SUCCEED, and we're holding i_mmap lock for read. I don't see any way that this pmd can become a non-pgtable-page. I meant, AFAIU tearing down pgtable in whatever sane way will need to at least take both mmap write lock and i_mmap write lock (in this case, a file mapping), no? > > But yes, the PMD cannot get modified while we hold the PMD lock, otherwise > we'd be in trouble > > > > > I wonder an open coded "ptlock_ptr(page_ptdesc(pmd_page(*pmd)))" would be > > nicer here, but only if my understanding is correct. > > I really don't like open-coding that. Fortunately we were able to limit the > use of ptlock_ptr to a single user outside of arch/x86/xen/mmu_pv.c so far. I'm fine if you prefer like that; I don't see it a huge deal to me. Thanks, -- Peter Xu