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++jLnK-B=q7X6VyUZDQiO7bG+u0mpC_PzXqhtLvW9LYxEe7g@mail.gmail.com>
Date: Wed, 4 Feb 2026 11:06:40 +0100
From: Linus Walleij <linusw@...nel.org>
To: wangyushan <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, 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

On Wed, Feb 4, 2026 at 10:53 AM wangyushan <wangyushan12@...wei.com> wrote:

> > 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?
>
> This question is actually: should it be kernel or user space
> application to decide if a cache lock should be applied?
>
> Maybe the ideal situation is that this capability should be reserved into kernel
> space as a vendor specific optimization option. With the lack of knowledge
> of memory interleave etc the best move of an application might be allocate
> cache lock as much as possible.

If it is a vendor-specific optimization that has no generic applicability
outside of this specific system, dependent on a specific userspace
that only exist on this system, what is the value for the generic
kernel to carry and maintain this code?

In that case maybe the code should be maintained outside of the
mainline kernel tree.

What we want to see as maintainers are things that are reusable
across several systems.

Integrating this with DAMOS in a generic way is what will help the
next silicon that comes down the road.

I have already seen similar things from Fujitsu (IIRC). We need this
mechanism to be kernel-driven and generic, not custom and
system-specific, least of all driven from userspace by sysfs.

Yours,
Linus Walleij