linux-kernel - Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC

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: <CAD++jLn+TDfu-aQ+Kfm=unYp4Zjg=endP3GGzZcpuYFR=s1K1g@mail.gmail.com>
Date: Wed, 4 Feb 2026 01:10:01 +0100
From: Linus Walleij <linusw@...nel.org>
To: Yushan Wang <wangyushan12@...wei.com>
Cc: alexandre.belloni@...tlin.com, arnd@...db.de, fustini@...nel.org, 
	Jonathan.Cameron@...wei.com, krzk@...nel.org, linus.walleij@...aro.org, 
	will@...nel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, fanghao11@...wei.com, linuxarm@...wei.com, 
	liuyonglong@...wei.com, prime.zeng@...ilicon.com, wangzhou1@...ilicon.com, 
	xuwei5@...ilicon.com, linux-mm@...r.kernel.org, SeongJae Park <sj@...nel.org>
Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC

Hi Yushan,

thanks for your patch!

On Tue, Feb 3, 2026 at 5:18 PM Yushan Wang <wangyushan12@...wei.com> wrote:
>
> The driver will create a file of `/dev/hisi_l3c` on init, mmap
> operations to it will allocate a memory region that is guaranteed to be
> placed in L3 cache.
>
> The driver also provides unmap() to deallocated the locked memory.
>
> The driver also provides an ioctl interface for user to get cache lock
> information, such as lock restrictions and locked sizes.
>
> Signed-off-by: Yushan Wang <wangyushan12@...wei.com>

The commit message does not say *why* you are doing this?

> +config HISI_SOC_L3C
> +       bool "HiSilicon L3 Cache device driver"
> +       depends on ACPI
> +       depends on ARM64 || COMPILE_TEST
> +       help
> +         This driver provides the functions to lock L3 cache entries from
> +         being evicted for better performance.

Here is the reason though.

Things like this need to be CC to linux-mm@...r.kernel.org.

I don't see why userspace would be so well informed as to make decisions
about what should be locked in the L3 cache and not?

I see the memory hierarchy as any other hardware: a resource that is
allocated and arbitrated by the kernel.

The MM subsytem knows which memory is most cache hot.
Especially when you use DAMON DAMOS, which has the sole
purpose of executing actions like that. Here is a good YouTube.
https://www.youtube.com/watch?v=xKJO4kLTHOI

Shouldn't the MM subsystem be in charge of determining, locking
down and freeing up hot regions in L3 cache?

This looks more like userspace is going to determine that but
how exactly? By running DAMON? Then it's better to keep the
whole mechanism in the kernel where it belongs and let the
MM subsystem adapt locked L3 cache to the usage patterns.

Yours,
Linus Walleij