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 946E5C54FC6 for ; Sun, 1 Sep 2024 13:39:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A4168D0049; Sun, 1 Sep 2024 09:39:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 853EB8D002D; Sun, 1 Sep 2024 09:39:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F3B78D0049; Sun, 1 Sep 2024 09:39:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5246F8D002D for ; Sun, 1 Sep 2024 09:39:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C4BF21614D3 for ; Sun, 1 Sep 2024 13:39:37 +0000 (UTC) X-FDA: 82516276794.01.2C8F010 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 91C4F40014 for ; Sun, 1 Sep 2024 13:39:34 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bCCFAGgJ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf11.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725197952; a=rsa-sha256; cv=none; b=IQo8Gk4LEKOmC9dNSnbBsxXTeItFaAVtBKVMfMRgKISe+uvNt7dxlvTvjz17tvmWVis1HY mLYxvBafcr4lIWpbMqF55pKl9fpyFn6uJUJFwtVSPgk35JHKdwCpZeJNnakKnggAUO9584 lugvJmiaCDIgjZ5DRoP9D1Uyadr3HMo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bCCFAGgJ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf11.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725197952; 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=vyGDIwF2j/q+RxX/6PvhOnfgGDLJV1PumKrXufZMqJk=; b=Kl9vOJ7ObfF3Ee9hEeKcZt5dg79UqgqNHV8rIzuqJuhU9ago07UfjPtLbywBiXVe7TOtE3 DVRhvg4sn3sxYl/vO44Dr6OWQ4360PHCyU4OWkOGoN11a0qFrhO7016rlJ1hG2vDrsGikC nX7CVozPHy3MuFoef5cFLxHX2XPW/YE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725197973; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vyGDIwF2j/q+RxX/6PvhOnfgGDLJV1PumKrXufZMqJk=; b=bCCFAGgJEonHNydSWRaQ5ta6GfzE0gTgSc3+sjdoN6GssWFgIO9iDYuWM/EbNmla79l4qx RlXW/mwAhruWM97KmFQlM+p8uG14iSVmikroKNYEVMd7D4oIJAISUdIsYYoRcDjD7sKSbN bh1aXyiILNPbQPFnq9RwdMZXVJeU78M= Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-591-iClz5dCJMFKatjHow_n5tg-1; Sun, 01 Sep 2024 09:39:32 -0400 X-MC-Unique: iClz5dCJMFKatjHow_n5tg-1 Received: by mail-oo1-f70.google.com with SMTP id 006d021491bc7-5dc96240f1dso3501307eaf.0 for ; Sun, 01 Sep 2024 06:39:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725197972; x=1725802772; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vyGDIwF2j/q+RxX/6PvhOnfgGDLJV1PumKrXufZMqJk=; b=lURXH4f4fRyHYuf02MiTxALiOpoyzwrv+V3o2YegfVqUPStZaWAVHUZlzwGYoLIqUP U9lnNxYtwjQUNzhb3cCaipeBo9Kl2nKweEszldX6/WPRGeeibHBw316TY0aqCAzb77EE NydjS9G978BVDaxi7ym63Tu2K5TCGuFZDktG/v2NCx2atY0N/gySTzlM3FSJfQXHAaR9 hvAHcjEvDEKCcPkY8juRASeIRFa1vFcMFE47Lo07RLqsrKYUa67fsKXh8TtIWQyYT6j2 9jRWHKEZ6hQ64016OUG2sPOMPiw/wdBKFXJLG//KAOgqdTn/OBN40F0ziLDWPhyOej2G uC0g== X-Forwarded-Encrypted: i=1; AJvYcCVnjAcrjPqAsQ2sKFGyNfax6vlK4+6Brsn2vSXNrdBywikXO2XsEgLzly/IUXwFj939zx1JJN+u+w==@kvack.org X-Gm-Message-State: AOJu0Yy6y9+WVIrlQliwOKJ8D6i6jvdfyE+e2zpeq3esAZ6CVJKih/dB P0FqWBxY5Z36XUwDnBYivfR2KIFEMk0m14gE6YfNyvw7ibz4V6vgdoTS5sHY9llwqaNcQqQZldm y72Eu32DBCbpT4161D6ka6s4jBZWcpbLYbIkuKMCvnaL45wrh X-Received: by 2002:a05:6358:9385:b0:1b5:a043:8f43 with SMTP id e5c5f4694b2df-1b603a26699mr1468278655d.0.1725197971942; Sun, 01 Sep 2024 06:39:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEDmQzg0ZPiJwjrC5T+Ay+drE71+FKdZDRY3ijuZM6RzcnlHFemGD4aRZKF9+h5bY5YpETJsQ== X-Received: by 2002:a05:6358:9385:b0:1b5:a043:8f43 with SMTP id e5c5f4694b2df-1b603a26699mr1468276255d.0.1725197971407; Sun, 01 Sep 2024 06:39:31 -0700 (PDT) Received: from ?IPV6:2003:cb:c720:6600:be4f:7c7a:2bbd:4720? (p200300cbc7206600be4f7c7a2bbd4720.dip0.t-ipconnect.de. [2003:cb:c720:6600:be4f:7c7a:2bbd:4720]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6c353173c45sm20426886d6.92.2024.09.01.06.39.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Sep 2024 06:39:31 -0700 (PDT) Message-ID: <8c70fc0d-901c-4a57-8bbd-0a7f8d895f7e@redhat.com> Date: Sun, 1 Sep 2024 15:39:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 16/19] mm: Remove follow_pte() To: Yu Zhao , Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Gavin Shan , Catalin Marinas , x86@kernel.org, Ingo Molnar , Andrew Morton , Paolo Bonzini , Dave Hansen , Thomas Gleixner , Alistair Popple , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Sean Christopherson , Oscar Salvador , Jason Gunthorpe , Borislav Petkov , Zi Yan , Axel Rasmussen , Yan Zhao , Will Deacon , Kefeng Wang , Alex Williamson References: <20240826204353.2228736-1-peterx@redhat.com> <20240826204353.2228736-17-peterx@redhat.com> From: David Hildenbrand In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 91C4F40014 X-Rspamd-Server: rspam01 X-Stat-Signature: 9oky7sbgiooidbhzj5rt6ke3c6mza6zu X-HE-Tag: 1725197974-677077 X-HE-Meta: U2FsdGVkX18GTjYrnt86zeZmjpSgZrTcrMCTRgZa7WyddT2IUv++Cu9A5UmrjGURN3oCBHj9C97emVWpAr+JuhLdf83WMEwQVspaOq5R+f+AkA9mEz6MdqgbFxZ2MQ5SQjy26wl8wsQxHhkI6h7TwtTlgnSHmdez6Z91ryauZv9fHxmmZI69998+Vi7Ye7OUQqjqxvBur/CLJr6lSDV2x1/TssNfTX1c+1d2WhI3qAN1iUpYXgzEYZSfFc+0rmDlKpohai/Sus4GnpxL2+pKMzsb7k9ZE3pst4zFxDGl2XTXBXD+in8uTaSLik23zBGTR7BVifhYoLSqCF4LAHso+cNx6cUhczEAUirL9485ZJf1ZVkdLAog4hcQnm6oZ9RzU6PPLialOV8w5ZP31kepbtTO+yK8nzMoFWLk/JkfrKh8lg/lHNAYzXv2/Hz+EBtiEtTJsFGTyJde2+kpc9AIiqDoGno1iTaEwTQJocHAur46UPyxnJMuFc5Sgbiu4R3LODHkHoKsWkeCSObO4/bqAZLiyqor5OL+sN+ZsJ3YWTpwhjJhTJ77EgS3kvZfYea79Glqg+MRjFoc0p7YqZre3Z6wT7kXcu+tPhHh9TV8wSPg7cSMGt+KGdlgg4HUtKkCRJISWYZfrxBwIQhwBYs8AYLTsd9ooEL7kKOuocYlLrhMt/T8lUIZm+8ChtNKIskKGEnUeWJ22YfgZDQ4z9g1DlP3NdEj6OiW/fcJ/MKFTIxsbJwv2QH2RIhPBoEkQeyb9SV4tq013H98z+1jid8pCsQE26I2ZKaoX/R6hPpqVMya//ptV4dbnxDR1L6/47f8GrjjOawiUutmK4WeRagWfAe4l+tBEZ8EQSTDWlHT/ov0/WEUEy5b/4jVm8c4Ttgz8KGZtmR/GC+0rPoGSWlDRVnQmHDRdF+1HAiuaBr1bNs47HvIM0v6nFZwcdclOOpjPkkTIVu8q2WpZ1eHE/1 lehvbA6j nihNml9DV6PkJ7h966JeRl6WN8BRLoXVsBwfqtvr8vtIFL4OjuxlXF8OnVQkQdnFoFXguJOq68uWI2EMjtTFqd0wh+A7zzjZpBSN28mCxh6ClZNUhvCdQ83IPltYgu5m3sedQpaJUxanUBxgVEQFLxBfGwyikyX9kqtgrZaSF9eiyt9qNewjJr2IQEW2rdett+UkTETKMj+vlaVwpx0+pPJhQrvD83L84ZX57V7/x3XpRNjukBCYuswrJtcELgfkLx6sjI6n7q1OcObTnRZD/pWTmRaBF2l+2rL5TWnWVc7YcheliclaJfXXM/q2H5PfRe+gpoaQmz5hju4rc65Dlr+hpTzXQnbEU6VBuoWx+yZrujsgHh/D7PXSE54jU+AE3YtpQ9LOP+Cl66Y6x87ZWOHxv5Sck3yrLsJ29ejhTpfYqDFzXxKSszWThfbI0KYN7hXYIskcB9f/JxdwHeVhOsj9dLWT1V4OyBNFrysYN5BrTNKih8H0DhOuvPmZfHL0xOisW3Q0X5uhCOhCAGSavEbr6eMedzB0Npkxee6+Py+dOyAqzmoMheDNeuT0xZF1d9PUzoEwfMRX8KPM= 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: Am 01.09.24 um 06:33 schrieb Yu Zhao: > On Mon, Aug 26, 2024 at 2:44 PM Peter Xu wrote: >> >> follow_pte() users have been converted to follow_pfnmap*(). Remove the >> API. >> >> Signed-off-by: Peter Xu >> --- >> include/linux/mm.h | 2 -- >> mm/memory.c | 73 ---------------------------------------------- >> 2 files changed, 75 deletions(-) >> >> diff --git a/include/linux/mm.h b/include/linux/mm.h >> index 161d496bfd18..b31d4bdd65ad 100644 >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> @@ -2368,8 +2368,6 @@ void free_pgd_range(struct mmu_gather *tlb, unsigned long addr, >> unsigned long end, unsigned long floor, unsigned long ceiling); >> int >> copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma); >> -int follow_pte(struct vm_area_struct *vma, unsigned long address, >> - pte_t **ptepp, spinlock_t **ptlp); >> int generic_access_phys(struct vm_area_struct *vma, unsigned long addr, >> void *buf, int len, int write); >> >> diff --git a/mm/memory.c b/mm/memory.c >> index b5d07f493d5d..288f81a8698e 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -6100,79 +6100,6 @@ int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address) >> } >> #endif /* __PAGETABLE_PMD_FOLDED */ >> >> -/** >> - * follow_pte - look up PTE at a user virtual address >> - * @vma: the memory mapping >> - * @address: user virtual address >> - * @ptepp: location to store found PTE >> - * @ptlp: location to store the lock for the PTE >> - * >> - * On a successful return, the pointer to the PTE is stored in @ptepp; >> - * the corresponding lock is taken and its location is stored in @ptlp. >> - * >> - * The contents of the PTE are only stable until @ptlp is released using >> - * pte_unmap_unlock(). This function will fail if the PTE is non-present. >> - * Present PTEs may include PTEs that map refcounted pages, such as >> - * anonymous folios in COW mappings. >> - * >> - * Callers must be careful when relying on PTE content after >> - * pte_unmap_unlock(). Especially if the PTE maps a refcounted page, >> - * callers must protect against invalidation with MMU notifiers; otherwise >> - * access to the PFN at a later point in time can trigger use-after-free. >> - * >> - * Only IO mappings and raw PFN mappings are allowed. The mmap semaphore >> - * should be taken for read. >> - * >> - * This function must not be used to modify PTE content. >> - * >> - * Return: zero on success, -ve otherwise. >> - */ >> -int follow_pte(struct vm_area_struct *vma, unsigned long address, >> - pte_t **ptepp, spinlock_t **ptlp) >> -{ >> - struct mm_struct *mm = vma->vm_mm; >> - pgd_t *pgd; >> - p4d_t *p4d; >> - pud_t *pud; >> - pmd_t *pmd; >> - pte_t *ptep; >> - >> - mmap_assert_locked(mm); >> - if (unlikely(address < vma->vm_start || address >= vma->vm_end)) >> - goto out; >> - >> - if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) >> - goto out; >> - >> - pgd = pgd_offset(mm, address); >> - if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd))) >> - goto out; >> - >> - p4d = p4d_offset(pgd, address); >> - if (p4d_none(*p4d) || unlikely(p4d_bad(*p4d))) >> - goto out; >> - >> - pud = pud_offset(p4d, address); >> - if (pud_none(*pud) || unlikely(pud_bad(*pud))) >> - goto out; >> - >> - pmd = pmd_offset(pud, address); >> - VM_BUG_ON(pmd_trans_huge(*pmd)); >> - >> - ptep = pte_offset_map_lock(mm, pmd, address, ptlp); >> - if (!ptep) >> - goto out; >> - if (!pte_present(ptep_get(ptep))) >> - goto unlock; >> - *ptepp = ptep; >> - return 0; >> -unlock: >> - pte_unmap_unlock(ptep, *ptlp); >> -out: >> - return -EINVAL; >> -} >> -EXPORT_SYMBOL_GPL(follow_pte); > > I ran into build errors with this -- removing exported symbols breaks > ABI, so I think we should make follow_pte() as a wrapper of its new > equivalent, if that's possible? Build error with OOT modules or in-tree modules? If you are talking about OOT modules, it is their responsibility to fix this up in their implementation. There are no real kabi stability guarantees provided by the kernel. If you are talking about in-tree modules, did Peter miss some (probably in -next?)? -- Thanks, David / dhildenb