linux-kernel - Re: [PATCH 1/3] mm: Call pointers to ptes as ptep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fe5c9272-c8f9-4d71-b8e6-d17678cd23ef@lucifer.local>
Date: Tue, 6 May 2025 10:05:39 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: Dev Jain <dev.jain@....com>, akpm@...ux-foundation.org,
        Liam.Howlett@...cle.com, vbabka@...e.cz, jannh@...gle.com,
        pfalcato@...e.de, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        david@...hat.com, peterx@...hat.com, ryan.roberts@....com,
        mingo@...nel.org, libang.li@...group.com, maobibo@...ngson.cn,
        zhengqi.arch@...edance.com, baohua@...nel.org, willy@...radead.org,
        ioworker0@...il.com, yang@...amperecomputing.com
Subject: Re: [PATCH 1/3] mm: Call pointers to ptes as ptep

On Tue, May 06, 2025 at 02:20:01PM +0530, Anshuman Khandual wrote:
> On 5/6/25 10:30, Dev Jain wrote:
> > Avoid confusion between pte_t* and pte_t data types by appending pointer
> > type variables by p. No functional change.
> >
> > Signed-off-by: Dev Jain <dev.jain@....com>
> > ---
[snip]
> Although this makes sense, mm/mremap.c might not be the only place with such
> naming confusions regarding page table entry and page table pointers. Rather
> than fixing this in just a single file, I guess generic MM wide change will
> be better.

No, let's not please. that will be a ton of churn. This confusion literally
already exists all over the place so it's not egregious.

I am sympathetic to this kind of change (I really _hate_ this as an issue), and
since I recently refactored all of mremap I am likely to be ok with this here,
but let's do any such change iteratively, please.