linux-kernel - Re: [PATCH] parisc: Set valid bit in high byte of 64‑bit physical address

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 for Android: free password hash cracker in your pocket

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

Message-ID: <fb9e642f-e5dd-48f2-b9b0-4ab2a63727f7@samsung.com>
Date: Fri, 19 Dec 2025 13:48:16 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>, Leon Romanovsky
	<leon@...nel.org>, Helge Deller <deller@....de>, Jason Gunthorpe
	<jgg@...pe.ca>
Cc: linux-parisc@...r.kernel.org, linux-kernel@...r.kernel.org, Guenter
	Roeck <linux@...ck-us.net>
Subject: Re: [PATCH] parisc: Set valid bit in high byte of 64‑bit physical address

On 19.12.2025 13:38, James Bottomley wrote:
> On Fri, 2025-12-19 at 09:35 +0100, Marek Szyprowski wrote:
>> On 18.12.2025 22:28, Leon Romanovsky wrote:
>>> On Thu, Dec 18, 2025, at 20:27, Helge Deller wrote:
>>>> On 12/18/25 13:08, Leon Romanovsky wrote:
>>>>> On 32‑bit systems, phys_addr_t is defined as u32. However,
>>>>> parisc expects physical addresses to be 64‑bit values so it can
>>>>> store a validity bit in the upper byte.
>>>>> ...
>>>>> Also remove the now‑obsolete macro.
>>>> Your patch is OK, but could you please keep the lpa() macro?
>>>> It's unrelated to your patch, and sometimes we need the lpa()
>>>> e.g. when adding debug code, so I'd prefer to keep it.
>>> The parch was already accepted and if Marek agrees, he can easily
>>> revert the deleted hunk and rebase my parch.
>>>
>>> However from upstream perspective, we don't keep code which is not
>>> used and if this macro would be function, we would get compilation
>>> warning for that.
>>>
>>> Isn't lpa(x/) equal to virt_to_phys(x)?
>> I can drop the lpa() related change, but let us know what is the
>> advantage of it compared to virt_to_phys()?
> Um, well same as on every architecture: virt_to_phys only gives correct
> results on the offset map since it's defined as an offset map
> subtraction; lpa() gives the the CPU view of the mapping through the
> page table entries, so is correct even in the vmap (and iomap, etc)
> range.

Thanks for the explanation. I will drop the lpa() removal chunk from 
dma-mapping-fixes branch then.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland