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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 29 Dec 2020 14:30:56 +0800 From: "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com> To: Russell King - ARM Linux admin <linux@...linux.org.uk> CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Will Deacon <will.deacon@....com>, Jason Cooper <jason@...edaemon.net>, Haojian Zhuang <haojian.zhuang@...il.com>, Arnd Bergmann <arnd@...db.de>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 1/1] ARM: LPAE: use phys_addr_t instead of unsigned long in outercache hooks On 2020/12/26 20:13, Russell King - ARM Linux admin wrote: > On Fri, Dec 25, 2020 at 07:44:58PM +0800, Zhen Lei wrote: >> The outercache of some Hisilicon SOCs support physical addresses wider >> than 32-bits. The unsigned long datatype is not sufficient for mapping >> physical addresses >= 4GB. The commit ad6b9c9d78b9 ("ARM: 6671/1: LPAE: >> use phys_addr_t instead of unsigned long in outercache functions") has >> already modified the outercache functions. But the parameters of the >> outercache hooks are not changed. This patch use phys_addr_t instead of >> unsigned long in outercache hooks: inv_range, clean_range, flush_range. >> >> To ensure the outercache that does not support LPAE works properly, do >> cast phys_addr_t to unsigned long by adding a middle-tier function. > > Please don't do that. The cast can be done inside the L2 functions > themselves without needing all these additional functions. OK. At first, I wanted to fit in like this: -static void l2c220_inv_range(unsigned long start, unsigned long end) +static void l2c220_inv_range(phys_addr_t lpae_start, phys_addr_t lpae_end) { + unsigned long start = lpae_start; + unsigned long end = lpae_end; > > We probably ought to also add some protection against addresses > 4GB, > although these are hot paths, so we don't want to add tests in these > functions. Maybe instead checking whether the system has memory above > 4GB while the L2 cache is being initialised would be a good idea? > I'm sorry, I didn't quite understand what you meant. Currently, the biggest problem is the compilation problem. The sizeof(long) may be 32, and the 64-bit physical address cannot be transferred from outcache functions to outcache hooks.
Powered by blists - more mailing lists