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 799DAC3ABAC for ; Tue, 6 May 2025 11:52:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AFD496B000A; Tue, 6 May 2025 07:52:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AAC516B0082; Tue, 6 May 2025 07:52:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 974CF6B0085; Tue, 6 May 2025 07:52:54 -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 7AA7F6B000A for ; Tue, 6 May 2025 07:52:54 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 361FEC017D for ; Tue, 6 May 2025 11:52:56 +0000 (UTC) X-FDA: 83412321552.26.001F120 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf22.hostedemail.com (Postfix) with ESMTP id 1B4BEC000E for ; Tue, 6 May 2025 11:52:53 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf22.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746532374; a=rsa-sha256; cv=none; b=C1sWoqJcUETaRvSryP143laHsUpg6KUTXgPXqPnDBWb/NRfimgS8lCNEWnXoyEvJvi8tvb KB3F1Dg+e4hZuhA04OnMqGfa/qodsDWJgVfSDvsop4lz23LZImtxAzm0p3y9HMeJiPYltz 9notvU7Q+9AboFAYTd2sGpI+BGXeZNU= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf22.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746532374; 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; bh=MqiU3xnGagwiTvU9GGNNwhuRygRP1u1w9+oqzqV6Oyw=; b=BasMgJOuswY6Y3Y91OmqRigpM94mhjVV1yPZRBnqA87JH4Vzozaw/HGheTxyiEanXpARsC /vwadWUeO4aFnVR5EJ0aaWT2Uoji+ALHoost8QsB8OQiCAD0XYspgAg3fZRgPHGVfvB7A1 VfTLtDI96QI0RO0z0aytUu0Z1TEpzlM= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 512CF113E; Tue, 6 May 2025 04:52:43 -0700 (PDT) Received: from [10.163.80.199] (unknown [10.163.80.199]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A5A223F58B; Tue, 6 May 2025 04:52:42 -0700 (PDT) Message-ID: <060ce34c-6729-4128-9190-264f7684e299@arm.com> Date: Tue, 6 May 2025 17:22:39 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] mm: Call pointers to ptes as ptep To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, vbabka@suse.cz, jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@redhat.com, peterx@redhat.com, ryan.roberts@arm.com, mingo@kernel.org, libang.li@antgroup.com, maobibo@loongson.cn, zhengqi.arch@bytedance.com, baohua@kernel.org, anshuman.khandual@arm.com, willy@infradead.org, ioworker0@gmail.com, yang@os.amperecomputing.com References: <20250506050056.59250-1-dev.jain@arm.com> <20250506050056.59250-2-dev.jain@arm.com> <5c20ada8-4863-4a33-bb1d-3b5695d0bf66@lucifer.local> Content-Language: en-US From: Dev Jain In-Reply-To: <5c20ada8-4863-4a33-bb1d-3b5695d0bf66@lucifer.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1B4BEC000E X-Stat-Signature: fo6j4b86t3ky9fyu8or4bkbkrjmykojk X-HE-Tag: 1746532373-330667 X-HE-Meta: U2FsdGVkX1/KeZplPSsc3wX+1cuE39XPPbVn6S44xwXgMxIXnAHNhrE0UlUDc8XPccYQ//ENdKEdM6CuO+gBJXFbSFa3H3Oa2xFNKzCvlX3t9GHgFR7TA+k7zgmDOEKxjc/c1iTciRQyX97W0scZk7E0jGzTljmladqglOyhW8hU+kh5MzDPKLrKYrG6atDSBA64hcftN7xPaWADNwwS1cyj7DcJc6e2E6lmm5RGu6c5KtDIZOKD4Bkt08CWLme38/bharfdYut+en/a6eQo4T44KSW0NHlTiFVug+0I5VizjaPiVxfBAjfEnxQ0mbyDUUqbSh6WfWJBhlX89TWYvmx2J+1VXlg7agTBHC2f0jGcazbWwiyeNA5E9laN5wRsNCdVcH8bTVxRBlV1Sdyl20YkQPSgwFluHAGqintdP5H5bC7UNW2+4mKdxGoG2NBBDrYMpWRzn11fIB/UOSdaRpzFc1WoKAZtMHorpONLFNJzCQrXSgzEskdcshbe+GVzfE80BbdERMU5WzI9X2ZcVOeQYn99325Qbfy3rzaXPicDCWicBOKRMrDQ9gg1sd8z7eLODA4FUjyqRi9Nvd7d6xjwc6FKLn8M7tvM+t/2ZbQaUkpT0GOW9d9uq/EvsMKZ5eE9j0N7QKALv+6uVJZaLX/eC1FzI7vOGnR2DBSgsFgMrnpPTlSH2rQCNtg/uAuxkne4HTgmHRVzdStTQ4ChUX9Hx4gR1LIjeKSPGGF/TeneqtDns9ashxEHuMC1b3GlPqls+fGwJ5Gyh3ngL5olT+UHRfG4j9Od1yhGxrkSlZ7ohGEdGsyjyO24Xc1++EQEBpFMauq+92HPv27jxEEu7X+nXDFLjQuYGcA9/372jyy55+eNUrtMjfmo22gy77VdFJatr36EuKdk8AcBWEAh+YLo7iO5rPGv+cHKOqdTFSq5G3HT3Qjg3cvXK671Pr6ITfzfqILAy3zqa4Ok79m FWu2iBQq I4trJGusrHnWrp0/kEAc/twR0VDcRApptm96NRS82fMg5jxn8KWSa/uk94ebCB/089/a+MUDP7MC9O1OrO/vgqGC4rafZCSd6pmhd+LeCvkvkOfsjvgP15pgZKxhnAHRWXPdQq+8xhnYAOZsArzqnUiiZUOW87+AoBmCsk9R848ddxnB0bIEyYzPdKh92o8ze7jXs6KlOUEU+7k+TkHv9KQEceuXb48NrhFfsaU2/Sj5pChvcu9iHkSGakA== 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 06/05/25 4:22 pm, Lorenzo Stoakes wrote: > On Tue, May 06, 2025 at 10:30:54AM +0530, Dev Jain wrote: >> Avoid confusion between pte_t* and pte_t data types by appending pointer >> type variables by p. No functional change. > > NIT: 'appending'->'suffixing' and 'by p' -> with p'. Thanks. > >> >> Signed-off-by: Dev Jain > > This looks generally fine, could you fix the nit below however... sorry to > be a pain! > > Thanks! > >> --- >> mm/mremap.c | 28 ++++++++++++++-------------- >> 1 file changed, 14 insertions(+), 14 deletions(-) >> >> diff --git a/mm/mremap.c b/mm/mremap.c >> index 7db9da609c84..1a08a7c3b92f 100644 >> --- a/mm/mremap.c >> +++ b/mm/mremap.c >> @@ -176,7 +176,7 @@ static int move_ptes(struct pagetable_move_control *pmc, >> struct vm_area_struct *vma = pmc->old; >> bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma); >> struct mm_struct *mm = vma->vm_mm; >> - pte_t *old_pte, *new_pte, pte; >> + pte_t *old_ptep, *new_ptep, pte; > > While we're at it, can we please move the pte decl to a new line? Mixing > pointers and non-pointers is not great (I refactored it but mremap still > has a bunch of less-than-ideal stuff in it :) Sure. > >> pmd_t dummy_pmdval; >> spinlock_t *old_ptl, *new_ptl; >> bool force_flush = false; >> @@ -211,8 +211,8 @@ static int move_ptes(struct pagetable_move_control *pmc, >> * We don't have to worry about the ordering of src and dst >> * pte locks because exclusive mmap_lock prevents deadlock. >> */ >> - old_pte = pte_offset_map_lock(mm, old_pmd, old_addr, &old_ptl); >> - if (!old_pte) { >> + old_ptep = pte_offset_map_lock(mm, old_pmd, old_addr, &old_ptl); >> + if (!old_ptep) { >> err = -EAGAIN; >> goto out; >> } >> @@ -223,10 +223,10 @@ static int move_ptes(struct pagetable_move_control *pmc, >> * mmap_lock, so this new_pte page is stable, so there is no need to get >> * pmdval and do pmd_same() check. >> */ >> - new_pte = pte_offset_map_rw_nolock(mm, new_pmd, new_addr, &dummy_pmdval, >> + new_ptep = pte_offset_map_rw_nolock(mm, new_pmd, new_addr, &dummy_pmdval, >> &new_ptl); >> - if (!new_pte) { >> - pte_unmap_unlock(old_pte, old_ptl); >> + if (!new_ptep) { >> + pte_unmap_unlock(old_ptep, old_ptl); >> err = -EAGAIN; >> goto out; >> } >> @@ -235,12 +235,12 @@ static int move_ptes(struct pagetable_move_control *pmc, >> flush_tlb_batched_pending(vma->vm_mm); >> arch_enter_lazy_mmu_mode(); >> >> - for (; old_addr < old_end; old_pte++, old_addr += PAGE_SIZE, >> - new_pte++, new_addr += PAGE_SIZE) { >> - if (pte_none(ptep_get(old_pte))) >> + for (; old_addr < old_end; old_ptep++, old_addr += PAGE_SIZE, >> + new_ptep++, new_addr += PAGE_SIZE) { >> + if (pte_none(ptep_get(old_ptep))) >> continue; >> >> - pte = ptep_get_and_clear(mm, old_addr, old_pte); >> + pte = ptep_get_and_clear(mm, old_addr, old_ptep); >> /* >> * If we are remapping a valid PTE, make sure >> * to flush TLB before we drop the PTL for the >> @@ -258,7 +258,7 @@ static int move_ptes(struct pagetable_move_control *pmc, >> pte = move_soft_dirty_pte(pte); >> >> if (need_clear_uffd_wp && pte_marker_uffd_wp(pte)) >> - pte_clear(mm, new_addr, new_pte); >> + pte_clear(mm, new_addr, new_ptep); >> else { >> if (need_clear_uffd_wp) { >> if (pte_present(pte)) >> @@ -266,7 +266,7 @@ static int move_ptes(struct pagetable_move_control *pmc, >> else if (is_swap_pte(pte)) >> pte = pte_swp_clear_uffd_wp(pte); >> } >> - set_pte_at(mm, new_addr, new_pte, pte); >> + set_pte_at(mm, new_addr, new_ptep, pte); >> } >> } >> >> @@ -275,8 +275,8 @@ static int move_ptes(struct pagetable_move_control *pmc, >> flush_tlb_range(vma, old_end - len, old_end); >> if (new_ptl != old_ptl) >> spin_unlock(new_ptl); >> - pte_unmap(new_pte - 1); >> - pte_unmap_unlock(old_pte - 1, old_ptl); >> + pte_unmap(new_ptep - 1); >> + pte_unmap_unlock(old_ptep - 1, old_ptl); >> out: >> if (pmc->need_rmap_locks) >> drop_rmap_locks(vma); >> -- >> 2.30.2 >>