linux-kernel - Re: [PATCH] LoongArch: Update the flush cache policy

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: <8809f5a7-de6e-0794-feab-726c26f87344@kylinos.cn>
Date: Tue, 7 May 2024 08:53:23 +0800
From: lijun <lijun01@...inos.cn>
To: Xi Ruoyao <xry111@...111.site>, chenhuacai@...nel.org, kernel@...0n.name,
 lvjianmin@...ngson.cn, dongbiao@...ngson.cn, zhangbaoqi@...ngson.cn
Cc: loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] LoongArch: Update the flush cache policy

The value of addr changes very very quickly, and 'volatile' ensures that 
every change can be read

在 2024/5/6 18:17, Xi Ruoyao 写道:
> On Mon, 2024-05-06 at 18:08 +0800, lijun wrote:
>> volatile prevents compiler optimization by allowing the compiler
>>
>>    to reread the address value of addr every time
> But why is this ever needed?  What's wrong if the compiler optimizes it?
>
> If the problem is the compiler may optimize it to cdesc->ways * 3 *
> cdesc->sets * cdesc->linesz, unknowing cdesc->ways etc may magically
> change, you should use READ_ONCE(cdesc->ways) etc.
>
> I.e. use READ_ONCE on the expression which may magically change, instead
> of hacking addr.  addr won't magically change.
>
>> 在 2024/5/6 17:28, Xi Ruoyao 写道:
>>> On Mon, 2024-05-06 at 17:24 +0800, Li Jun wrote:
>>>> fix when LoongArch s3 resume, Can't find image information
>>>>
>>>> Signed-off-by: Li Jun <lijun01@...inos.cn>
>>>> Signed-off-by: Baoqi Zhang <zhangbaoqi@...ngson.cn>
>>>> Signed-off-by: Jianmin Lv <lvjianmin@...ngson.cn>
>>>> Signed-off-by: Biao Dong <dongbiao@...ngson.cn>
>>>> ---
>>>>    arch/loongarch/mm/cache.c | 24 +++++++++++++++++++++++-
>>>>    1 file changed, 23 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/loongarch/mm/cache.c b/arch/loongarch/mm/cache.c
>>>> index 6be04d36ca07..52872fa0e5d8 100644
>>>> --- a/arch/loongarch/mm/cache.c
>>>> +++ b/arch/loongarch/mm/cache.c
>>>> @@ -63,6 +63,28 @@ static void flush_cache_leaf(unsigned int leaf)
>>>>    	} while (--nr_nodes > 0);
>>>>    }
>>>>    
>>>> +static void flush_cache_last_level(unsigned int leaf)
>>>> +{
>>>> +	u64 addr;
>>>> +	int i, j, nr_nodes, way_size;
>>>> +	struct cache_desc *cdesc = current_cpu_data.cache_leaves
>>>> +
>>>> leaf;
>>>> +
>>>> +	nr_nodes = loongson_sysconf.nr_nodes;
>>>> +
>>>> +	addr = CSR_DMW1_BASE;
>>>> +	iocsr_write32(0x1, 0x280);
>>>> +	way_size = cdesc->sets * cdesc->linesz;
>>>> +	do {
>>>> +		for (i = 0; i < (cdesc->ways * 3); i++) {
>>>> +			for (j = 0; j < (cdesc->sets); j++) {
>>>> +				*(volatile u32 *)addr;
>>> ??? what does this line do?
>>>